+1 on getting rid of the teaser splitter -- I've been using css to hide it :)
The teaser splitter could become a contrib field module, if anyone wants to save it.<br><br>On auto-creating both a body and a teaser field -- is there a way to skip creating a second field for all the sites where the teaser is just a subset of the body? We really only need two fields if they have different content. I suppose it's a lot simpler to just automatically create it in all cases, so maybe simplicity wins out.<br>
<br>The only other question I have is what happens when there is no official 'body' field that other modules might expect to find. I guess we've already made the body optional so they should not be expecting that anyway. Is there any reason why losing a field that has had special meaning could be a problem to contrib modules?<br>
<br>Karen<br><br><div class="gmail_quote">On Tue, Feb 10, 2009 at 10:20 PM, Barry Jaspan <span dir="ltr"><<a href="mailto:barry@jaspan.org">barry@jaspan.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.<br>
<br>
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.<br>
<br>
Concept:<br>
<br>
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.<br>
<br>
Random thoughts:<br>
<br>
- We will get to remove a bunch of code, much of it quite ugly, from node.module.<br>
<br>
- 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.<br>
<br>
- 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 <a href="http://drupal.org/node/368674" target="_blank">http://drupal.org/node/368674</a>).<br>
<br>
- 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.<br>
<br>
- 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.<br>
<br>
Comments?<br>
<br>
Thanks,<br><font color="#888888">
<br>
Barry<br>
<br>
<br>
<br>
</font></blockquote></div><br>