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 <!--break--> 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 <!--break--> 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@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@garfieldtech.com