Body and teaser as fields
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
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
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
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
The special case handling that body gets right now is more properly "old legacy crappy way of doing things". It's a special case only by virtue of being old and non-updated, and it makes life much harder for themers, for Views, etc. The last several sites I've spec'ed out have involved removing the body field on *all* node types completely and replacing them with a shared CCK field just to avoid the nonsense that is the core body field. In other words, huge +1 on making body just another "FiC field". I also use teasers almost never. They're slow, difficult to configure, and the teaser splitter dojobby ranks as one of our dumbest "usability improvements" ever IMO. :-) (Yeah, come on Larry, tell us how you really feel.) The one and only place I ever use it is on my blog, where I manually set <!--break--> myself TYVM. For a real site I'm building for someone, I virtually never use teasers. If I want a list of something, I give the node a "Lead" CCK field and make a list view of it, as that's about 10x faster since it avoids the node load, and gives me much much much more theming flexibility to boot. If anything, I can see "teaser" becoming, get this, an alternate formatter for *any* textfield to just stop at the <!--break--> tag or at some number of characters, whichever comes first. That's effectively what we do now in a horribly hacky way. If you want a separate field instead, you add a separate textfield/textarea and use that. Problem solved. In other words, forge on, McJaspan! May the wind be at your back in your quest to exterminate crufty old crap from node.module. (OK, it's after 1 am, I'm tired...) On Tuesday 10 February 2009 11:41:22 pm Ronald Ashri wrote:
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
-- Larry Garfield larry@garfieldtech.com
+1 - although im dismayed to find im the only one who likes the js teaser break thing - if anything this is what has impressed a lot of users more than anything in my experience!. havent used body for aaaages tho. steev
On 11-Feb-09, at 2:11 AM, Larry Garfield wrote:
I also use teasers almost never. They're slow, difficult to configure, and the teaser splitter dojobby ranks as one of our dumbest "usability improvements" ever IMO
I'm surprised that there are many here who aren't using teasers. I think it's much more likely for users to use teasers and not developers, because they wouldn't encounter the benefits of replacing the teaser with a CCK field. The main problem I encounter with teasers is the name. "Summary" or "Introduction" is how I explain it to my users, and when they understand that, they're quite happy to use it in its intended manner. JS-splitter and all!
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?
It'd have to catch the case where the teaser is a subset, but the default position of <!--break--> has moved as well. I'd support only creating a teaser field on site upgrades, and having just a body field on new installs. --Andrew
On Wed, 2009-02-11 at 06:41 +0100, Ronald Ashri wrote:
For example a page could be a Title and Content, but a story would be Title, Post (a more blog-like name),
I respectfully disagree. "Content" is a nice generic term, and I think that the same field should be called the same thing across all the standard Drupal-default node types. Also, many Drupal sites are not blogs nor blog-like sites, so we should not assume that blog-ish terminology will be familiar to all Drupal content creators. Kind regards, Scott -- Syscrusher <syscrusher@4th.com>
If there are any improvements at all to be gained here, it is that there should be NO default Drupal content types, except maybe by way of example. Therefore, _nothing_ should be assumed about sub-class terms, they will be up to the end user in each case. So rather than argue in favor or against "post" as opposed to whatever, something like "content" (i.e. generic) is what should go. Victor Kane http://awebfactory.com.ar On Wed, Feb 11, 2009 at 11:17 AM, Syscrusher <syscrusher@4th.com> wrote:
On Wed, 2009-02-11 at 06:41 +0100, Ronald Ashri wrote:
For example a page could be a Title and Content, but a story would be Title, Post (a more blog-like name),
I respectfully disagree. "Content" is a nice generic term, and I think that the same field should be called the same thing across all the standard Drupal-default node types. Also, many Drupal sites are not blogs nor blog-like sites, so we should not assume that blog-ish terminology will be familiar to all Drupal content creators.
Kind regards,
Scott -- Syscrusher <syscrusher@4th.com>
Hi, syscrusher: I was simply giving an example - as I said more thorough usability testing will give these answers. If "content" is the way to go then that's great. victor: As for having default content types I think there are two levels - Drupal as a system/framework should not assume anything but a fresh installation should give a user(especially a new one that is probably just exploring the system) some types to work with, even if it is just a way to illustrate that different types that are possible. If the first thing a new user has to do is actually create a content type then we lost them right there... Best, Ronald Victor Kane wrote:
If there are any improvements at all to be gained here, it is that there should be NO default Drupal content types, except maybe by way of example.
Therefore, _nothing_ should be assumed about sub-class terms, they will be up to the end user in each case.
So rather than argue in favor or against "post" as opposed to whatever, something like "content" (i.e. generic) is what should go.
Victor Kane http://awebfactory.com.ar
On Wed, Feb 11, 2009 at 11:17 AM, Syscrusher <syscrusher@4th.com <mailto:syscrusher@4th.com>> wrote:
On Wed, 2009-02-11 at 06:41 +0100, Ronald Ashri wrote: > For example a page could be a Title and Content, but a story would be > Title, Post (a more blog-like name),
I respectfully disagree. "Content" is a nice generic term, and I think that the same field should be called the same thing across all the standard Drupal-default node types. Also, many Drupal sites are not blogs nor blog-like sites, so we should not assume that blog-ish terminology will be familiar to all Drupal content creators.
Kind regards,
Scott -- Syscrusher <syscrusher@4th.com <mailto:syscrusher@4th.com>>
On Wed, 2009-02-11 at 18:16 +0100, Ronald Ashri wrote:
syscrusher: I was simply giving an example - as I said more thorough usability testing will give these answers. If "content" is the way to go then that's great.
Understood, and I didn't mean to sound unduly critical.
victor: As for having default content types I think there are two levels - Drupal as a system/framework should not assume anything but a fresh installation should give a user(especially a new one that is probably just exploring the system) some types to work with, even if it is just a way to illustrate that different types that are possible. If the first thing a new user has to do is actually create a content type then we lost them right there...
I heartily concur. Kind regards, Scott -- Syscrusher <syscrusher@4th.com>
victor: As for having default content types I think there are two levels - Drupal as a system/framework should not assume anything but a fresh installation should give a user(especially a new one that is probably just exploring the system) some types to work with, even if it is just a way to illustrate that different types that are possible. If the first thing a new user has to do is actually create a content type then we lost them right there...
I heartily concur.
It should be up to the default install profile to create the two default types we have (page and article). Other install profiles can do what they want, including no content types at all. -- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting. Simplicity is prerequisite for reliability. -- Edsger W.Dijkstra Simplicity is the ultimate sophistication. -- Leonardo da Vinci
+1 removing default content types +1 getting rid of $node->body & $node->teaser +1 on offing the js-splitter +1 on field formatter that handles sizing or splitting content from the "display field" tab where it would seem more logical to handle this sort of thing.
On Wed, Feb 11, 2009 at 3:16 PM, Ronald Ashri <ronald@istos.it> wrote: Agreed, absolutely. But these example content types should be constructed in the same way anyone would construct one, and there should be no magical behavior associated with any of their fields that are not associated with any others anyone might make. Victor victor: As for having default content types I think there are two levels -
Drupal as a system/framework should not assume anything but a fresh installation should give a user(especially a new one that is probably just exploring the system) some types to work with, even if it is just a way to illustrate that different types that are possible. If the first thing a new user has to do is actually create a content type then we lost them right there...
Best,
Ronald
Quoting Victor Kane <victorkane@gmail.com>:
On Wed, Feb 11, 2009 at 3:16 PM, Ronald Ashri <ronald@istos.it> wrote:
Agreed, absolutely. But these example content types should be constructed in the same way anyone would construct one, and there should be no magical behavior associated with any of their fields that are not associated with any others anyone might make.
Victor
victor: As for having default content types I think there are two levels -
Drupal as a system/framework should not assume anything but a fresh installation should give a user(especially a new one that is probably just exploring the system) some types to work with, even if it is just a way to illustrate that different types that are possible. If the first thing a new user has to do is actually create a content type then we lost them right there...
How about making the default content types a configurable item for the install profile? -- Earnie http://r-feed.com Make a Drupal difference and review core patches. -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Earnie Boyd wrote:
How about making the default content types a configurable item for the install profile?
I think the default install should be zero-configuration to start with (beyond obvious DB name, user, etc). A lot of people are going to give Drupal about 4-5 minutes initally. They will download, unzip, visit install page on browser and fire away. They will assume that any issues will be dealt with and they don't want to learn anything about Drupal before Drupal is actually running on their system because that is the first hurdle. If I can't install it why should I even learn about it. If you ask them "do you want to create content types Page and Story" - already they have to learn something, as in "what are content types then?". Other profiles already assume some familiarity with Drupal and some purpose in what you are trying to achieve so they can happily ask all sorts of questiosn. Best, Ronald
I was actually thinking about this a few weeks ago, but don't know how feasible it would be (it probably wouldn't be that bad), but what if we had a multi-option download page? Basically you have the option of just downloading Drupal, but also have a few prepackaged options. So if I am looking at Drupal and want to blog I would select the "blogger package", then I would get an installation profile installing the blog module, plus maybe views with monthly archives, pathauto (and token), and possible a WYSIWYG editor. It could be something like "your flavor" of Drupal - similar to the custom downloads on jQuery UI. The hardest part I would see is keeping these single download packages up to date with releases of the modules they incorporate, but a work around on that shouldn't be too bad. It would also let the user, who doesn't really know what Drupal is, see that Drupal is actually all these things, and we even made it super easy for them to get going on whichever path they want. I think it would go good in the redesign, plus it would also go hand in hand with the content type creation based upon installation method (ie: installing would be simple like Ronald points out, yet content type is created based upon the "package" they download.) Jamie Holly http://www.intoxination.net Skype:intoxination Phone: 1-513-252-2919 Ronald Ashri wrote:
Earnie Boyd wrote:
How about making the default content types a configurable item for the install profile?
I think the default install should be zero-configuration to start with (beyond obvious DB name, user, etc). A lot of people are going to give Drupal about 4-5 minutes initally. They will download, unzip, visit install page on browser and fire away. They will assume that any issues will be dealt with and they don't want to learn anything about Drupal before Drupal is actually running on their system because that is the first hurdle. If I can't install it why should I even learn about it.
If you ask them "do you want to create content types Page and Story" - already they have to learn something, as in "what are content types then?".
Other profiles already assume some familiarity with Drupal and some purpose in what you are trying to achieve so they can happily ask all sorts of questiosn.
Best,
Ronald
Here's my suggestions: (a) The install package should include a small number of highly useful, pre-configured content types that *can* be installed/enabled. (b) The user at install time is given, say, three choices: 1. Install the basic CMS version of Drupal. This will install the core Drupal framework, plus 2 or 3 content types as appropriate, e.g. story, blog and event. 2. Install the basic blogging platform version of Drupal. This will install the core Drupal framekwork, plus 2 or 3 content types as appropriate, e.g. blog and user profile node. 3. Customize your Drupal install -- for experts. This will provide a list of all content types included in the basic Drupal download package with checkboxes which can be ticked off. Those types should be something like: story, page, blog, event, profile. This sort of install arrangement should address most of the issues brought up here. Of course, additional contrib modules can be added later -- perhaps even suggested during install, or at least referenced with a "for more functionality, see the large repository of contrib modules." ..chris On Thu, Feb 12, 2009 at 8:00 AM, Ronald Ashri <ronald@istos.it> wrote:
Earnie Boyd wrote:
How about making the default content types a configurable item for the install profile?
I think the default install should be zero-configuration to start with (beyond obvious DB name, user, etc). A lot of people are going to give Drupal about 4-5 minutes initally. They will download, unzip, visit install page on browser and fire away. They will assume that any issues will be dealt with and they don't want to learn anything about Drupal before Drupal is actually running on their system because that is the first hurdle. If I can't install it why should I even learn about it.
If you ask them "do you want to create content types Page and Story" - already they have to learn something, as in "what are content types then?".
Other profiles already assume some familiarity with Drupal and some purpose in what you are trying to achieve so they can happily ask all sorts of questiosn.
Best,
Ronald
Yep, I'm definitely in favour of this. It would make things a lot cleaner and more usable. So +1 from me. Cheers, Stella On Wed, Feb 11, 2009 at 4:20 AM, Barry Jaspan <barry@jaspan.org> 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
- 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)
.
Since Drupal 5 or 6 there's not been a body column in the node table anyway, so at the very worst we'd be looking at an extra select - which would be a cache_get() 90% of the time anyway. Would be nice to skip the join to node_revision for the title field (node.title doesn't get used in node_load()), then we actually lose a join in the default case. If anything it'll make our base query more efficient (and I've got plans to remove the join on users elsewhere, although a different issue of course). So +1, the teaser splitter definitely comes down as a DrupalWTF and could be happily moved into contrib, have you posted the issue yet? Nat
+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. 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. 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? Karen On Tue, Feb 10, 2009 at 10:20 PM, Barry Jaspan <barry@jaspan.org> 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
Maybe teaser is just a formatter for body? On Wed, Feb 11, 2009 at 8:13 AM, Karen Stevenson <karen@elderweb.com> wrote:
+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.
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.
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?
Karen
On Tue, Feb 10, 2009 at 10:20 PM, Barry Jaspan <barry@jaspan.org> 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
Yes. I suggested that earlier in this thread. Good to know we're still reaching the same conclusions. ;-) (Arguably then we may need caching for formatter results, but I hardly see that as a bad thing to have anyway.) On Thursday 12 February 2009 2:32:47 pm Darrel O'Pry wrote:
Maybe teaser is just a formatter for body?
On Wed, Feb 11, 2009 at 8:13 AM, Karen Stevenson <karen@elderweb.com> wrote:
+1 on getting rid of the teaser splitter -- I've been using css to hide it
-- Larry Garfield larry@garfieldtech.com
Perhaps I missed totally the FiC features but why can not $node->title be generic textfield as well? k
The title is used in all kinds of special ways, like as the default link to the node, so we were going to leave it alone for now. We could maybe make it a 'locked' field though (although we haven't really defined yet what 'locked' really means.) Anyway, someone would have to spend some time digging through the code to be sure to uncover all the implications of handling the title differently before making any change to that. Karen On Fri, Feb 13, 2009 at 7:59 AM, Kristjan Jansen <kika@trip.ee> wrote:
Perhaps I missed totally the FiC features but why can not $node->title be generic textfield as well? k
participants (20)
-
Andrew Berry -
Barry Jaspan -
Chris Johnson -
Darrel O'Pry -
Earnie Boyd -
Jamie Holly -
Karen Stevenson -
Khalid Baheyeldin -
Kristjan Jansen -
Kristof Van Tomme -
Larry Garfield -
Matt Farina -
Moshe Weitzman -
Nathaniel Catchpole -
Ronald Ashri -
Stella Power -
Steve Power -
Syscrusher -
Victor Kane -
william roboly