Node body moving as Groups.Drupal.Org/node input format is way-too limited :KEKJIR

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
DrupalPal's picture

KEKJIR:  node  KEKH8E:  main-post  (updated 20090205145702):

  • KEKXJA:  Not to be negative but I've gotten fed-up with KEKXAN:  the way-too-limited, non-standard, & buggy input format of Groups.Drupal.Org (at least to do fully-formatted posts as my groups.drupal.org/node/18329); so I'm KEKXE5:  moving  the node's main body to another site (recommend one?) while still keeping the discussion and a copy of the teaser paragraph here.
  • KEKIWN:  Intro.  While there's MANY things which Groups.Drupal.Org does wonderfully (as see on my profile), fully-formatted user content it actually seems to do badly.  This is very frustrating to me, as fully-formatted content (such as the formatting of this very post) markedly enhances communication. And it would initially appear from Groups.Drupal.Org's input format that the site can do such formatting --and it can (just look at this this very post) --iff you've infinite time to waste! (this post took hours and required a number of tricks (as using regular expression search-and-replace in place of CSS!); and ones with tables and more advanced formatting can be much worse). So I say KEKXJA above!
  • KEKH8Q:  Why KEKXJA? (Why have I gotten fed up with KEKXAN for at least fully-formatted posts?)  From roughly most to least important,
    1. KEKHVN:  Show-stopper:  broken spam filtering now preventing me from posting further updates. I've composed a complete reply to our new participant MRadcliffe's comment (which in the node's body node for updatability), and heavily updated the node's body, but I can't post the updated node's body due to a Groups.Drupal.Org bug (which I've reported but have not heard back on it). And why the problem?  Apparently more problematic-filtering of the input content! --as Groups.Drupal.Org nodes want to be "clever", trying stop spam too automaticly by detecting spam via some advanced but broken input filter instead of an ordinary CAPTCHA --ugh!
    2. KEKHXK:  Practical show-stopper: non-standard & way-too limited HTML. Moreover, in the intro's creation the intro and even in comments, I've wasted hours, if not a day or more all told, having to constrain all HTML to fit into Groups.Drupal.Org/node 's terribly-restrictive and non-standard input format (as used on the comment form).
      1. KEKVH8:  For instance, as well as a primitive subset of HTML codes (and no Javascript, and not even CSS!), you are FORCED to interpret every line break as a new-line (making it tricky or impossible to use an WYSIWYG HTML editor externally --so not only does it lack one internally, it even makes it hard to add one externally).
      2. KEKHXS:  And I'd guess much of this non-standard HTML formatting (as auto-line breaks --want them or not) is because of the days before Drupal had a WYSIWYG editor, but Drupal has several WYSIWYG editors now, so get with the times!  Or am I missing something?
        • KELEOO:  (Indeed, Groups.Durpal.Org  --the community center of Drupal-- is still on D5 -- the prior version, and when D7 is already well under way --what the heck?!)
      3. KEL441:  But even if no WYSIWYG editors yet, can't we at least have the option to turn off all non-essential input filtering?
        1. KEL4A0:  the problem here is probably with with "Markdown with Smartypants" (from reviewing http://groups.drupal.org/about#Code 's "Modules of interest" list) especially in that it (or whatever filter it is) cannot be turned off.
    3. KEKJ5V:  Notable time-waster: Versioning must be done manualy even when it's there!  Drupal core can version a node content (indeed every Groups.Drupal.Org discussion posts ask for a log entry); but I see now way to display & diff the prior versions.  Consequently I've been having to maintain the intermediate versions manually!
      •   KELF1Z:  (And, boy, with no history maintained for each page maintained for you, doing it manually is no walk-in-the-park: I've had to create a template for a node & comment post, plus, to keep track of which file was posted when to where, I've had to create a spreadsheet to track it all --ugh!)
    4. KEKVPI:  Notable annoyance: A comment can't be edited after it's been replied to.
      1. KEKW1G:  This causes me to avoid wanting to put anything in a comment which might need editing later (such as instructions and an answer to a FAQ, as my groups.drupal.org/node/18329 does a lot)
        1. KELFJ8:  so I've typically put the would-be-comment text into the node's main post (real example) and then the reply just being a short note giving a link to it (real example).
      2. KEKW1U:  Yeah, I can see the point behind this restriction (freeze the text after some reply); and I could even see that one might argue that a comment couldn't be edited at all (as others could easily have read it and reacted not just with a reply to it).  But on the other hand, the main-post of a Drupal node can be freely edited after the fact (and with Groups.Drupal.Org, without even revealing any history of edits, or even that it has been edited), and indeed this is a very valuable ability -- so this is consistent.
      3. KEKW4G:  I suspect the immediate solution would be to as well as displaying a creation/post date, to also display it's modified date (but perhaps only if the entry has been subsequently modified) --and both for comments and the main node post.
        1. KEKXR5:  This also eliminates the need to place an updated-date at the top of the node post, which I've also had to do (for instance, see the start of this post) to alert readers that it is changed.   
        2. KEKXRR:  Indeed when Drupal is made to use its node construct also for the user profile (as I would agree it should), such a mod date also saves the need for a manual  update-date on the user profile.
    5. KEKHY2:  All of this notable unnecessary work would be gone, and complex/involved pages would be possible & straightforward if Groups.Drupal.Org nodes just pretty-much left good standard HTML alone --as it seems it should.    But since it doesn't, it tried to get "smart" with filtering which is pretty poor if even desirable, it makes any post needing significant formatting to take 2 to 3x longer than it should, if even possible -- even if you use an external WYSIWYG editor. All told, I've easily spent 2 or 3 extra days of work work just trying to get my well-formatted user content to appear properly on Groups.Drupal.Org, and I can no longer afford that, especially now I've also encountered this apparent showstopper.  And finally...

    6. KEKHYD:  Not ideal but understandable: There's no embedded ads to get paid for real contributions here. Just a bit annoying, and especially after so much unnecessary work, I can't even put revenue generating ads on the page (something I wouldn't normally immediately worry about, but after having to spend frustrating hours & hours with this HTML, it would be really nice!)  But of course I realize realize that while Drupal does have revenue sharing modules, such a feature is not a simple matter to "ad", both technically and probably administratively.
  • KEKJ5C:  So I'm starting & planning to do the move KEKXE5.  
    1. KEKXPZ:  As mentioned I will still keep a copy of the first-paragraph teaser summary, but after the teaser will be a link to the content page (on a site without out these problems, opening a new window) plus a link to this page here to explain.
    2. KEKJCD:  Sadly users will have to go to 1-more click, plus click back to read comments, but this seems a small price to pay to solve all these problems.  The biggest cost may be that some users may view this as not fully supporting Groups.Drupal.Org since the actual content doesn't appear there.  But hopefully by referring them to this page here, specifically how much I've already tried, they will understand.
    3. KEKJPX:  As to where else to host the node's main body,
      1. KELJNZL:  It's currently not that big of deal since it's just this 1 to 3 pages, but if it became a regular thing (for several node body's), it might become rather important.
      2. KELJOH:  Something which could automatically maintain a page history would be a big plus.
      3. KELJOT:  options I'm considering, in no order:
        • KEKJXJ:  A simple FrontPage site (since I've done many of these so it's super easy).  Naturally this isn't scalable nor even Web 2.0, but, as long as it stays small, it's quick to port to something which is since it's pure HTML.
        • KELIXL:  WebDAV pages delivered via Subversion (and edited by any WYSIWYG editor, as FrontPage).  Some work to set up, but does the auto-versioning.  I kind-a like this.  Possibly use iframe for repeated content (as borders).
        •  KEKK27:  Maybe a Drupal site which of course is not so constrained.  The problem is I don't have one up yet and am unfamiliar here, indeed ironically how to do that well (which generally comes first) is what the node's main body is about.  But, if time permits, I might do this anyway for the obvious reason that it's I'm currently aiming.  (Plus then Druplars wouldn't growl (seemingly needlessly) that "It's not Drupal."!)
  • KEL0QN:  Why I post this here? (if perhaps not obvious)  2 reasons:
    1. KEL1EU:  to be respectful my participants of my groups.drupal.org/node/18329, I need to let them know of the move & why (and so I'm putting a comment on that node referencing this post),
    2. KEL1F3:  And, especially if I'm then going to have to write it up, I'd also like to let the users & especially makers of Groups.Drupal.Org know of this news (specifically members http://groups.drupal.org/maintenance for to fix it, and ideally http://groups.drupal.org/groups-drupal-org for how should it be fixed) and, especially for them, of the exact reasons (why I post it in those group(s), and just reference it from groups.drupal.org/node/18329), so if they desired they could say improve Groups.Drupal.Org and/or correct me these details.

    KEL1CT:  I also post it as a node body, rather than a comment, since (it could be a topic in itself) and (it also contains quite a few details which may need to be updated but comments easily freeze).

  • Hope this helps!

    Comments

    putting lots of links

    greggles's picture

    Frankly, I have a hard time reading your posts because of all the anchor linking that you do. In my opinion, it is inappropriate behavior.

    From what I can read in your two posts, you find Mollom (the spam filter used here) blocks you and the input format is too limited. Mollom considers posts with lots of links to be spam, so I suggest you reduce the number of anchored links in your posts.

    Regarding input formats, this site has very liberal input formats in terms of which tags they allow. Beyond that, though, one uses markdown and one doesn't. If you don't like Markdown then use the other.

    Misplaced priorities

    shunting's picture

    It seems odd that an author should have to constrain their style because of the number of links a spam filter thinks is appropriate.

    You may not like the writer's style, but then you are free not to read what you like. However, when you have moved on to more pleasurable reading matter, the author is still under the technical constraint, and is prevented from writing as others might like.

    One would think that in a content management system, the needs of content creators would take priority over the technical constraints imposd by a spam filter!

    Maintenance

    Group organizers

    Group categories

    Group notifications

    This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: