The big break-tag discussion started because I thought the HTML-comment <!--break--> tag was not usable enough. I wanted a simple tag.

However, all that fades away if we have a better method of inserting the break. The text tag is really a hack and not very friendly. If we can hide the tag in normal use and only use it internally, we don't need to worry about it being ugly or hard. We can use the HTML comment syntax.

See: http://acko.net/files/jQuery-splitter.mov

The attached patch implements a jQuery splitter. The body field gains a button, which, when clicked, splits the textarea into two resizable portions. The break is made at the current cursor location. Clicking again joins the teaser to the body. It works just as if you typed a break tag in the middle. If you do not split the teaser, one will be autogenerated (or you could still manually use the break tag, if you wanted). Note that submitting an empty teaser is different from submitting a joined body (one textarea).

Any existing node is automatically edited in its split form, if it had a break tag before. The JS scans the textarea for the break tag, and splits it if found. That way, it still degrades gracefully: the form still contains the unaltered text with break tag.

The only change to the form is the addition of a hidden, disabled textarea for the teaser. I could also add this through JS, but it would make the Form API code much more difficult. With my patch, the teaser textarea is also themable and resizable.

The JS behaviour kicks in with the #teaser property on the textarea field, which designes a textarea as a teaser belonging to the body textarea whose id is given. WYSIWYG editors can disable it and replace it with their own break tag handling (e.g. a styled horizontal ruler in the editor).

I also removed the earlier db update and replaced it with the reverse update, which only gets run if you already updated to 5.0-HEAD.

Ok so, it's a gross violation of the code freeze, but hey, this is how teaser handling *should* be. And this should also keep everyone happy.

Tested in IE6/7, Firefox, Safari, Opera. Challenge to JS gurus: make it so the textarea portions each take up the right size to maintain visual consistency, and use fadeouts instead.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

webchick’s picture

+1 from me.

This solves the usability problem of the break comment for end users while retaining the current behaviour for people who have JS disabled or who access Drupal data from external systems. I was personally there when Steven spent about 2 hours slaving away at this to get it to work under IE, so it's been well-tested.

It is clearly a feature, which I would normally be opposed to this late in the cycle, but it fixes what the vast majority of us consider a critical bug (the <break> tag) and is also a usability improvement, so I would support its inclusion in 5.

Will leave to someone more JS-fluent to RTBC.

Bèr Kessels’s picture

This is absolutely the most silly solution in ages. Sorry. -1. No way should we even consider such a large structural patch to go in this far after the freeze.

Yes it looks Geil. And yes, it improves usability. But it changes nothing about the actual problem, which is having a break tag or a break comment or any other solution.

Please don't be stubborn and just rollback this issue completely: it is too hot and it already starts to threaten the actual release.

toemaz’s picture

I didn't follow any issues on this matter so far, but I'd like to give my opinion on the proposed idea. I propose drupal to a lot of people as a CMS solution and most of them are struggling with the break thing. Once they get it, it's not that hard.
Anyway, the fact remains I have to explain each time. This solution would solve it I guess.

So +1 from my point of view. Nice work.

dman’s picture

I really don't know what to make of this solution.
It's cool, and in some respects, yes, it is exactly how a teaser selector widget should work.
But
It's radical, and would be hard to push through even with support.
It doesn't address the problem being debated of how the pseudo-tag is actually serialized. (some say that's irrelevant, and I disagree)

If this approach was where we wanted to go, I'd second the suggestion of incorporating excerpt.module into core. ... then get it working like your demo, and discard this hack marker thing altogether.
... Oh hang on, that's half what you've actually done, isn't it?

Bloody good work on getting such a thing working consistantly, so applause for that.
I just feel a bit dirty using a client-side UI to fix a problem that's been introduced at a data-storage level.

I'd vote for this if it meant the elimination of all pseudo-break tags altogether!
... and there was still a good non-js-alternative.
... and if we were not in a feature freeze. :-B

.dan.

ontwerpwerk’s picture

The patch changes stuff in the block.module that looks unrelated to the teaser issue

Other than that I think it does fix the problem for 5.x.
It's not feasible to remove the teaserbreak at the moment, and this patch makes a workable and usable change to the user interface to remedy the fact that endusers should never see the teaserbreak (as long as they have javascript enabled)

I tested it for winxp ie7, ie6 and ff2 and it works as advertised

+1 from me
not sure about the changes to block.module

chx’s picture

Title: jQuery Teaser Splitter » Solve the break tag debate with a jQuery Teaser Splitter
Category: feature » bug
Priority: Normal » Critical
Status: Needs review » Reviewed & tested by the community

I tested with Opera too, and works.

Those who need the HTML comment, get it back. blogapi really shows the problems with the <break> tag -- if my blogapi client posts the same to several sites (this is a real thing, I have even written a Drupal module which does exactly that!) then embedding an HTML comment for Drupal does not break the other systems, but a pseudotag simply does not work. I marked this as a critical bug because in current HEAD blogapi breaks are the old comment tags and the pseudotag does not work there.

Those wanted a simpler solution for making teasers, they get it too.

If pseudotag could be committed past freeze then this shall also get in.

Morbus Iff’s picture

UnConeD: please gimme a .mp3 of the music and More Info.

ericG’s picture

I just don't understand how you can spend this much time building code to simply justify your refusal to compromise with the majority of developers that have an opinion on this issue.

-1 for this change, no matter how cool it might look.

you have still failed to fully justify your opinion that the current break tag as html comment is not usable enough, and you have also failed to fully justify your opinion that the new tag is a gain in usablility

chx’s picture

ericG and all -- there is no need to debate the pseudotag over HTML comment. That debate is closed, because blogapi.module still uses the old one (HTML comment) and the new one (pseudotag) just won't work. It's because of blogapi and not because I like or dislike the new tag that we must roll back.

So, even if it's decided that this change is too much, the rollback portions of this patch should be extracted and committed and then in D6 we can get this one in.

moshe weitzman’s picture

Status: Reviewed & tested by the community » Needs work

are you guys actually testing the patch? i get a 404 on teaser.js which was not included. or i am missing something. feel free to set this to rtbc if i am mistaken.

how does this interact with the teaser pref at admin/content/node-settings?

in general, this is a lovely solution to a difficult issue.

@ber - i wish you wouldn't use superlatives when you are uninformed. this isn't a structural patch. it rolls back the [break] as you and many others have advocated. further, it adds just the right amount of UI sugar to solve the problem in a far better way.

i think this is a valid exception to the code freeze. code freeze is a guideline, not a golden stone from the gods.

ontwerpwerk’s picture

Status: Needs work » Reviewed & tested by the community

#8 - the break tag change is also reverted with this patch
the whole idea is that what the break tag does not matter for end users anymore (as long as they have javascript in their browser)

ontwerpwerk’s picture

Status: Reviewed & tested by the community » Needs work

whoops, accidentally changed the setting

ericG’s picture

Status: Needs work » Reviewed & tested by the community

sorry if my comment was off topic for this issue, maybe I was responding more to the title of the issue "Solve the break tag debate " than the patch.

-1 for forcing users to have javascript to do correct editing. this is a total violation of usability standards for the disabled, from my understanding.

chx’s picture

Status: Reviewed & tested by the community » Needs work

While the solution is sound, there are several problems with the patch: a) teaser.js is missing b) it is somewhat an API change with changing all body_filter to body_field needless. This breaks already ported modules form_altering that part totally needlessly.

chx’s picture

note that this patch does not force JS as Steven notes:

Any existing node is automatically edited in its split form, if it had a break tag before. The JS scans the textarea for the break tag, and splits it if found. That way, it still degrades gracefully: the form still contains the unaltered text with break tag.

another note -- how could I test with Opera if there was no teaser.js in the issue? Easy, I tested on Steven's test site which is currently off (I presume it's his notebook and he is asleep).

chx’s picture

Version: 5.x-dev » 6.x-dev

The Drupal 5 release manager have spoken: http://lists.drupal.org/archives/development/2007-01/msg00159.html I will reopen my other issue and post the rollback.

Gábor Hojtsy’s picture

I leave debating code freeze reasons to others. What is problematic for me is the 'split at cursor' text. If you are not familiar with the teaser concept, you don't know what happens... Why would you split? Maybe 'split teaser at cursor' is better wording, since the join button is already titled 'join teaser'.

killes@www.drop.org’s picture

Nice stuff, but to me this is clearly for Drupal 6. I'd either rollback the issue or keep it, but please not this patch that late in the game.

NikLP’s picture

I'm sticking my neck out even speaking on this thread (given the company I'm in and that I know practically nothing) but...

Am I correct in saying that there is not a teaser field available in most content types? I can't see anything pertinent, and have read issues pertaining to this matter, specifically in relation to CCK content types I believe. If this is correct, would the ideal solution not be to just add a teaser field to the existing node types (I'm donning my flame-proof vest as I speak) and be done with all this? I seem to have come across several points of view on this matter here, both positive and negative.

I realise this would likely not make v5 "RTM", but perhaps for the next version? An update script would not be hard to implement to convert existing in-body-field tags to separate teaser/body fields. At that point, the jQuery "magic" (or "bad-gic"?! ;) ) would be simpler to implement as it would be a matter of coding against two existing static fields. This would surely solve both the data and usability problems, and also reduce overheads associated with extraction of the teaser from the body tag in places where body is not simultaneously required?

I'm at your mercy on this, and I fully appreciate "code-freeze" issues. Some things are worth waiting for, and those things should be done right, IMO. That is all.

PS, sweet tune on the vid there.

kbahey’s picture

I like what I see. Really nifty, but have reservations:

- As many have said, too late in the release cycle to put a major usability change.

- What if JS is disabled? How does this degrade?

- Does this leave room for third party WYSIWYG editors do do things differently if they want?

Steven’s picture

FileSize
15.62 KB

Here's a patch with teaser.js included.

Steven’s picture

kbahey: please, don't hesitate to stick your head in a microwave oven, and grill until satisfied. Both your questions are answered in my original description.

kbahey’s picture

I see the answers to both, but no detail on #3. My bad.

You have a point for the microware. Should I use form_alter() to turn it one before I stick my head in?

Steven’s picture

Title: Solve the break tag debate with a jQuery Teaser Splitter » Add jQuery Teaser Splitter
Status: Needs work » Needs review
FileSize
13.68 KB

Rerolled after break tag revert.

kbahey’s picture

Status: Needs review » Reviewed & tested by the community
FileSize
13.59 KB

OK, so I put my head in the microwave for some time. (That felt good, thanks Steven, I now know what do when I get a headache next time!).

Then I applied the latest patch (#24), and did some testing.

Here is what I found.

- Does not work in KDE/Konqueror. The text in the top textarea gets eaten. This is not a big deal given the market share for Konqueror. Pity Safari is based on Konq's engine.

- With Firefox 2, and TinyMCE installed (5.0-dev), the "Split at cursor" button is still there. Clicking the button causes the top textarea to appear and then disappear immediately. Looks funny, but does not seem to break anything major.

- I added a settings to turn this feature off, with the default being on. This makes it 100% compatible with what we have now if someone wishes it to be so. See attached patch.

So, that only leaves whether this is too late in the release cycle or not. With the setting above, that should not be much of an issue. Right?

Steven’s picture

-1 on the setting. Modules like tinymce should set #teaser to null in form_alter or elements.

Steven’s picture

Status: Reviewed & tested by the community » Needs review
FileSize
12.38 KB

The idea behind this issue is: improve the usage of teasers in Drupal. So, I've added another enhancement: support for teasers that are not part of the body. See attached patch.

It adds an additional checkbox to the form, "include teaser in body", next to the splitter button, which defaults to TRUE. Note that this checkbox is present even without JS and is perfectly usable with the manual break tag.

Note that instead of saving the value of the checkbox, I determine it based on the contents of $node->teaser and $node->body. This means that it can transparently work with existing sites that have been using excerpt module (otherwise, it might start eating teaser content). So, no upgrade path is needed. It also means that it can deal perfectly with custom module teasers, and that no action is required from module authors, no matter what exotic tricks they pull.

The flow after this patch is (when editing a node):

  1. Form API outputs a form with a

    tag in the textarea, separating teaser and body. If the teaser was chopped off from the body, it is restored here in the body (so non-JS users see a single field).

  2. jQuery splitter notices the break tag and splits the textarea.
  3. User edits form and submits
  4. Form API #after_build takes the teaser from the separate textarea, and merges it into $node->body.
  5. The values are processed and validated.
  6. Node_preview or node_submit (whichever op was taken) now calls node_teaser() to generate/extract the teaser from the node body. If 'include teaser in body' was not checked, the body's beginning is chopped off and saved.

Note that from Node API's point of view, the JS feature does not exist. It always sees the right values in $node->teaser and $node->body, as if the break tag was manually typed.

I also took the liberty of centralizing the code that generates the node body field. It is called by blog, book, forum and node module.

Steven’s picture

webchick’s picture

Ooooo!!!!!

I will try and test this tomorrow!

profix898’s picture

Really nice work from what I see from the screenshots. +1 on such a feature in core.
But on my install it doesnt work properly :( When I go to node/add/page I get a page as documented in the attached screenshot. I already cleared my browsers cache and forced a reload of that page, without success. I can see the body textfield, but I also see a disabled teaser field. The split/join button is missing but the 'Include teaser in body' checkbox is visible. This is using FF 2.0.0.1 (win32) with todays HEAD (patch applied cleanly).

profix898’s picture

FileSize
9.01 KB

... and the screenshot .... Sorry

Steven’s picture

You probably need to shift-refresh.

stBorchert’s picture

FileSize
45.26 KB

Hi.
#28 looks good.
But wouldn't it be more informative if the teaser-box is labeled with "teaser" (and the body with "body") instead of only display one label (see attachment for example)?
I know that the upper box is the teaser but think of a "normal" user.

Just a question. If youre answer is "no" I'm as happy as now :-)

profix898’s picture

Patch in #27 looks good, except for a missing teaser.js in the patch .... (actually thats why it didnt work for me). Otherwise this looks like a very nice feature to be included in Drupal core.

webchick’s picture

Status: Needs review » Needs work

Ah-ha. Marking code needs work because of missing js file. Thanks, profix!

webchick’s picture

Also, stBorchert's suggestion looks good to me

bdragon’s picture

(subscribing)
For the record, you can use "cvsdo" to do pseudo-cvs-adds without touching the repository.
http://viper.haque.net/~timeless/redbean/cvsdo

Steven’s picture

Status: Needs work » Needs review
FileSize
14.92 KB

I don't think separate labels are a good idea. They destroy the visual proximity and relation between teaser and body (namely: that the body may include the teaser). It also does not help with degrading the JavaScript, as there is ambiguity with the meaning of a blank teaser textarea (as there is no way to hide it, like with JS).

Patch rerolled with teaser.js.

ChrisKennedy’s picture

The problem is that when splitting into two textareas, the "body" label is adjacent to the teaser area, rather than the body area. This is confusing. Why can't the labels be dynamically inserted and removed with jQuery?

Morbus Iff’s picture

CK: the teaser is /literally/ part of the body. It will get displayed on full node views.

ChrisKennedy’s picture

FileSize
3.36 KB

@Morbus: try out Steven's latest patch, which makes it optional as it should be.

I agree with #17 that the button should be changed to "split teaser at cursor" to be less ambiguous.

Minor: many of the code comments are missing periods.

On FF2 and IE6 the button and checkbox show up above the "body" label, and the teaser's grippie is a few pixels too short - see screenshot.

Overall it is a great solution to the general problem of teasers.

Steven’s picture

Chris, you are definitely missing CSS. Always shift-refresh please.

ChrisKennedy’s picture

I always test with shift-refresh, but I didn't realize that css aggregation was turned on in my test site. That fixed the button+label placement, but not the grippie shortness.

Stefan Nagtegaal’s picture

What happened with this? It surely rocks ass!

If no-one does update the patch, I'll see what I can do in the upcoming days...

drumm’s picture

Category: bug » feature
ximo’s picture

I support your initiative for a more user friendly alternative to the teaser tag, and this looks very promising! I only think it could be more user friendly for novices who have no understanding of body, teaser, splitting - what they are and what they do. I think what's most logical for a user would be one field for the Teaser and one for the Body.

Here's my suggestion for joinging and splitting the Teaser and Body fields:
Below the Teaser field there would be a button labeled "Join teaser with body", that when clicked merges the text of the two fields, leaving only the Body field. The same button would then be labeled "Split teaser at cursor" (or why not something easier to grasp like "Make text before cursor the teaser"?). When clicked, it would return to the initial state; a Teaser field and a Body field, the Teaser field now containing the text extracted.

Ideally, the code would remember the previous "state". I believe a lot of users never write teasers, and then there are plenty who always do.

My 2 useability cents..

BioALIEN’s picture

Subscribing to this issue.

dmitrig01’s picture

subscribing

jacauc’s picture

Just tracking the issue. +1 though!

drupalnesia’s picture

Title: Add jQuery Teaser Splitter » Drupal all ready has teaser and body

Steven,

Your patch is useless (since the real problem is in the Drupal strategy to handle teaser and body), because Drupal already has 2 fields: teaser and body. What happen right now is the Drupal body-field also contains teaser-field. So, I suggest to remove the "teaser value" from body-field. Mean: body is body and teaser is teaser!

This approach will effect the edit form with 2 textarea: teaser and body. Users must entry the teaser value manually but this will give us very flexible and very ACCURATE teaser.

You can have teaser for every nodes with this great feature:
- teaser for every node has its own length
- body not contain repeated value from teaser! Great!
- no need additional module and/or patch (like you provided and some module provided)
- solve the break tag problem
- solve wrong break teaser by Drupal, i.e: if you put image or flash file or table at the first section of your body then Drupal will be wrong to break you article as teaser, so you need manually enter break tag, then... you must do PREVIEW AGAIN to make sure the teaser nicely show on your page

Sorry if I am wrong because I just see that Drupal node_revisions already contains teaser and body fields! I think this come from CCK but after I do recheck I found that this is come from original Drupal installation, very interested.

Another CMSs follow this approach as I described above, why not Drupal?

Gábor Hojtsy’s picture

Title: Drupal all ready has teaser and body » Add jQuery Teaser Splitter

Drupal-id.com! Do not modify the title!

ximo’s picture

#50:
I've also asked myself why we have the break tag. To me it feels like a hack and it's confusing to many. Having separate teaser and body fields (in the database and visually in the node edit form), without duplication of the teaser in the body, is a much cleaner approach in my eyes. I'd be interested to hear opposing views though.

BioALIEN’s picture

Well, to add to the discussion here, with the convergence of CCK + Core in Drupal6 - one can even remove teaser and body all together easily from their content-types, or change the order of display for title then body then teaser etc.

But let's not bite Steven's head, this is an issue to discuss a patch that he's created to reach a short term resolution. Ideally, we want to recode the way body and teasers are done - and the ongoing efforts to bring CCK to core is probably the best chance of getting this resolved in the process.

Steven’s picture

It's a matter of usability. The majority of sites out there will not use a separate teaser. By providing a separate field, you force them to copy/paste the content and keep it in sync whenever they edit it.

This is duplication of information, and unnecessary. Any way, the current patch provides the best of both worlds. Most users will never see the break tag again.

drupalnesia’s picture

It's a matter of usability. The majority of sites out there will not use a separate teaser.

Right. But the original Drupal node_revisions table contains 2 fields named as "teaser" and "body".

By providing a separate field, you force them to copy/paste the content and keep it in sync whenever they edit it.

This is duplication of information, and unnecessary. Any way, the current patch provides the best of both worlds. Most users will never see the break tag again.

I just see and see again the Drupal node_revions table has a field named as "teaser" already there!
So, Drupal already provide separate field for teaser purpose.

But the Drupal original "body" field also contain value form "teaser" field. This is a duplication as Steven says, agree.
Please take a look again to Drupal node_revisions, maybe I see the wrong table ???

The idea is provide teaser and body in separate textarea because there are already separate in Drupal table. What makes difficult is: body-field contain teaser value, so, this will affect the Drupal core.

Steven’s picture

FileSize
12.41 KB

The vast, vast majority of sites do not need separate teasers. If they did, excerpt.module would be in core by now. The current patch provides the solution for everyone, and is a thousand times more usable than the old behaviour, or than just two separate textareas.

Still applies with fuzz, but resyncing with head.

rconstantine’s picture

Steven, I'm wondering if you can add something to your patch that may help dispel some confusion for users of what that grippy is for, or even what to do about their teaser. First, eliminate the 'join teaser' and 'separate at cursor' button altogether. Second, put a label on the grippy itself of some kind indicating that above it is the teaser and below it the 'rest of' the body. Next, treat above and below the grippy as one field for the purposes of typing so that as one fills the top pane, the cursor automatically moves to the bottom pane so one can continue the entry. Additionally, if the user grabs the grippy and pulls up or down, the text should be bumped from one pane to the other. So the teaser will always appear full if there is any text in the bottom pane -- or if the grippy is pulled all the way to the top, then all of the text is below it and there is no teaser. Then simply worry about any settings the site admin has set as to whether or not to save the teaser or roll it in with the body. I think you already have something in place behind the scenes for the case when teasers aren't used, but I'm not sure whether that could be used with my idea or not as I haven't looked at the code yet.

Anyway, from a UI point of view only, I like what you've done and I think my proposal would finish it off. As for the implications of code changes and whatever, I'm going to stay out of that.

Steven’s picture

How would you implement that in a cross-browser fashion? They can't even get WYSIWYG to work properly.

Let's stick to realistic goals.

chx’s picture

Status: Needs review » Reviewed & tested by the community
FileSize
11.03 KB

it is exactly how a teaser selector widget should work.

in general, this is a lovely solution to a difficult issue.

It surely rocks ass!

Can we get this into core please and move on?

The attached patch is a simple reroll against HEAD.

chx’s picture

FileSize
11.03 KB

it is exactly how a teaser selector widget should work.

in general, this is a lovely solution to a difficult issue.

It surely rocks ass!

Can we get this into core please and move on?

The attached patch is a simple reroll against HEAD.

Dries’s picture

I tried testing this patch, but it doesn't seem to work (despite the shift-reload and flushing cache tables).

No matter what I do, the top-most textarea remains grayed out and un-selectable. It doesn't have a form title either. And the checkbox doesn't seem to have any effect.

I must be missing something here, but I tried getting this to work for 10 minutes. Thoughts?

Steven’s picture

FileSize
12.41 KB

teaser.js was missing from the reroll.

Steven’s picture

FileSize
14.98 KB

Ack, I still uploaded the wrong file :/.

Dries’s picture

I tried this patch and I was confused by the checkbox. I showed it too my wife, and she didn't understood it either. I think the addition of the checkbox introduced a usability issue. What do the others think of this?

Steven’s picture

chx already summarized some weighty opinions above.

Dries’s picture

Are you referring to comment #60? chx posted about 15 comments in this thread.

My question still stands: what does 'use teaser in body' mean? Maybe it can be re-rephrased to something more explanatory? Does it mean 'auto-extract teaser from body'?

(Note that my wife is actually using Drupal at work. It's real feedback from a real user.)

Steven’s picture

Please tell me you're not too lazy to hit CMD-F and type 'checkbox'.

kbahey’s picture

Steven

There is no CMD key on my keyboard. Would putting my head in the microwave help?

;-)

(Sorry, couldn't resist)

chx’s picture

For that checkbox, I think it'd be more intuitive to say 'store a separate teaser' than saying the opposite.

Steven’s picture

Assigned: Steven » Unassigned

The nice version

I'm tired of my patches ballooning out of control with endless threads where people 1) post questions whose answers were already posted 2) make wild suggestions without thinking about the implementation for one second and 3) go off topic.

Such comments harm the progress of an issue rather than helping it along. Long, pointless threads are known to scare people away, and repeated questions diffuse rather than focus information, making it harder to review.

This needs to stop if any sort of useful improvement is to make it into core. The problem is not that there aren't enough contributors, but that the number of people who do complete patch reviews beyond their immediate turf can be counted on one hand. We have a giant patch queue filled with things that need looking at.

How I really feel

*snipped*

chx’s picture

Status: Reviewed & tested by the community » Needs review
FileSize
13.48 KB

OK, let's put code where my mouth is. I really believe it's much easier to understand what it means to 'store a separate teaser' than the opposite of it.

chx’s picture

FileSize
13.49 KB

Let's hope this one is less broken.

victorkane’s picture

Status: Needs review » Reviewed & tested by the community
FileSize
81.99 KB

Installed clean Drupal 6 (HEAD) system.
Created several story content types.
Edit as usual.
Applied patch successfully.
Edit of old story or creation of new story now shows "Store a separate teaser" (*********** shouldn't that be "store in a separate teaser"?)" checkbox and Join teaser button.
Works (see attached screen captures).

chx’s picture

So Dries, please choose between _5 and _7 they essentially differ in the wording of the checkbox (and of course, the actual behaviour is inverted).

Dries’s picture

Please tell me you're not too lazy to hit CMD-F and type 'checkbox'.

Geez, Steven, stop being cranky. I spent 4 hours reviewing patches today. I can provide UI feedback without looking at the code, can I? Do you expect my wife to inspect the code too?

Chill35’s picture

While you you're all busy with this, why not add the option in the admin panel to put a readmore link INLINE with the teaser.

Drupal, through node.module, closes in the teaser in a block element (as it should) : it makes it hard to add a link INLINE, like this :

This is text, more text, bla bla bla bla. Cut. read more »

Chill35’s picture

By the way...

I support your initiative for a more user friendly alternative to the teaser tag, and this looks very promising! I only think it could be more user friendly for novices who have no understanding of body, teaser, splitting - what they are and what they do. I think what's most logical for a user would be one field for the Teaser and one for the Body.

+10 for that.

jacauc’s picture

@Chill35: That's what the read-more tweak module does: http://drupal.org/project/ed_readmore
Let's not request further features. Don't think it's the time now after 77 comments.

If you really think this should be in core, create a seperate issue for that, but I think the contrib module readmoretweak is perfectly acceptable.
Just my opinion :P

Steven’s picture

Geez, Steven, stop being cranky. I spent 4 hours reviewing patches today. I can provide UI feedback without looking at the code, can I? Do you expect my wife to inspect the code too?

Um no. I was referring to the text above when I posted the checkbox patch and said what it does so that you wouldn't have to read the code.

"support for teasers that are not part of the body"

i.e. extracts vs abstracts, excerpt.module in core, whatever you want to call it. It's not rocket science.

dodorama’s picture

FileSize
25.77 KB

Applied teaser_5.patch and teaser_7.patch but they both don't work in Safari 2 (Mac Os X 10.4.9) (it looks OK in Firefox even if the button isn't well aligned with the textarea).
On Safari: There's a strange grippie on top of the body textarea and the join/separate button isn't there. And the grippie doesn't work.

See screenshot

P.S. I agree with Dries that the checkbox can be confusing. Maybe that feature should remain in a contrib module since:

The majority of sites out there will not use a separate teaser.

Steven’s picture

I developed this feature on Safari 2 on Tiger too. Are you sure you applied the patch correctly and have no stale CSS or JS caches sitting around in the browser or in drupal? It works perfectly here: http://acko.net/dumpx/teaser.png .

As for the firefox misalignment: it's a known firefox bug. It looks fine in all the other browsers. This is a detail that can be resolved later if it remains a problem.

BioALIEN’s picture

I didn't want to take this off topic or drag on about the implementation so I created a discussion node in the forums:
http://drupal.org/node/133702

This is the result of a considerable amount of time thinking of the whole process and asking a few non Drupal users.

chx’s picture

The jQuery splitter itself works without the checkbox fine. If neither _5 nor _7 wins the turf I hereby volunteer to roll a patch which removes the checkbox so that the splitter itself can get in. Dries?

dodorama’s picture

@Steven
My bad. It was Safari cache. I'm sorry.
Another minor issue. If I hit separate at cursor an than I join back an empty row appears between teaser and body.

The more I use it the more it looks a really stylish solution to break the body. Visually separate teaser and body is for sure more usable than having to use a weird tag. Once you're comfortable with the concept of 'teaser' this is really handy.
But I still think with should apply the patch without the checkox.

Steven’s picture

The checkbox is IMO a handy feature... for one thing, hacking this in with excerpt.module would complicate the code a lot. Having it be part of the core teaser functionality is just a lot handier and cleaner. It is unlikely any other module other than excerpt.module would do radical things with the teaser, so providing a whole hook just for one module would be a bit wasteful.

The main goal of this patch is to turn teasers from second-class citizens to prominent tools. The relationships between teaser and body are indeed much more visual now, and I think excerpts belong there too. There is a specific audience for the kind of sites that need this (mostly literary / text-heavy sites), and it makes Drupal core look a lot more attractive to them.

Dries’s picture

If we remove the checkbox (and its functionality), I think this patch is RTBC. We can than worry about the checkbox in round #2. Thanks chx. :)

Steven’s picture

The checkbox works. It's a useful feature, that many people have requested for core before. It's usable. It's elegant. It puts all teaser related controls in a single, visible place.

Usability is about mental models and mapping them to the UI. For a lot of people, separate teasers is the way they view their text writing process. By adding the checkbox, those people can now too map their mental model clearly to a default Drupal node form rather than being confused after they submit something for the first time and see repeated text. Existing users gain an ability, and may even start writing better abstracts.

Didn't all the old blogging apps always have separate teasers? I thought that was one of those annoyances we had to work around in Blog API.module.

No patch can save the world, not even a Drupal core patch. Why are we suddenly usability nazis about a feature that offers an otherwise huge benefit and makes node editing more flexible and elegant out of the box?

dodorama’s picture

The main goal of this patch is to turn teasers from second-class citizens to prominent tools. The relationships between teaser and body are indeed much more visual now, and I think excerpts belong there too. There is a specific audience for the kind of sites that need this (mostly literary / text-heavy sites), and it makes Drupal core look a lot more attractive to them

This is true. For people using drupal as a blog/literary tool the checkbox is infact a great tool to fine tune the display of their post. And it is true that (until CCK will make his way to core and a file management API will let us do media right) what Drupal offers to end users, out of the box, is the management of text content. Therefore let's put the checkbox in and go on!

BioALIEN’s picture

Guys, the checkbox needs to live in the workflow section where it rightfully belongs.

Steven’s picture

-1 on moving the checkbox to workflow. That would move it away from the objects it affects.

webchick’s picture

I do see the UI concerns people have brought up... though I haven't shown this to a new user yet, by looking at the screenshot at http://acko.net/dumpx/teaser.png I can see a couple of areas where it could be confusing.

However, I think the best way to handle this is to post it to the forums and let our users do some kind of annotated screenshot stuff to illustrate how this could be improved from their eyes. This would best happen after the patch goes into core, so they can test it themselves in the dev tarball rather than having to apply a patch, which raises the barrier.

+1 for this baby being committed, as-is, with the checkbox. And let's do community involvement to get it tweaked that extra .001%.

Dries’s picture

I'm not opposed to the checkbox, but it needs to be made easier to understand. I've shown it to my wife (who uses Drupal), and she has no clue what "include teaser in body" really means. More importantly (terminology aside), she doesn't know what effect it has on her posts? In other words: it doesn't fit her mental model, she don't know what to do with it, or what effect it will have on her posts. Maybe I should tell her and others to 'CMD-F' this issue? ;-)

And quite frankly, I'm not 100% sure I understand the checkbox myself.

Maybe 'repeat teaser in body' is slightly better?

This is a good patch and is extremely likely to go in. You don't need to fight for that, so there is no way to be frustrated or whatnot. However, that doesn't mean we can't discuss the UI, that we can't brainstorm about it, or that we can't show it to relatively newbie Drupal users, ... I mean, we're trying to make this patch better through discussion and brainstorming.

This patch is _all_ about usability, so let's make sure it is 100% usable ...

Dries’s picture

I showed it to yet another newbie Drupal user and she responded with: "Huh? I don't know what a teaser is? Oh, and [while pointing to the new button] here is says 'teaser' as well. No, I don't understand it."

If you don't believe me, try showing it to someone who is not a CMS or blogging expert ...

Dries’s picture

I think this is a summary of the patch's effect:

1. People who come from Wordpress or what not, will be able to map this onto their mental model. These users are typically 'experts' (though they might not be HTML or Drupal experts). For them, this patch is likely to improve the user experience -- at least, if they depend on this kind of teaser functionality. (Not all of them do.)

2. People who are new to CMSes, will _not_ be able to map this onto their mental model and will not understand what this functionality is used for. These users are typically 'newbies'. For them, this patch adds to the confusion and learning curve. They are going to state: "Drupal is difficult to understand and use.". The patch could be considered a regression for absolute newbies.

Does that make sense?

rconstantine’s picture

I'm relatively new to Drupal, and although my last comment in this thread was apparently crap, I'll open my mouth and try to add something anyway.

First, can't 'teaser' be called 'summary' or maybe even 'teaser/summary' and eliminate the confusion? I think everyone should understand what a summary of their entry is or what it might be used for.

Next, why does the teaser have to be visibly separated from the body? Why can't a checkbox to the right of the body ask 'Do you want a summary?' and a text field (or dropdown with set values) ask 'How many characters long?' (which will be disabled if the above checkbox is unchecked). Then, once the info is filled in, give some indication within the body of where the summary ends. And if a person really doesn't want their summary to be the beginning (teaser) of their body, they simply write one thing before the visual indicator like a synopsis and start their article after it.

I do realize that the separation of two fields with the grippy bar is supposed to accomplish the same thing, but I don't think does. The visual indicator could be an icon, or maybe highlighting all of the teaser text with a yellow background. Sounds like a jquery thing.

Steven’s picture

rconstantine: pie in the sky. To do any sort of styling, icons or markup in textareas, you need to convert it to a full blown wysiwyg editable piece of HTML. That's how browsers work. This patch solves a specific need: to replace the clumsy break tag with a clearer and more usable visual marker.

I'm all for renaming "teaser" to "summary" though. How about "Show summary in full view"?

Steven’s picture

Status: Reviewed & tested by the community » Needs review
FileSize
17.95 KB

Here's another thing that nobody seems to have noticed... there is the rather useless combination in the patch of the separate teaser checkbox with an auto-generated cut-off point (i.e. no user-defined break tag or split).

This doesn't make much sense as you have to guess where the teaser will end. The checkbox should only be visible if you actually have split the textarea.

The attached patch rewords the checkbox and button label to use "summary" and "show summary in full view" and hides it for joined textareas. For the non-JS version, it is always there (nothing to do about that).

This also has the benefit of hiding the trickier teaser UI for those users who don't go looking for it (i.e. that don't click the button).

I also fixed that Opera bug. Not sure why that suddenly got triggered. And I used a wrapper div to work around that bug with Firefox not setting margins on buttons.

Everyone happy now?

http://acko.net/dumpx/teaser.png

VM’s picture

I have a suggestion for the wording issue of the checkbox, if i may without sticking my nose in.

what about the word merge ? merge with body ..... split from body ?

VM’s picture

sorry i meant the button name... not the checkbox.

Dries’s picture

The wording of the text in Steven's last patch is a definite improvement. Fixing the checkbox visibility is a definite improvement as well. That takes care of the usability issues that I put forward. (Still have to test the patch though.)

webchick’s picture

Latest patch looks great.

Tested in Firefox 2.0.0.3, Safari 2.0.4 (419.3), Opera 9.02 on Mac. I can check on IE later, but if someone could get to it first, that'd be great. :)

At one point I had this weird flukey thing in Safari where when I hit the button it would expand and then immediately contract, but when I attempted to write up reproduction steps, I couldn't get it to do it anymore. So probably not a big deal. :)

ximo’s picture

FileSize
130.76 KB

The patch is really smooth, the more I use it the more I like it! Smooth like butter.

The new wording makes it easier to grasp for non-technical users, but I think one can take a slightly different approach to make it even easier to grasp. I think the concept of teasers and how they relate to the body is what confuses many.

An image says a thousand words, so take a look at the attached screenshot to see what I mean. This is basically what I suggested earlier, only then I didn't get the point across then (my bad).

misty3’s picture

As an enduser and in my humble opnion spilt summary at cursor or merge with body etc
are excellent but unfamiliar stuff to me and the friends I discussed with - I will rather have some admin defined options like collapsible ( collapse on or off ) text area box for non-automatic teaser for vistors to my site ......

My suggestion :

Teaser Options which admin can set ( various settings for various node types ):

administer » settings » content types » a specific content type ( eg. blog ) » workflow

Teaser or summary or intro or whatever it is called

default options
radiobuttons - choose any one
disabled
enabled , automatic teaser [ first 'n' words from content ]
enabled, teaser text area box [ separate stuff from main content ]
enabled , automatic teaser with thumbnail picture [ 1st image ]
enabled, teaser text area box with thumbnail picture [ 1st image ]

if teaser text area is enabled
radiobuttons - choose any one
keep the text box above the body text area
keep the text box below the body text area

Collapse teaser text area option
check box

if teaser text area is enabled but user keeps it empty
radiobuttons - choose any one
automatic teaser
node title
full post

if teaser with image
radiobuttons - choose any one
left align image with wrapping text
right align image with wrapping text
image ,line break, then text
text, line break, then image

Collapse teaser text area option
check box

How many words if automatic teaser
text(number) input or number dropdown

What code if custom break wanted [ rather than 'n' words ] in automatic teaser
text input
example code <--teaser-->

Show Teaser on specific pages:
radiobuttons - choose any one
Show on every page except the listed pages.
Show on only the listed pages.
Show if the following PHP code returns TRUE (PHP-mode, experts only).

In addition to this an access control may be added for teaser textarea boxes eg. allowing only admins or certain blogger role to have this. though if we go by 'per content type' this may not be necessary.

Some frills ( or features in some cms-es ) can be adding "forward" and "print" link to teasers.

Best regards

webernet’s picture

FileSize
15.44 KB

Tested in Firefox 2 and IE7 - seems to be working fine.

Rerolled without theme .info files.

Dries’s picture

ximo: I think your screenshot is a small but subtle improvement. I like it, but would be interested to learn what others have to say.

misty3’s picture

Dries, will like to know what you think of the workflow mentioned above,
many ordinary drupallers will feel extremely comfortable and will find this useful
in my humble opinion.

http://drupal.org/node/133702#comment-219708

Best regards

webchick’s picture

@misty, I could see that being a useful contributed module like "SuperTeaser" or something... but our goal in core is actually to provide *fewer* configuration options, and instead satisfy the "90% case" -- meaning that 90% of sites out there are going to want functionality like X, and if they want anything over and above that, they should turn to a contributed module.

misty3’s picture

Thanks a LOT, webchick.

I agree with what you say.

At the same time, Drupal follows logical workflow, which at this time has already a "lot" ( but actually sufficient ) of options with workflow already inbulit into core [ see any workflow of any content type ]. So not much over "fewer" will be added in this way in my humble opinion.

Also it is very logical to have the ability to set separate different settings of teaser for different core node types - the entire thing can be made into a collapse-able stuff to avoid clutter, if needed.

[ BTW - what 90% need is arbitrary, 9 years ago there was hardly any blog, now there are 90% ... one can always be path setter, in this case , with teaser and open up new ( good ) vistas
asTeasers are SO important as those are the very essential stuff that gets displayed first in the eyes of the visitors ]

Best regards

webchick’s picture

What I'd say is that if you feel strongly that such configuration should be included, you should go to http://drupal.org/node/add/project-issue/drupal and create another feature request for it... maybe something like "add more robust teaser configuration options," and include your synopsis as well as any other evidence you can cite (how other CMSes are handling this, etc.) to support your idea. Then we can have a proper discussion about how best to implement your idea in core.

However, this issue isn't about changing the way teasers work; only about making the interface for adding teasers more intuitive to people, so we want to be careful not to confuse this primary issue with other suggestions and ideas. As you can see, this issue is already well over 100 replies... if we start adding in how we should handle teaser configuration from an admin point of view, it could go well beyond that. :) So let's break your idea into a separate feature request, and discuss it over there, and leave this one just to the new interface.

misty3’s picture

I fear that I will be bordering on 'troll' if I carry this !
You are right that a fresh request should be started.

Though I feel that what I was suggesting is that
"new interface thing" only which you say as
"leave this one just to the new interface."

In my humble opinion
the splitter and the lingos used like "summary" and other
instructions arenot very intuitive, does add to learning curve
and being js oriented may have issues with current or future gens of
wysiwyg editors. I do not agree to
"And this should also keep everyone happy." :-)

If "our goal in core is actually to provide *fewer* configuration options"
I will certainly say to Dries and you that what we have already i.e.
like a tag to make a manual length of teaser is quite fine and sufficient.

Best regards

webchick’s picture

Yeah, this is getting really off-topic now. So please, let's take this discussion to another issue.

The comments here should center around:
a) whether or not the latest patch works in various browsers
b) UI suggestions for the current patch (for example, http://drupal.org/node/107061#comment-225469)

shunting’s picture

At the risk of being forced to stick my head in a microwave oven:

1. The body/teaser concept is not intuitive to novices. Think of someone who is coming from the blogger world, where there is no such concept.

2. The body/teaser concept is one thing; two fields, one for teaser, one for body, is quite another.

(a) If you've tried Scoop at Kos, you know that separate fields cause their own problems -- two updates, two chances for error. Yes, I know this implementation isn't Scoop crude, but as the writer of many thousands of posts, as a opposed to a developer or a database designer, I know that

(b) to a writer, the boundary between teaser and body is fluid and changing. I might start out with one idea for the teaser, and then end up with something entirely different at the end of the writing process.

3. Therefore, -10 for the idea of separating teaser and body into fields as proposed in this elegant implementation.

This is content, prose. It simply is not fielded data, and a dragger bar, though it be elegantly implemented, buys into a metaphor that's going to be wrong for a substantial portion of your user population.

4. In fact, the break comment, though implemented in an ugly way, is the right metaphor, because the distinction between teaser and body is, indeed, a BREAK point in a constantly changing flow.

5. Since I am not a JS guy, let along a JQuery guy, I can only suggest -- brainstorming here -- that the solution might look more like:

(a) A button for toolbars that inserts a cute little icon where the break is -- I don't know if buttons in JS textareas can be made draggable, but that would be great -- combined with

(b) Some sort of dynamic preview function that shows a thumbnail of how the post splits given the position of the cute little icon. (If it were dynamic, I wouldn't have to push the preview button to see how my teaser reads, which would be a win.)

OK, I'll got stick my head in a microwave there. Sorry to make a long thread longer, but I didn't here the position of the content creator being advocated for.

shunting’s picture

I forgot to say:

(5)(a) and (5)(b) are independent. The dynamic preview function might be a win for novices even if the BREAK comment were retained.

Chill35’s picture

(a) If you've tried Scoop at Kos, you know that separate fields cause their own problems -- two updates, two chances for error. Yes, I know this implementation isn't Scoop crude, but as the writer of many thousands of posts, as a opposed to a developer or a database designer, I know that

In Drupal, teaser and content are actually 2 different 'fields'/chunks of HTML data to update in the database.

misty3’s picture

I missed out Dries comments in this thread #93,#94

http://drupal.org/node/107061#comment-225018
http://drupal.org/node/107061#comment-225019

and I agree with those :)

If our target is not to make things complex or non-intuitive
I think what we already have is sufficient. At the max, we can make
an admin-optionable button-addition to the text-box, which when clicked
inserts whatever_the_teaser_tag_is , instead of having to manually
type the code words.

If I read right, Dries saying that this js thingy splitter is certainly going
to be part of the core is what I think best avoided or made an admin-optionable
thing for the visitor-user. Though I strongly beleive this adds to confusion
and complexity.

Best regards

Steven’s picture

FileSize
15.47 KB

Chill35: We in fact get both the advantages you describe, as well as the better editing interface. I deliberately kept the old approach in the database for three reasons:

  • It makes the non-JS version backwards compatible and requires no database updates. The old interface is a bit crude, but works. It is also visibly documented after this patch.
  • It gives external APIs a simple way of marking the teaser, if the client does not support a separate field (e.g. RSS).
  • It means modules can just print/use $node->body or $node->teaser without having to worry whether to display one or both. The database implicitly stores the user's choice for separate teaser or not. However, when editing (both with JS and without JS), there will never be duplication of text in the form fields. Drupal recomposes the body text for the form and parses it back on submission.

Also, for the n'th time: No, we cannot change this to a horizontal ruler, icon, background color or flying pony in the textarea. That's impossible with a simple textarea tag and requires a true HTML WYSIWYG editor. The current state of WYSIWYG is that it's broken and messy, and some major browsers (like Safari and possibly Opera) are still completely left out of the picture. Two separate textareas is the golden mean for now.

So the only issue left is whether we want separate labels. Personally, I think the two textareas should be joined together without anything in between, as the text for the body can conceptually start in the summary. I don't think there is a single right answer here though.

If we want to add labels, change the wording or such, that's IMO worries for later. The current implementation is already polished well up to the level required for core.

Patch still applies, but I rerolled without windows line endings.

Steven’s picture

Sorry, I meant shunting, not Chill35, above.

ximo’s picture

I think the problem is that there are so many different uses for teasers/summaries/excerpts that one can't cater to all with one simple solution.

As for the name of the teaser, I looked up the definitions of the alternatives I know of. These are the definitions that would be most appropriate in the context of posts:

Teaser
An advertisement that offers something free in order to arouse customers' interest.

Summary
A presentation of the substance of a body of material in a condensed form or by reducing it to its main points; an abstract.

Excerpt
A part or selection from written or printed matter.

The meanings differ largely, so calling it one or the other completely changes the perception of its function. The definitions are taken from dictionaries and represent how the average user understands the words. I still believe "summary" is a better word than "teaser" for online publishing, as most people associate teasers with advertisement.

The way I see it, there are two main uses of a teaser; summary and excerpt. So what about adding a set of radio buttons to admin/content/node-settings, allowing the admin to choose which teaser concept to use? It could be done like this (picture a set of radio options):

Type of teaser:
The teaser is typically used when displaying the post on the main page, in XML feeds, etc. Note that this setting will only affect new or updated content and will not affect existing teasers.

  • (o) Excerpt
    A selected excerpt from the body of posts will be used.
  • ( ) Summary
    Write a summary of the contents of posts in a separate field.
  • ( ) Trimmed
    Drupal will use a trimmed version of the post.

If Excerpt is chosen, Steven's original "split" concept would apply; the Excerpt textarea would be part of the Body field. If Summary is chosen, my suggestion would apply; a separate Summary field would be used. If Trimmed is chosen, the existing "Length of trimmed posts" option is used to trim all posts, no "Split at cursor" button would be shown (old behaviour).

I know you're not keen on adding new options, but like I said, it's difficult to come up with one solution that will fit 90% of all users. This would certainly cover the most common uses.

Although I would like to see my suggestion taken into consideration, I think the patch is good to go as it is. It is a great improvement and does what it's supposed to do very elegantly. All kudos to Steven for that! The intention of my suggestions is to take it even further.

ximo’s picture

When Summary is chosen, the Summary field would be visible to start with (as shown to the right in my screenshot). The user can then merge it with the body and back again as it likes.

I also forgot to link to my suggestion for those who don't know what I'm talking about.
Suggestion: http://drupal.org/node/107061#comment-225469
Screenshot: http://drupal.org/files/issues/teaser_field.png

Dries’s picture

Status: Needs review » Needs work

I've committed this patch to CVS HEAD, even though there might be room for additional/small improvements. It forces others to test this patch, and to channel their experience into additional patches.

In particular, I agree with the comment that we should properly label the summary. It makes it easier for people to understand what the 'summary' in the text is referring to.

I'm marking this 'code needs work' because we'll want to document the API changes/additions? Feel free to mark this 'fixed' once documentation related tasks have been taken care of.

Thanks all, and Steven in particular.

Frando’s picture

Status: Needs work » Needs review

ximo: Why should these options be added?
Steven's amazing patch provides all this, without the need to clutter the interface.
For teaser as a trimmed version of the post, just do nothing (as before).
For teaser as an excerpt of the post, just click the split button, and make sure "include in body" is selected.
For teaser as a summary of the post, just click the split button, enter the summary in the teaser field, and make sure the "include in body" is not selected.

I think Steven's patch is a super-flexible and usable approach to the problem.
We could still discuss adding workflow options (in a seperate issue), something like help tooltips (in a seperate issues), etc., but please keep these in seperate issues. I tested Steven's patch a few days ago and didn't detect any problems back then.

Frando’s picture

Status: Needs review » Needs work

Forget about my last comment. Didn't see Dries' lastest post when I wrote it.

ximo’s picture

Frando: For better useability. Although _we_ understand it perfectly well, the non-technical users out there finds it confusing and even have different expectations as to how it works and what it should do.

My suggestion isn't very drastical. It adds a set of radio options and requires some additional code to present the Summary field when the Summary option is chosen. Based on the option, the jQuery does its thing.

I realize it's not for this discussion/issue though. I'll create another issue for this once the patch has been included in core.

webchick’s picture

ximo: the patch is now in core, so go to town. :)

BioALIEN’s picture

misty3, I thought exactly the same which is the reason I opened up a discussion thread about it: http://drupal.org/node/133702

To all, I think what we have here is still the best short term solution to the problem but the bigger picture remains.

Congrats for getting this committed :)

Steven’s picture

ximo: I think the meaning of the words 'teaser', 'trimmed', 'excerpt/abstract', and 'summary' are sufficiently diluted that a radio button choice will not clear up things much. I think a checkbox like "Show summary in full view" is much more direct and clear as it shows a relation between elements on screen.

misty3’s picture

Thanks BioAlien, for that thread ( I made some feedback there )
I also agree that the bigger picture remains, and this solution with its rather uncomfortable_for_many terminology and the non-intuitive splitter thingy can ( or is ) be
confusing to many. BioAlien, since this thread is not the right place may be you can chime in at
http://drupal.org/node/134657

One small ( or big ) thing is that this js splitter stuff does not play nicely with
wysiwyg and there a variety of those with respective browser peculiarities :-(
It thus drifts away far from the simple, logical and complete approach of drupal, imho.

Best regards

Steven’s picture

misty3: what the heck are you on about? The problems encountered by WYSIWYG textareas are completely different from this patch. They use a radically different way of implementing it.

"One small ( or big ) thing is that this js splitter stuff does not play nicely with WYSIWYG"

This is non-sense. WYSIWYG modules can easily disable the teaser behaviour, just like they now disable the resizable behaviour. They can implement their own method of doing the break tag (and many already do afaik).

shunting’s picture

Status: Closed (fixed) » Needs work

1. chili at 114: I am well aware that on the backend, in the database, teaser and body are split. That's not relevant to my point, which is to a writer, or, at least this writer and many other writers I work with, the split between teaser and body is fluid and not considered as fielded. I argue that the UI metaphor proposed on this thread is wrong. Or do you believe that the front end should simply be a readout of whatever fields are in the database?

2. Steven at 116: I don't recall requesting a flying pony, for the first or the thousandth time. All that would is required is a better tag for the user. There are two use cases: (1) If the user can't work in HTML, then they're going to work in the WYSWG anyhow, so a tag for the split is just as valid a solution is the (wrong metaphor) of fields. Alternatively (2) If the user can work in HTML, then give them a real tag, not a comment.

For case 1, if there's a real tag, then the AJAX guys can turn it into a flying pony, or a flaming... Well, it's late, so let's not go there. ;-0

UPDATE Let's remember, please, that content creators actually add value to sites, shall we? Usability is critical. Please, can we just have D5 classic back, in addition to this new approach?

webernet’s picture

Status: Needs work » Closed (fixed)
davyvdb’s picture

Version: 6.x-dev » 5.x-dev

Is this working in Drupal 5.5? I can't patch fully.

VM’s picture

Version: 5.x-dev » 6.x-dev

No, please read http://drupal.org/node/107061#comment-486968 from this thread and follow along with the remainder of the conversation.

Status: Needs work » Closed (fixed)