The Status and Future of the Body Field
I'm working on a "What's New" in D7 screencast and I'm having trouble figuring out the body field and what a best practice would be. A quick review leads me to the following conclusion: The body field is a legacy of a pre-fields-in-core Drupal. I can understand, for ease of upgrading, why the body field might remain in the node_revisions table. 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. If you want to add a "long text with summary" field you should just go to, "Manage Fields", choose "Text" and then "Long text with summary." I understand that upgraded existing content-types with body fields will still need to be edited. But shouldn't there be a way to edit existing body fields from updated content types without presenting the body field in the legacy manner when creating new content-types? Shai
2010/1/15 Shai Gluskin <shai@content2zero.com>
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
@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 <naheemzaffar@gmail.com>wrote:
2010/1/15 Shai Gluskin <shai@content2zero.com>
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
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 mike@mikeyp.net 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 <naheemzaffar@gmail.com> wrote: 2010/1/15 Shai Gluskin <shai@content2zero.com>
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
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 <mike@mikeyp.net> 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 mike@mikeyp.net 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 <naheemzaffar@gmail.com> wrote: 2010/1/15 Shai Gluskin <shai@content2zero.com>
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
participants (3)
-
Michael Prasuhn -
Naheem Zaffar -
Shai Gluskin