[development] Body and teaser as fields

Wed Feb 11 07:11:41 UTC 2009

The special case handling that body gets right now is more properly "old 
legacy crappy way of doing things".  It's a special case only by virtue of 
being old and non-updated, and it makes life much harder for themers, for 
Views, etc.  The last several sites I've spec'ed out have involved removing 
the body field on *all* node types completely and replacing them with a shared 
CCK field just to avoid the nonsense that is the core body field.

In other words, huge +1 on making body just another "FiC field".

I also use teasers almost never.  They're slow, difficult to configure, and the 
teaser splitter dojobby ranks as one of our dumbest "usability improvements" 
ever IMO. :-)  (Yeah, come on Larry, tell us how you really feel.)  The one 
and only place I ever use it is on my blog, where I manually set  
myself TYVM.  For a real site I'm building for someone, I virtually never use 
teasers.  If I want a list of something, I give the node a "Lead" CCK field and 
make a list view of it, as that's about 10x faster since it avoids the node 
load, and gives me much much much more theming flexibility to boot.

If anything, I can see "teaser" becoming, get this, an alternate formatter for 
*any* textfield to just stop at the  tag or at some number of 
characters, whichever comes first.  That's effectively what we do now in a 
horribly hacky way.  If you want a separate field instead, you add a separate 
textfield/textarea and use that.  Problem solved.

In other words, forge on, McJaspan!  May the wind be at your back in your 
quest to exterminate crufty old crap from node.module.

(OK, it's after 1 am, I'm tired...)

On Tuesday 10 February 2009 11:41:22 pm Ronald Ashri wrote:
> Absolutely makes sense for me to remove Body and Teaser - talking from a
> user's/developer's perspective I've spent enough time trying to remove
> them already - they almost never quite work for what I am trying to do.
> Based on how we use Drupal at times even Title is an inconvenience, but
> I guess removing that as well would create more problems than solve.
>
> What we could then do is provide more useful content types for users to
> start with - in the case of Page and Story simply changing the field
> names would be enough to help people.
>
> For example a page could be a Title and Content, but a story would be
> Title, Post (a more blog-like name), Teaser (as a separate field -
> because although the js divider idea is a nice one it is confusing to
> people and does not fit the needs of a story too often). We could then
> also add other types as examples for people.
>
> Anyway, I am sure the far more sophisticated usability testing going on
> is going to throw up all these issues.
>
> Best,
>
> Ronald
>
> Moshe Weitzman wrote:
> > core would get rid of it. and there will be much rejoicing in usabilty
> > land.
> >
> > On Tue, Feb 10, 2009 at 11:45 PM, Matt Farina<matt at mattfarina.com>  wrote:
> >> On the UI side including the teaser splitter JavaScript might be ugly.
> >> How would we handle this special case? Or, do we get rid of the teaser
> >> splitter?
> >>
> >> On Feb 10, 2009, at 11:20 PM, Barry Jaspan wrote:
> >>> Now that Field API is in core it is time to start using it.  I have an
> >>> initial suggestion: change node body and teaser from special cases to
> >>> normal fields.  I suspect this is going to be quite controversial so I
> >>> thought I'd get some feedback here before evening bothering to start
> >>> looking at the code.
> >>>
> >>> This message is not about the details of the implementation; I'm sure
> >>> there will be subtleties and complexities to work.  I'm just asking
> >>> about the concept.
> >>>
> >>> Concept:
> >>>
> >>> Remove all special processing for $node->body and $node->teaser. 
> >>> Create two fields, body and teaser, both text fields.  Assign both
> >>> fields to every existing content type with a "body field" using the
> >>> textarea widget.  For existing nodes, as part of the upgrade path,
> >>> initialize the teaser field value with whatever teaser would normally
> >>> be generated automatically from the body.
> >>>
> >>> Random thoughts:
> >>>
> >>> - We will get to remove a bunch of code, much of it quite ugly, from
> >>> node.module.
> >>>
> >>> - Sites that really want an auto-generated teaser can remove the teaser
> >>> field from a content type and use the text field's teaser Display
> >>> Formatter in the teaser context.
> >>>
> >>> - This will mean removing the body field from the node and
> >>> node_revision tables, and creating a field_data_body table for it
> >>> instead.  Don't worry about database query efficiency; that is a solved
> >>> problem (see http://drupal.org/node/368674).
> >>>
> >>> - With $node->body and $node->teaser being normal fields, they will not
> >>> be available for overloaded use as the complete rendered output of the
> >>> node. Hurray!  We can use $node->content = drupal_render($node) or
> >>> something like that.
> >>>
> >>> - We might want to think about adding other fields to our default
> >>> content types.  Perhaps Article should have a Subtitle field, etc. 
> >>> This is a whole topic in itself.
> >>>
> >>> Comments?
> >>>
> >>> Thanks,
> >>>
> >>> Barry

-- 
Larry Garfield
larry at garfieldtech.com