Please respect whitespace in Extended Entry (for WordPress)
  • George the FleaGeorge the Flea
    I've been testing out the Extended Entry field for working with a new WordPress blog, and am running into a problem: MarsEdit always submits this to the server, regardless of leading/trailing whitespace:

    ...end of the entry text.<!--more--><h2>Starting of the extended entry</h2>...


    This is a problem, because it causes WordPress to render this markup to the page:

    ...<p>end of the entry text.<span id="more-1"></span><br><h2>Starting of the extended entry</h2>...


    In other words, it nests the H2 in the preceding paragraph, which is decidedly NOT what I want. If I edit the entry in the WordPress admin screen, I can get my desired markup by doing this:

    ...end of the entry text<!--more-->

    <h2>Starting of the extended entry</h2>...


    And when MarsEdit pulls that in, it shows the extended entry starting with a pair of newlines (as I would expect). However, if I save an entry from MarsEdit with newlines leading the extended entry, they get stripped out and I'm back to square one.

    I'd really appreciate it if, at least for WordPress blogs, you respected the whitespace at the end of the entry and beginning of the extended entry. I don't see that I have much choice about this except to avoid the extended entry feature completely in favor of manually inserting <!--more--> tags currently (which is unfortunate, because there's a nice usability improvement for this particular project when using a separate field for extended entry, as I always have the same sort of standalone information down there).
  • Daniel JalkutDaniel Jalkut
    Hi - I thought I was respecting the whitespace. Is it possible it's being stripped on the WordPress end of things? If you examine Window -> Network Log after sending a point with explicit whitespace between the sections, does it show the whitespace already stripped in the submission to WordPress?
  • George the FleaGeorge the Flea
    Hm, it looks like it might be a WordPress thing (at least partially, although there is definitely something weird going on at the MarsEdit end, as well).

    In the network log, the request text shows a single linebreak at the start of the mt_text_more field (although there are two in the editor itself, which is odd), but then the getPost call has no leading whitespace when it returns the post from WordPress.

    When I manually log into the WordPress admin and add the two linebreaks after the <!--more--> tag, then refresh MarsEdit the mt_text_more field for the entry has two linebreaks at the beginning of it (instead of just one the way it had when getting sent from MarsEdit), and the final in-UI rendering of the post is identical to what I had before I published it at all.

    If I then publish an edit to the post, MarsEdit once again sends it out with only one linebreak at the beginning of the mt_text_more field, and I end up with no linebreaks back in WordPress. If I use four linebreaks, MarsEdit sends it out with two at the beginning of the field, but WordPress still happily strips them out.

    It looks like I'll need to contact WordPress to report this as a bug or similar no matter what (and probably code some hacky plugin or functions.php workaround for the problem). :-\
  • Daniel JalkutDaniel Jalkut
    I thought this was starting to sound familiar so I did some searching on WordPress and ... sigh, this is a little embarrassing but I may be somewhat to blame for the behavior you're seeing at WordPress. Years ago it looks like I encouraged them to strip the whitespace from supplied Body and Extended values, to make it consistent with the way WordPress behaves elsewhere:

    http://core.trac.wordpress.org/ticket/6016

    There's a lot of discussion there about how your specific use case is stymied by this but at the time I seemed to think there were behaviors elsewhere in WordPress that made it worse to preserve the whitespace.

    Daniel
  • George the FleaGeorge the Flea
    Ha, that's amusing. The problem with that patch is that it doesn't take into account the scenario where the mt_extended_text field starts with a block-level element, which borks the HTML once the WordPress parser is done with it.

    I've created a small WordPress plugin that automatically appends two linebreaks to the more tag if it is followed by common block-level elements. Hopefully it will be useful for other folks who run into this issue:

    http://wordpress.org/extend/plugins/breathable-more-tag/

    I've never signed up for WordPress bug reporting credentials, but if I remember to do that I'll see about reporting this edge case; would be nice to get it changed in the core code.
  • Daniel JalkutDaniel Jalkut
    Thanks. Yeah, signing up is not a big deal - just a quick registration with their Trac system. If you do get a chance please file it!
Add a Comment

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In Apply for Membership

Categories