Regression: teaser splitter forces paragraph break

dropdown's are handled by at least two contrib modules.

teaser splitter forcing a paragraph break sounds like a regression.

Confirmed: it inserts a plain text paragraph break (2 newlines).

1. Create a new node
2. Insert a paragraph of text into the body field
3. Position the cursor somewhere inside the paragraph, and click "Split summary at cursor"
4. Click "join summary"

Now suddenly there are two paragraphs.

http://drupal.org/node/195352 was duplicate.

From teaser.js:

    // Join the teaser back to the body.
    function join_teaser() {
      if (teaser.val()) {
        body.val(trim(teaser.val()) +'\r\n\r\n'+ trim(body.val()));
      }

It seems to expect a teaser break is always inbetween paragraphs.

Perhaps this is a better method:

        body.val(ltrim(teaser.val()) + rtrim(body.val()));

gaele: could you roll that into a patch?

...

Hmm, I applied it, but it's not making any difference for me. Did a hard browser refresh etc.

Perhaps I should define ltrim and rtrim (they're default in PHP but not JS).
Besides, both splitting and joining should preserve whitespaces at the break.
This should do it.

Sorry, it's less happy now. I still get the line breaks, then I get bits disappearing if I rejoin.

That's strange. At demo.guruburu.com it works okay.

Attached teaser.js as it should be.

Could the problem be that http://api.drupal.org/api/function/node_teaser_js is also inserting CR/LF sequence before and after the break delimiter?

If I understand it correctly node_teaser_js is called on submit. In such a case adding two newlines might be a good thing.

It all depends on the use cases. Which use cases are there?

1. A user accidentally clicks the teaser splitter ("Hmm, what does this button do?") and then clicks join teaser again. In such a case Drupal should not touch the formatting (which the patch does, or should do).
2. A user clicks the teaser splitter, perhaps edits a few lines in teaser or body, and then decides the break should be at another position (=> join teaser; relocate cursor; split teaser). What should Drupal do?
3. A user clicks the teaser splitter, saves the node, goes back to editing, and clicks join teaser. Perhaps you could say in such a case a conscious decision was made to have a separate teaser, justifying formatting changes.

Anyway, could someone please try the teaser.js from #10?

...

(Sorry, fighting with d.o. slowness.)

...

Revised .js file works fine (after doing a hard refresh to reload the JS), about to test patch. Note that my comment at #11 still applies (i.e. this needs to be fixed too).

Out of interest, do you know what the motivation is for trimming the teaser (aka summary) and the body? Is it just to remove unnecessary whitespace and the beginning and end of the post?

Patch at #8 applies OK.

#11 also needs fixing: consider: I have a node with the

delimiter manually inserted in the middle of a line. If I edit the node and save it (or hit Preview) then line breaks are wrapped round the delimiter (these show up as newlines at the end of the summary and the start of the body). Similar problem if I use the splitter button to create the delimiter. Basically the JS and node_teaser_js() need to be consistent with each other.

In some ways what the teaser splitter/joiner was originally trying to do was quite sensible (i.e. enforce a para break between teaser and body) but as this issue says, it is a regression and limits the options for the user. It's easy enough to add a couple of line breaks at the top of the body if required, or even at the end of the teaser/summary. From what I can make out from a few tests, the automatic line breaks filter handles superfluous newlines at the beginning/end of teaser/body quite happily, so we don't end up with unwanted vertical whitespace underneath a teaser, for example. And if the summary really is a teaser and breaks in the middle of an HTML elelment, then the htmlcorrector will close the open tags :-)

It would also be cool if the JS could remember where the cursor was when you hit the "Split" or "Join summary" button ... maybe that's a new feature though.

Changing the behaviour from an arbitrary split to a paragraph break was completely intentional, and follows the change in UI from a random tag to a horizontal ruler separating two fields.

Requiring the user to insert blind line breaks at the end of the teaser is a bad idea, because visually identical input would result in very different end results. This is a typical faux-pas for usability and pretty much undoes all the work in making the teaser UI more consistent and thus easier to grok.

We already acknowledge this principle, by e.g. having the line break filter remove trailing whitespace.

As far as I'm concerned, this is -1 by design.

"Requiring the user to insert blind line breaks at the end of the teaser is a bad idea, because visually identical input would result in very different end results. This is a typical faux-pas for usability..."

That's right, but so is splitting then joining not resulting in zero difference.

Then again, this whole teaser looks like a conceptual mess, which won't be solved by a simple patch like this.

Thanks for the background to the enhancements, Steven.

I can see 2 relatively simple ways of ?maybe reconciling the usability concerns with the problems of "splitting then joining not resulting in zero difference" and of the inability to have the teaser as a part of the first paragraph (which could muck up old content when it is re-saved after an upgrade to D6):

a) If you want to separate teaser from body then put 2 line breaks in at the beginning of the body section. This would need to be pointed out on the edit page itself - and should perhaps be the default. Problem: does this really get round the visually identical input => different end results issue?

b) Add a 2nd checkbox along the lines of "Separate* summary from main text by paragraph break in full view". This would only be visible when "Show summary in full view" is visible and checked and when input format contains line breaks filter (since otherwise this is all academic anyway). [* this is meant to be a verb but that may not be obvious so would need rewording.] Problem: is this getting too complicated?

What do you reckon?

gpk:

No knock on the developers or the enhancements but...

Again, my situation: Small, Technorati 5000 group blog, 8 very untechnical writers, 20,000 or so posts. So, retraining worries me; I've been a Drupal user since 4.75, and I was totally baffled about why my teaser was suddenly disappearing because I didn't check the "Show summary in full view" box. (I don't have a summary; I have a teaser. This behavior gets even more confusing with a very short post, where the teaser is the body. Then you go to the full page and nothing is there.) Right now, if I understand this thread, it's looking like I have to train my users to: (1) no longer use the BREAK tag; (2) understand two new checkboxes OR (3) understand why joining a split post doesn't bring them back to the original post; (4) Understand how to fix past posts, which will break when re-posted or saved. That's not the ideal way to introduce my users to the truly great D6, because we are posting all the time. Totally smooth posting is a necessity, and anything else is a luxury.

Keying off what gaele said (and I'm glad I didn't say ;-)

This whole teaser looks like a conceptual mess

We have three use cases. I'm going to call them summary, lead, and teaser. (gpk, this differs from what I wrote here. I added another use case.) The "trimmed" nomenclature confuses the use cases with the implementation, so I'm not going to use it.

We have a superclass called intro. Its function is to introduce the reader to the post. In each case the editorial function is to get the reader to click "Read More" but they do this with different editorial strategies:

1. Teaser is a subclass of intro. It begins at the start of a post, and has a few words or phrases that "tease" the reader into reading more. It divides the post into the portion that appears on the main page, and the portion that appears on the post page. This is classic <D6 behavior. Conceptually and editorially, the teaser and the body are one entity, and the teaser is a SPAN within the body.

2. Lead is a subclass of intro. Like teaser, it begins at the start of a post, and divides the post into the portion that appears on the main page, and the portion that appears on the post page. It's a classic newspaper lead paragraph. Whereas a teaser is not necessarily readable on its own (it could be just a few words), a lead can stand alone. Conceptually and editorially, the teaser and the body are one entity, and the teaser is a DIV within the body.

3. Summary is a subclass of intro. A summary is an abstract or precis of the post, as in a medical journal or academic paper. Conceptually and editorially, a summary and the post it summarizes are two entities, not one. While the summary may appear before the post body, it doesn't do so necessarily. Summaries are also far more valuable in aggregation than teasers and leads, since they intend to convey the entire content of a post). The summary is a DIV, but not necessarily part of the body.

And so, from the content creator's perspective (and not worrying about the back end for the moment):

1. The splitter is most useful for SPAN-like teasers, since one simply positions the break between main page and post page content, where no break existed before

2. The splitter is less useful for DIV-like leads, since the natural breaks between DIVs already exist (unlike a teaser, where no break exists at all). Still, it's useful to be able to be able to indicate the main/post break, even between DIVs.

3. The splitter is not at all useful for summaries. A post and its summary are conceptually and editorially two things (unlike a post and its teaser or lead). The process of writing a summary of a post is completely different from writing a post; ask a technical writer; some editorial workflows even have different people work on the two; some companies give away summaries and sell complete content; and so forth. Moreover, there's no ordered relationship between a summary and a post; the two can be distributed separately; one can even imagine a main page layout with a post's title, its summary... and a teaser!

Separation of concerns:

1. Treat the summary use case as a separate concern. I think it can be well handled as fielded data through CCK. The splitter adds little to the process of creating one. And if it turns out that a paragraph in the post is a good summary, then cut and paste it into the summary field.

This may be more controversial, but:

2. The need to make a SPAN-like teaser into a paragraph at the main/post split should not be imposed on the content creators (see retraining, above. Plus, they should be able to write as they like, insofar as possible. They are the ones who add value!!!!). However, the need to have the main/post split between DIVs for a lead should be respected.

Leading me to ask... IIRC, the reason to use the COMMENT "tag" was that comments can appear anywhere in text, so the SPAN-like behavior of the teaser was supported. Could the same behavior be accomplished, and meet requirement #2 above, with an empty SPAN tag that had an ID (say... drupal_[lead|teaser])? Then one doesn't have to add carriage returns, and so on, and can also control any behavior, including line break behavior, with the ID value via CSS or theming.. Plus the markup weenies could just type in the tag instead of using the splitter...

More disruptively... I'm sure this isn't possible... But I find the teaser/body distinction in the database really hard to get my head around, since, after all, the whole point of having a splitter is that the boundary between teaser/lead is to some extent fluid and subjective (unlike a summary, which truly is fielded). That's why the boundary can be resplit! What not just put the whole post body into the body field, including the classed SPAN tag, and split for display in theming based on the split tag?

3. If the usability concerns persist, it might make sense to allow "classic" teaser behavior to continue.

I can try a patch, if I understand the requirements. Again, this is a stab at the conceptual issues, and solving them necessarily precedes solving the technical issues...

UPDATE 1 Another post, here, takes the same tack and adds an additional subclass to intro: Excerpt.

UPDATE 2 Please, can we just have "classic" behavior in addition to the splitter? See, again, comments on "my situation" as well.

My bad:

I should have been saying "splitter" not "dragger" above. Yes, put the cursor wherever, split... Sorry!

shunting, thanks a lot for your input from an editor's perspective. Very valuable.

A few remarks:

- "Show summary in full view" is enabled by default. Which is the D5 behavior. So no worries there.

- Reading your post made me find another bug: http://drupal.org/node/201667

- Discussion about concepts here: http://drupal.org/node/193680

Gaele @23:

Thanks. I was worried that I was too confrontational. Can this be elevated to "Critical"? Because now it's not just me, but artatec @22, who's saying that right now, this functionality just is not ready; in fact, from my own perspective of my content and my users, it's broken as designed. (Sorry if there's an "ouch" there, but no knock, again, on the implementors -- there's just a mismatch between the requirements for creating content, what teasers did, and what they now do).

shunting, I agree the problem is annoying, but I don't think it's critical. Feel free to create a new issue to make the teaser splitter optional (probably per node type). There should be more people interested in such a feature.

OK I think there are a number of issues/bugs/concerns, here's an attempt to summarise:

We have concerns (most recently from shunting and artatac) that the new teaser/summary functionality is "not ready". Whether or not this is deemed "critical", there are certainly some points that if not addressed before D6 is released will result in hordes of frustrated (existing) users.

- One problem is to do with the bug Gaele found at #23 (nice catch!). That probably explains the "blank pages" problem (shunting @ #20). This should be quite easily fixed.

- A second is to do with the new functionality forcing a paragraph break at the end of a teaser/summary. That was the original concern of this issue. This problem has a few different facets as outlined earlier and a way forward has yet to be agreed.

If we fix these then am I right in thinking that we are left with just the usability concerns/problems (which are of course just as important)?

A brief aside: artatac @ #22: If you don't use the summary/teaser splitter then it *does* behave like D5 - i.e. you get an automatically generated teaser whose length is defined on the Post settings page. The fancy JS stuff is just supposed to make life easier when you want to specify the exact place where you want the teaser to end (so that you don't have check the Preview to remind yourself what the <!--break--> delimiter is). So apart from the 2 problems I've already mentioned, D5 functionality is there I think?

So on to the usability problems, especially the ease of replicating D5 functionality/behaviour.

- Gaele's suggestion #25 above, i.e. allowing the administrator to turn the "splitter" on or off in some way for users, would be one approach.

- Also shunting in the other issue http://drupal.org/node/193680#comment-660413 essentially suggested making the whole thing much more configurable (the details of that suggestion have probably been superceded by comments above at #20).

- There is then the question of terminology which (as the title of the other issue makes clear) is confusing at present.

- And finally maybe some readily available help/description is needed to help users who do have the splitter available.

Have I missed anything? I know I'm not addressing the "big questions", but am deliberately taking a "what can we do for D6" approach.

As gaele said in the other issue http://drupal.org/node/193680#comment-661999, more comment on all of this from end users would be really helpful.

I've experimented some more and I'm still finding the behavior counterintuitive. Starting as a D5 user who assumes that BREAK tag is usable:

Filtered HTML
1. Make this post (note spaces before and after BREAK) and press Preview

Teaser <!--break--> Body

2. Result is:
Top box (confusingly labelled "Body"): Teaser
Bottom box (no label): Body

NOTE That spaces around the break are removed.

3. Now I press the Join Button and I get:

Teaser

Body

on two lines. So, my content is not respected in three ways: subtracting whitespace, adding returns where there were none, and losing my break.*

Full HTML
1. Preview this:

<p>Teaser <!--break--> Body</p>

2. Yields this:

Top: <p>Teaser
Bottom:  Body</p>

NOTE From a usability perspective, what do I tell the user to get them to conceptualize this? That it's OK that the open tag <p> and the close tag </p> span the two boxes?

3. Now press Join:

<p>Teaser

Body</p>

on two lines. Again, my content is not respected and in the same three ways: subtracting whitespace, adding returns where there were none, and losing my break. And it's even more confusing, because as I (that is, the "I" playing the role of the writer) dimly understand (from the explanation provided by "me", the administrator) the whole point of the new behavior is to treat teasers as paragraphs unto themselves. So where is the <p> tag that every other paragraph has?

4. So, experimenting, I try this (cursor just before [X]) and Press Split Summary at Cursor

<p>Teaser<!--break-->[X]

Body</p>

5. Yielding this:

Top: <p>Teaser<!--break-->
Bottom: Body</p>

So now the break comment is still there after I press the Split Summary button instead of the Preview button. Why?
6. Press join again:

<p>Teaser<!--break-->

Body</p>

So returns are added but <--break--> is not removed. Why?

7. For grins (cursor just before [x]), press preview:

<p>Teaser<!--br[x]eak-->

Body</p>

8. Yields this:

Top: <p>Teaser <!--br

Bottom: eak-->

Body.</p>

9. And on Join:

<p>Teaser <!--br

eak-->

Body.</p>

Thinking out loud: Can't Join roundtrip the break comment back into the post, and whitespace be respected throughout, so that adding carriage returns goes away? I think my users would be with a BREAK comment being present, and clicking Split at cursor over-riding that, and then the BREAK comment being repositioned where the new cursor break was on Join. That feels like the HTML and the boxes and the buttons are all playing well together. Maybe an error message on validate could be issued for the pathological case of the cursor in the BREAK comment. This doesn't handle the weird markup problem at point 3 in Full HTML, though....

That seems a lot more intuitive, to me--But does it break any other requirements?

NOTE * A break is a value add. Authors choose breaks consciously, because the right break improves their clickthroughs from the main page to the post page. The conscious break is an important use case in D5, besides the automatic break, which most of my writers never use, because it doesn't help them win readers.

I'm not sure this is the exact same issue, but it's related. When my users post any form of html at the beginning of their post, if the end tag is not before the teaser, then that html gets applied to every post on my main page. For example, if they use <font face="Times New Roman" size="4"> and the </font> tag is after the teaser cut, the Times New Roman is then applied to everything, not just that single post, on the front page. I'm sure this could be prevented by disabling the html, but I'd like to enable such simple tags. The paragraph tag is not the only one that gets broken up, in my experience.

@28 courtney:

This looks like a breaker to me.

Surely the teaser should never, ever create invalid HTML from valid HTML?

Gabor or gpk can mark this back down to normal, but I thought I'd elevate this so it gets some attention.

Well I've seen teasers with unclosed <em> tags on drupal.org projects making half the download page italic, so that wouldn't be a regression. I've not yet tried it, but wouldn't the htmlcorrector filter (now in core) deal with this situation though. Anyway I'll leave this for someone else to decide, but I don't think it's critical.

@#28 courtney: I tried and this problem is now fixed in Drupal 6 thanks to the htmlcorrector, as catch said.

Not critical then.

@32 Not critical

OK. the HTML corrector catches it... Not sure that's going to work if and when Drupal moves to XML. If the markup conveys any value at all beyond presentation, it's not likely that the user will be happy with automatic corrections. Further, it bugs me, as a cultural issue "Drupal Way" if you will, that it's OK to introduce errors programmatically -- even if the user can do so, it's not the same use case.

All that said, though, not for D6.

Bump. I am seeing a forced line break at the split. I can see why this would be ok most of the time, but it seems pushy, and not always wanted.

Subscribe.

I realize that it's a bit late to complain, but the fact that pre D6 nodes with the break tags inserted manually will be changed when re-saved in D6 bothers me.

202567 has been marked a duplicate of this bug. That issue had an old patch that might be of use here.

Robin

Although technically not the same issue, this one is also "Regression: teaser splitter forces paragraph break", so possibly better solve it here.

While Steven calls these newlines by design, they do cause some problems on my site as well. My use case is teaser only nodes (as in break tag at the end of teaser/body). When I edit such a node in Drupal 6, I get the separated teaser and body textareas which greatly visualizes that I am editing a teaser only node. Superb. But when I save it, the empty body gets appended with newlines before and after the inserted break tag, so from then on, Drupal thinks my teaser and body are different (the body is not empty due to the newlines). The newlines with the break tag should only ever be appended if there is something in that body to append in the first place. This patch does not modify newlines in other cases, so it might indeed be another issue. Tell me if I'd better open a new one.

@37: I think this particular problem might be solved by the patch at #23 of #201854: "Read more" link sometimes shown when it shouldn't be, or not shown when it should. It's hardly pretty but probably the best bet for 6.x since I don't think we want to start completely refactoring teaser handling.

As the last postings are growing quite old - is this issue still beeing discussed? I am having a real problem with the fact that the teaser splitter parts a body's content in full view by inserting additional "paragraph" tags. The only way I can creata a teaser break that does not affect a full view is to manually insert the !--break--. If I edit the node afterwards, drupal now shows me the content separated into two windows, as if I would have split it via the split-button. Now I have to copy the second part's content into the teaser-window and afterwards make the two windows join. Then I have to insert a !--break-- again to make the content show correctly split like it was before. Usability wise this is making the content editing process way too complicated.

My apologies if there is a workaround that i should have missed by now. If there is one - please tell me.

There should be an option to disable this.

There should be an option to disable this.

UPDATE I repeat myself when under stress. I repeat myself when under stress.

So, am I the only one who gets random double posts? Is this a symptom of the mousing equivalent of lead-foot, or something deeper?

Edit - my prior posting should now be understandable. Also subscribing for an opt-out solution.

For those who have a problem with the teaser breaking HTML, have a look at this issue:

#221257: text_summary() should output valid HTML and Unicode text, and not count markup characters as part of the text length

Note: Yes, the current version (6.19) still breaks HTML without an inch of a problem.

Thank you.
Alexis Wilke

I'm adding this because I came here first and had to search a while longer for the solution. This may not work for everyone, but the best solution I found was to disable the "Split Summary at Cursor" entirely. This is probably most cleanly done using http://drupal.org/project/resizable_body

movinr8along,

I've also been thinking that it would be better not to save the auto-teaser in the database. It is, however, a must have in case you go to /node or a views equivalent.

Now, using a flag to know whether it was cut automatically or not would certainly be wise. That way you don't guess as it is done right now.

Thank you for the link.
Alexis