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