Michael, Thanks... that makes sense...
But a concern here. Isn't it possible that by supporting the legacy behavior so thoroughly that lots of modules may upgrade to 7 but not actually make themselves compatible with fields-in-core? They won't look broken initially because old and new sites are using the legacy body field. Shai On Fri, Jan 15, 2010 at 1:10 PM, Michael Prasuhn <[email protected]> wrote: > One reason is that many modules and places in Drupal are used to > $node->body and removing that standard and using $node->field_FOO is fine if > you know what you are doing, but otherwise it's a bit of a legacy practice. > > -Mike > __________________ > Michael Prasuhn > 503.512.0822 office > [email protected] > http://mikeyp.net > > On Jan 15, 2010, at 8:02 AM, Shai Gluskin wrote: > > > @Naheem, > > > > That doesn't answer the question. We can use a fields-in-core field to > create a body field that automatically gets created when you create a new > content-type. Sensible default settings have nothing to do with it. So I > still ask, "Why are we using the legacy body field for new content types in > D7?" > > > > While we are talking sensible defaults... the default for a body field in > a new content type should be to use the "Long text" handler and NOT the > "Long text with summary." The use-cases for "Long text with summary" are far > fewer than for "Long text." And it can take years for people to actually > grok "long text with summary" anyway :). Now that we've got fields-in-core, > we should be defaulting on a new content-type body field to "long text". > > > > Shai > > > > On Fri, Jan 15, 2010 at 10:50 AM, Naheem Zaffar <[email protected]> > wrote: > > 2010/1/15 Shai Gluskin <[email protected]> > > > > But this is what I don't get: Why is the body field still there when you > create a new content-type the body field is still there on the content-type > edit screen. > > > > usability - most people will expect a content type to be useable after > creation. > > > > Customisation is great, but it should never be at the expense of good > defaults > > > > > > > >
