+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&#39;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 &#39;body&#39; field that other modules might expect to find. I guess we&#39;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">&lt;<a href="mailto:barry@jaspan.org">barry@jaspan.org</a>&gt;</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. &nbsp;I have an initial suggestion: change node body and teaser from special cases to normal fields. &nbsp;I suspect this is going to be quite controversial so I thought I&#39;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&#39;m sure there will be subtleties and complexities to work. &nbsp;I&#39;m just asking about the concept.<br>
<br>
Concept:<br>
<br>
Remove all special processing for $node-&gt;body and $node-&gt;teaser. &nbsp;Create two fields, body and teaser, both text fields. &nbsp;Assign both fields to every existing content type with a &quot;body field&quot; using the textarea widget. &nbsp;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&#39;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. &nbsp;Don&#39;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-&gt;body and $node-&gt;teaser being normal fields, they will not be available for overloaded use as the complete rendered output of the node. &nbsp;Hurray! &nbsp;We can use $node-&gt;content = drupal_render($node) or something like that.<br>

<br>
- We might want to think about adding other fields to our default content types. &nbsp;Perhaps Article should have a Subtitle field, etc. &nbsp;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>