Remaining bits from teaser splitter

This could be a "best of both worlds" solution, since teaser-splitter support is confusing to some (as supported by the testing) but works very well for others who understand the teaser concept. A site admin who finds the functionality confusing could just disable this for all content types if she likes; either way, as an admin, we can decide intelligently whether the functionality "fits" with the site (or node type, even) and enable or disable accordingly.

I'm a fan of the teaser-splitter, and find it very useful for some types of posts. If the only downside here is one additional option on the content type add/edit screen, I certainly +1 the idea.

The thing it if we should just ignore any teaser information when teaser button is disabled or just hide the button.

I mean - when editing a node with a teaser (using <!--break-->), Drupal splits the text into teaser and body. Should it still split the text or ignore everything?

I'd support eliminating the teaser splitter entirely, and making the 'generate a teaser for this node' function a hook. Anyone else in favor of that? ;-)

There's definitely demand for this! While there are clear advantages to teasers, other pages (as catch clearly outlined above) shouldn't have the teaser splitter at all.

However, I'm in favour of keeping things simple, so the answer to #3 is to keep splitting the text with <!--break-->. This issue is from a pure usability viewpoint by hiding the clutter. It gets my +1.

+1000 for Eaton's proposal. The teaser splitter behavior is a nightmare for JavaScript behaviors (especially client-side/wysiwyg editors) and also for themers.

This bump courtesy of a collective swearing session in IRC :-) Lot of people are unhappy with the way it currently works (http://drupal.org/node/225955, http://drupal.org/node/134657), especially in combination with wysiwygs. Can't really tell what 'make it a hook' would mean for how this functionality will be presented to the user, but as it is now, we'd be better off without it.

I'm all for removing the functionality entirely. I can't see any reason why this couldn't be form_altered back in by a contributed module for anyone that's interested in re-implementing it.

Why the need for the regression?
If it can be 'form_altered back' with a contrib module, why not let core do precisely that?
The original idea to have this as a custom setting for each node type can satisfy everybody: those who want it and those who don't.

Because everyone hates the teaser splitter. If we can reach a 80% threshold (I think we can, easily) of people that would prefer the teaser splitter not exist at all, it'd be better to let contrib handle it than to burden the end user with yet another option for a feature they most likely don't want or understand.

I'd also say to nix the teaser splitter button.
With fields in core, down the road replace it with an excerpt or summary field.
And still make it possible to use the

tag, but that the excerpt field would take precedence.

Here's a devel thread on several developers thoughts on the teaser splitter: http://lists.drupal.org/pipermail/development/2009-February/031896.html

We also know from formal usability testing that the teaser splitter is baffling to many users. In Minnesota, one user was stuck on trying to figure out the teaser splitter for several minutes while attempting to insert an image into the body. We're doing another usability testing round right now in Baltimore, so it'll be interesting to see if we get similar results.

Yes, teaser splitter confused most participants this time as well
http://www.drupalusability.org/search/node/teaser
http://www.drupalusability.org/node/158

Removing features is awesome. Who's up for it?

While I think the teaser splitter is a cool piece of JavaScript I agree that it's not usable for a majority of drupal site users. Let's remove the teaser splitter. Do we revert back to the way it was handled in drupal 5?

Adding wysiwyg tag.

Here's an idea...

If we can find a way to improve that feature but still have it in core, that makes sense. Since fields in core is a D7 feature, why not create a module that enables blurbs/teasers? It enables a new text field, you attach it to a content type, then you get this snazzy teaser box that tracks & auto fills its text based on the body field. You can then click and expand that box. It can then be edited more precisely and independently.

I'm against regressing a core feature simply because we have a usability issue. It has a purpose. I think it needs to be refactored and have some usability people redesign it.

Contrib is where such funky ideas evolve. The teaser splitter should have been a contrib module in the first place. If it had been one, I am 99% sure we would not have it in core today.

I'll take up initial writing of a teaser_splitter contrib module for 7.x so we can finally rip this out.

Looking forward for this, make sure this stuff gets documented well.

Dave Reid: I am trying to follow this up, are you still planning on doing this - otherwise I wish to mark it normal.

Removing tag, untill there is something to review - I still think that we can remove this feature.

I, for one, like the teaser splitter. I find it quite helpful for selecting just how much of a posting will appear in category listings using views and such. I would be okay with splitting it into a contrib module, but make sure an upgrade path exists so those of us with thousands of nodes with teasers don't have to regenerate the teasers.

While I agree the current teaser splitter approach is ugly I think we will always need a way to control teaser appearance. I like Eaton's idea of a "Generate Teaser" button and I would like to suggest an expansion of that idea that would also address geerlingguy's concern.

When users currently press Preview they are shown two versions of the content: Teaser and Full
In place of the default teaser view I suggest users be given (node type configurable of course) either a Generate Teaser button or else an automatically generated teaser BUT under the teaser display include a button for "Edit Teaser Content".

Allow the teaser to be a completely separate editable content field (teaser7_content ?) so that the teasers can be more like a summary if that is what the contributor wants (gee... that would make an excellent optional module -- AutoSummarize -- like MS Word has). The size of the teaser7_content field could be optionally configured/limited per node type by the admin.

This approach would also allow for legacy content with teasers split-tags to be automatically converted by simply porting the "old" teaser content into the new teaser7_content and removing the split-tag.

On a separate but related matter, I use the Read More Tweak (http://drupal.org/project/ed_readmore) module and often have to use the split-tag to correctly place the Read More link.

I definitely think this fction needs some kind of implementation in D7 core (see http://drupal.org/node/16161) and I think the best way to implement it is by integrating it into the teaser content display code we are talking about here rather than as a separate module.

I'm so happy this issue is here. I don't like the teaser splitter. I don't like teasers. I like eaton's suggestion to make the functionality a hook.

I like teasers, but they should be a separate text area. Very confusing for new users.

If anyone's curious how to do this, here are the four lines required in your hook_form_alter:

http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/nodecomment...

Not all parts were removed by the 'Body as field' patch, it seems.

Committed to CVS HEAD. Thanks.

joy! This is a Good Thing. Thank you all.

sub