One of the things that has bugged the snot out of me is this story and page module. Not seeing a difference I went looking for what it the difference might be. Then I find a post by Steven Peck http://lists.drupal.org/archives/documentation/2006-08/msg00063.html that say basicly nothing. Certainly that is what appears to be. What is worse is they are both turned on and both can be deleted from the content types. I think that now page should be on by default and not allowed to be deleted; it becomes the require content type. I think that story should be removed from core and maintained as a contributed module as an example of how node modules can be created. I think doing these will help remove confusion from the beginning Dural experience. Earnie
One of the things that has bugged the snot out of me is this story and page module. Not seeing a difference I went looking for what it the difference might be. Then I find a post by Steven Peck
If you're on the developer list, the assumption is that you're running the latest version of Drupal, which is Drupal 5.0rc1. Had you been, you would not have sent this email. -- Morbus Iff ( if god is my witness, god must be blind ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
If you're on the developer list, the assumption is that you're running the latest version of Drupal, which is Drupal 5.0rc1. Had you been, you would not have sent this email.
My apology. I am an idiot. -- Morbus Iff ( i've got the creme filling ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
Quoting Morbus Iff <morbus@disobey.com>:
If you're on the developer list, the assumption is that you're running the latest version of Drupal, which is Drupal 5.0rc1. Had you been, you would not have sent this email.
My apology. I am an idiot.
But at least you agree. Apology accepted. Earnie
Quoting Morbus Iff <morbus@disobey.com>:
One of the things that has bugged the snot out of me is this story and page module. Not seeing a difference I went looking for what it the difference might be. Then I find a post by Steven Peck
If you're on the developer list, the assumption is that you're running the latest version of Drupal, which is Drupal 5.0rc1. Had you been, you would not have sent this email.
I am running from CVS HEAD. Shouldn't HEAD have at least 5.0rc1 code? Isn't HEAD the starting point for the 6.0 release? Earnie
On 12/22/06, Earnie Boyd <earnie@users.sourceforge.net> wrote:
I think that now page should be on by default and not allowed to be deleted; it becomes the require content type.
When I was working on the patch that introduced CCK functionality into core (<http://drupal.org/node/62340>), I wanted 'page' (and 'story') to be a content type that could be disabled, but not deleted. However, the ability to 'disable' a content type was a feature that didn't make it into core. Thus, the 'page' content type in Drupal 5 is one that can be deleted. In order to make 'page' a content type that can be disabled, we'd have to move it back into its own separate 'page.module' (it's currently created by node.module), and make it once again get defined through hook_node_info(). Then, when page.module gets disabled, the content type would also be disabled. I think the fact that both 'page' and 'story' can be deleted makes it clear enough to end-users that neither or these content types is necessary, and that both of them are pretty similar. I don't really see the need to move them back into their own modules. Cheers, Jaza.
On 12/21/06, Earnie Boyd <earnie@users.sourceforge.net> wrote:
One of the things that has bugged the snot out of me is this story and page module. Not seeing a difference I went looking for what it the difference might be. Then I find a post by Steven Peck http://lists.drupal.org/archives/documentation/2006-08/msg00063.html that say basicly nothing. Certainly that is what appears to be. What is worse is they are both turned on and both can be deleted from the content types. I think that now page should be on by default and not allowed to be deleted; it becomes the require content type. I think that story should be removed from core and maintained as a contributed module as an example of how node modules can be created. I think doing these will help remove confusion from the beginning Dural experience.
Earnie
The reason they exist is historical, and is just for flexibility. Having two content types, even though identical in fields, provides more flexibility in workflow. For example, one can be moderated by default, and have comments on by default, the other can be not so. In 5.0, you can define your own type, or delete story if you don't like it.
On 12/21/06, Khalid B <kb@2bits.com> wrote:
The reason they exist is historical, and is just for flexibility.
And for an upgrade path from 4.7. On the flexibility angle, I'm going to propose a patch with two/three changes: * page not promoted by default * page with comments off by default * (don't know if we can easily do this) page with "submitted by" turned off by default Having two content types, even though identical in fields, provides more
flexibility in workflow. For example, one can be moderated by default, and have comments on by default, the other can be not so.
In 5.0, you can define your own type, or delete story if you don't like it.
I've been looking at programmatically defining new / different content types as part of alternate install profiles. I spent some time on this today and I think I uncovered some areas that could be improved in default.profile -- some stuff (like required modules) should be moved to system.install, and some things, (like defining page and story) might work better in default.profile. I encourage everyone to try and make an install profile by doing "cp -R profiles/default profiles/your_new_profile" -- I suspect this is the "cut and paste" install profile method that we'll see the most of initially. I got pretty far today in perhaps an hour. I wanted to not have story, but instead a replacement node type called "pressrelease". -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 Skype borismann http://www.bryght.com
On the flexibility angle, I'm going to propose a patch with two/three changes: * page not promoted by default * page with comments off by default * (don't know if we can easily do this) page with "submitted by" turned off by default Nice. That would justify the inclusion a bit more for me and I ALWAYS turn off promotion and comments for page.
I think I uncovered some areas that could be improved in default.profile -- some stuff (like required modules) should be moved to system.install I've been doing a lot of work on my own install profile over the past couple weeks and agree with you there. You shouldn't have to worry about the required modules since...uh, they're required. We shouldn't give users the ability to forget to include node module (although they'd probably find out really quickly). :-)
, and some things, (like defining page and story) might work better in default.profile. Yeah, that makes sense to me. You got any issues opened up for those?
You have your install profiles somewhere I could check out? I found out that in profilename_install() you don't have access to a full bootstrap so I needed to do a drupal_goto('mymodulecallback'); in profilename_install() that would do additional setup by way of an installed auxiliary setup module. Is this what you're doing or am I missing something? Rob Roy Barreca Founder and COO Electronic Insight Corporation http://www.electronicinsight.com rob@electronicinsight.com Boris Mann wrote:
On 12/21/06, *Khalid B* <kb@2bits.com <mailto:kb@2bits.com>> wrote:
The reason they exist is historical, and is just for flexibility.
And for an upgrade path from 4.7.
On the flexibility angle, I'm going to propose a patch with two/three changes: * page not promoted by default * page with comments off by default * (don't know if we can easily do this) page with "submitted by" turned off by default
Having two content types, even though identical in fields, provides more flexibility in workflow. For example, one can be moderated by default, and have comments on by default, the other can be not so.
In 5.0, you can define your own type, or delete story if you don't like it.
I've been looking at programmatically defining new / different content types as part of alternate install profiles. I spent some time on this today and I think I uncovered some areas that could be improved in default.profile -- some stuff (like required modules) should be moved to system.install, and some things, (like defining page and story) might work better in default.profile.
I encourage everyone to try and make an install profile by doing "cp -R profiles/default profiles/your_new_profile" -- I suspect this is the "cut and paste" install profile method that we'll see the most of initially.
I got pretty far today in perhaps an hour. I wanted to not have story, but instead a replacement node type called "pressrelease".
-- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 Skype borismann http://www.bryght.com
On 12/21/06, Rob Barreca <rob@electronicinsight.com> wrote:
On the flexibility angle, I'm going to propose a patch with two/three changes: * page not promoted by default * page with comments off by default * (don't know if we can easily do this) page with "submitted by" turned off by default Nice. That would justify the inclusion a bit more for me and I ALWAYS turn off promotion and comments for page
I don't have an issue open for this yet...I think default.profile is probably also the right place for this.
, and some things, (like defining page and story) might work better in default.profile. Yeah, that makes sense to me. You got any issues opened up for those?
Define page and story in default.profile: http://drupal.org/node/104763 Remove required modules from default.profile: http://drupal.org/node/104764
You have your install profiles somewhere I could check out?
Just one. Will be noodling around here: https://svn.bryght.com/dev/wiki/CorporateSiteInstallProfile
I found out that in profilename_install() you don't have access to a full bootstrap so I needed to do a drupal_goto('mymodulecallback'); in profilename_install() that would do additional setup by way of an installed auxiliary setup module. Is this what you're doing or am I missing something?
I *just* started diving into this. And I only play a developer on this list :P I think we need to be able to use more of the API rather than having to do direct DB inserts. So...some sort of method of bootstrapping if needed? My overriding of story in myprofile.profile hasn't worked yet using _node_type_set_defaults and node_type_save, so that might be the reason. -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 Skype borismann http://www.bryght.com
My overriding of story in myprofile.profile hasn't worked yet Yeah, I really think we need to have a full bootstrap in profilename_install()...or profilename_enable() if we want to be consistent with how .install files are doing this now.
Issue at http://drupal.org/node/104765 Rob Roy Barreca Founder and COO Electronic Insight Corporation http://www.electronicinsight.com rob@electronicinsight.com Boris Mann wrote:
On 12/21/06, Rob Barreca <rob@electronicinsight.com> wrote:
On the flexibility angle, I'm going to propose a patch with two/three changes: * page not promoted by default * page with comments off by default * (don't know if we can easily do this) page with "submitted by" turned off by default Nice. That would justify the inclusion a bit more for me and I ALWAYS turn off promotion and comments for page
I don't have an issue open for this yet...I think default.profile is probably also the right place for this.
, and some things, (like defining page and story) might work better in default.profile. Yeah, that makes sense to me. You got any issues opened up for those?
Define page and story in default.profile: http://drupal.org/node/104763
Remove required modules from default.profile: http://drupal.org/node/104764
You have your install profiles somewhere I could check out?
Just one. Will be noodling around here: https://svn.bryght.com/dev/wiki/CorporateSiteInstallProfile
I found out that in profilename_install() you don't have access to a full bootstrap so I needed to do a drupal_goto('mymodulecallback'); in profilename_install() that would do additional setup by way of an installed auxiliary setup module. Is this what you're doing or am I missing something?
I *just* started diving into this. And I only play a developer on this list :P
I think we need to be able to use more of the API rather than having to do direct DB inserts. So...some sort of method of bootstrapping if needed? My overriding of story in myprofile.profile hasn't worked yet using _node_type_set_defaults and node_type_save, so that might be the reason.
Rob Barreca wrote:
My overriding of story in myprofile.profile hasn't worked yet Yeah, I really think we need to have a full bootstrap in profilename_install()...or profilename_enable() if we want to be consistent with how .install files are doing this now.
perhaps it offends some elegance, but why not ship with a <profilename>.module and its own install. you are bootstrapped there and can run wild.
perhaps it offends some elegance, but why not ship with a <profilename>.module and its own install. you are bootstrapped there and can run wild. That's what I'm doing now with a profilename_setup.module. So it's not a huge deal as it does keep the .profile clean this way. So if there is a intent to keep profilename_install() simple and restricted then I'm fine with that, but wanted to bring it up to see if there was a good reason for it not working the way I thought it should.
Rob Roy Barreca Founder and COO Electronic Insight Corporation http://www.electronicinsight.com rob@electronicinsight.com Moshe Weitzman wrote:
Rob Barreca wrote:
My overriding of story in myprofile.profile hasn't worked yet Yeah, I really think we need to have a full bootstrap in profilename_install()...or profilename_enable() if we want to be consistent with how .install files are doing this now.
perhaps it offends some elegance, but why not ship with a <profilename>.module and its own install. you are bootstrapped there and can run wild.
On 22 Dec 2006, at 6:53 AM, Rob Barreca wrote:
You have your install profiles somewhere I could check out? I found out that in profilename_install() you don't have access to a full bootstrap so I needed
Why not just call drupal_bootstrap yourself.
Why not just call drupal_bootstrap yourself. Well, I have a solution in place that works but is just a little clunky. And quite frankly, I'm too scared to manually call drupal_bootstrap.
Rob Roy Barreca Founder and COO Electronic Insight Corporation http://www.electronicinsight.com rob@electronicinsight.com adrian rossouw wrote:
On 22 Dec 2006, at 6:53 AM, Rob Barreca wrote:
You have your install profiles somewhere I could check out? I found out that in profilename_install() you don't have access to a full bootstrap so I needed
Why not just call drupal_bootstrap yourself.
Sorry for this last thread hijack. Just wanted to document this here first: Okay, boys. I did a little searching and looks like I was missing out on a profile hook_profile_final. install_complete() calls profilename_profile_final() after a drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL) so this should be the place to do all this magic. After I mess around with this a bit more I'm gonna go document this at http://drupal.org/node/67921 and try and explain what should go in profilename_install (still have to figure out why this is useful) and what should go in profilename_profile_final. Rob Roy Barreca Founder and COO Electronic Insight Corporation http://www.electronicinsight.com rob@electronicinsight.com adrian rossouw wrote:
On 22 Dec 2006, at 6:53 AM, Rob Barreca wrote:
You have your install profiles somewhere I could check out? I found out that in profilename_install() you don't have access to a full bootstrap so I needed
Why not just call drupal_bootstrap yourself.
Hello Op vrijdag 22 december 2006 05:28, schreef Boris Mann:
The reason they exist is historical, and is just for flexibility.
This reason is, IMNSHO, the worst reason you can think of. It basically says "we are not open for substantial improvement", or "we made mistakes in the past, and are not willing to fix these". Drupal has a good history of not stepping into that trap. Drupal has not been afraid to break old code and concepts. Yet in this very case page and story were allowed to co-exist, without any clear reason. FRom 4.6 to 4.7 and now from 4.7 to 5.0
And for an upgrade path from 4.7. Sure, but does this not indicate that, with little more effort we would have had a *real* solution instead of an *easy* one?
I can think (and have proposed them several times, even with patches, just to cut off that argument) of at least three solutions that are really easy: - Pages get a link in the menu automagically, stories not. - The interface for stories: a 20-lines textfield, and a title. pages: a 50 lines textfield and a title. - An autocreated taxonomy-tree is connected to stories. Stories can be categorised by default, pages don't need to be. I guess there are a million small things like this (Boris proposed some other ones), that can bring us to a good intermediate solution: not removing stories or pages, but utilising the virtual difference. Bèr -- Ik doneer alle advertentie inkomsten x2 aan Serious Request/Music 4 life. Doe ook mee: -- http://bler.webschuur.com/ik_doneer_alle_advertentie_inkomsten_x2_aan_seriou... Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: www.sympal.nl
On 22 Dec 2006, at 10:01, Bèr Kessels wrote:
This reason is, IMNSHO, the worst reason you can think of. It basically says "we are not open for substantial improvement", or "we made mistakes in the past, and are not willing to fix these". Drupal has a good history of not stepping into that trap. Drupal has not been afraid to break old code and concepts. Yet in this very case page and story were allowed to co-exist, without any clear reason. FRom 4.6 to 4.7 and now from 4.7 to 5.0
Ber, we're going to fix this. We're still in an intermediate state, but making progress. At this point, it's not clear whether we want to remove 'page', or whether we want to make it better (and different from story). I'm leaning towards making it better and that is going to take at least one more release ... -- Dries Buytaert :: http://www.buytaert.net/
On Fri, 22 Dec 2006, [utf-8] Bèr Kessels wrote:
Drupal has a good history of not stepping into that trap. Drupal has not been afraid to break old code and concepts. Yet in this very case page and story were allowed to co-exist, without any clear reason. FRom 4.6 to 4.7 and now from 4.7 to 5.0
Ber the clear reason was that you can attach different permissions to them, different taxonomy vocabularies, different publishing defaults, display of 'submitted by' information, enabling of comments, etc. These are all still utilized features and differentiators of actual usage patterns of story and page (with these usage patterns differring from website to website for good reasons). The possibilties can be better communicated, and better defaults can be made for the two types, but saying that there is no reason to have the two of them is false IMHO. Gabor
On 12/22/06, Bèr Kessels <ber@webschuur.com> wrote:
Op vrijdag 22 december 2006 05:28, schreef Boris Mann:
The reason they exist is historical, and is just for flexibility.
Actually, I am the one who wrote that, so I will respond. This reason is, IMNSHO, the worst reason you can think of. It basically
says "we are not open for substantial improvement", or "we made mistakes in the past, and are not willing to fix these".
Ber, There is a difference between an explanation and an excuse. In response to the original question, I was merely pointing out how things have been (and still are), not how they should be.
On 22 Dec 2006, at 05:28, Boris Mann wrote:
On the flexibility angle, I'm going to propose a patch with two/ three changes: * page not promoted by default * page with comments off by default * (don't know if we can easily do this) page with "submitted by" turned off by default
3 x YES, and I'd like to go one step further. Add a parent ID to pages (or nodes in general) so we can create content trees with proper breadcrumbs (eg. Home >> About us >> Management >> Joe Boss (CEO)) and navigation links. We might be able to deprecate book.module in the long run. I'd accept patches for all of that so make sure to submit it to core rather than keep it in your install profiles. Thanks. Maybe create an issue for it already? ;-) -- Dries Buytaert :: http://www.buytaert.net/
Quoting Dries Buytaert <dries.buytaert@gmail.com>:
On 22 Dec 2006, at 05:28, Boris Mann wrote:
On the flexibility angle, I'm going to propose a patch with two/ three changes: * page not promoted by default * page with comments off by default * (don't know if we can easily do this) page with "submitted by" turned off by default
3 x YES, and I'd like to go one step further. Add a parent ID to pages (or nodes in general) so we can create content trees with proper breadcrumbs (eg. Home >> About us >> Management >> Joe Boss (CEO)) and navigation links. We might be able to deprecate book.module in the long run.
Wow, I didn't realize this was such a hot issue. While we're at how about adding a content type option to populate the menu title with the title of the node and an option to set the default menu? I was going to mention this at a later date after I had some time to study the core code and try a patch but since we discussing changes ... Earnie
On Fri, 2006-12-22 at 11:41 +0100, Dries Buytaert wrote:
On 22 Dec 2006, at 05:28, Boris Mann wrote:
On the flexibility angle, I'm going to propose a patch with two/ three changes: * page not promoted by default * page with comments off by default * (don't know if we can easily do this) page with "submitted by" turned off by default
3 x YES, and I'd like to go one step further. Add a parent ID to pages (or nodes in general) so we can create content trees with proper breadcrumbs (eg. Home >> About us >> Management >> Joe Boss (CEO)) and navigation links. We might be able to deprecate book.module in the long run.
I'd accept patches for all of that so make sure to submit it to core rather than keep it in your install profiles. Thanks.
Maybe create an issue for it already? ;-)
-- Dries Buytaert :: http://www.buytaert.net/
Is there any chance 1-3 could end up in 5.0?
On 12/22/06, Darrel O'Pry <dopry@thing.net> wrote:
On Fri, 2006-12-22 at 11:41 +0100, Dries Buytaert wrote:
On 22 Dec 2006, at 05:28, Boris Mann wrote:
On the flexibility angle, I'm going to propose a patch with two/ three changes: * page not promoted by default * page with comments off by default * (don't know if we can easily do this) page with "submitted by" turned off by default
3 x YES, and I'd like to go one step further. Add a parent ID to pages (or nodes in general) so we can create content trees with proper breadcrumbs (eg. Home >> About us >> Management >> Joe Boss (CEO)) and navigation links. We might be able to deprecate book.module in the long run.
I'd accept patches for all of that so make sure to submit it to core rather than keep it in your install profiles. Thanks.
Maybe create an issue for it already? ;-)
-- Dries Buytaert :: http://www.buytaert.net/
Is there any chance 1-3 could end up in 5.0?
RobRoy and I are working on it: http://drupal.org/node/104763 -- I'm about to test to see if this works. Rather than asking...let's make it ready and then work through any issues. I think this is a good step to do to get into 5. At a worst case (no functional changes, we're just moving code around), maybe for a bugfix in the 5 series. -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 Skype borismann http://www.bryght.com
On 12/22/06 5:41 AM, Dries Buytaert wrote:
On 22 Dec 2006, at 05:28, Boris Mann wrote:
On the flexibility angle, I'm going to propose a patch with two/three changes: * page not promoted by default * page with comments off by default * (don't know if we can easily do this) page with "submitted by" turned off by default
3 x YES, and I'd like to go one step further. Add a parent ID to pages (or nodes in general) so we can create content trees with proper breadcrumbs (eg. Home >> About us >> Management >> Joe Boss (CEO)) and navigation links. We might be able to deprecate book.module in the long run.
Well, I've long thought book.module should be deprecated / tweaked into a more generalized "outline" module. I know I know ... code is gold. But +1 for easing simplifying this type of IA improvement.
I'd accept patches for all of that so make sure to submit it to core rather than keep it in your install profiles. Thanks.
Maybe create an issue for it already? ;-)
-- Dries Buytaert :: http://www.buytaert.net/
-- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net
Would I be insane to suggest that 2 node types which work the same, but have different default work-flow / comment settings, should not have names as different as "story" and "page"? How about naming them "storytype1" and "storytype2" or the semantic equivalent? (I'd prefer to not use "page" since it collides with multiple nodes appearing on a themed page.) ..chrisxj On 12/22/06, Dries Buytaert <dries.buytaert@gmail.com> wrote:
On 22 Dec 2006, at 05:28, Boris Mann wrote:
On the flexibility angle, I'm going to propose a patch with two/ three changes: * page not promoted by default * page with comments off by default * (don't know if we can easily do this) page with "submitted by" turned off by default
3 x YES, and I'd like to go one step further. Add a parent ID to pages (or nodes in general) so we can create content trees with proper breadcrumbs (eg. Home >> About us >> Management >> Joe Boss (CEO)) and navigation links. We might be able to deprecate book.module in the long run.
I'd accept patches for all of that so make sure to submit it to core rather than keep it in your install profiles. Thanks.
Maybe create an issue for it already? ;-)
-- Dries Buytaert :: http://www.buytaert.net/
They only "work the same" from a developer's perspective. For an end user who will be using them to submit content, different workflows can make a huge semantic difference. 'Page' (or 'static page' or 'site page', if you prefer) is for building your site while 'story' (or 'user posting' or 'posting') is for adding daily content. Of course if the developer's perspective was what mattered most, then both these default content types could be scrapped. On 12/26/06, Chris Johnson <cxjohnson@gmail.com> wrote:
Would I be insane to suggest that 2 node types which work the same, but have different default work-flow / comment settings, should not have names as different as "story" and "page"? How about naming them "storytype1" and "storytype2" or the semantic equivalent? (I'd prefer to not use "page" since it collides with multiple nodes appearing on a themed page.)
..chrisxj
On 12/22/06, Dries Buytaert <dries.buytaert@gmail.com> wrote:
On 22 Dec 2006, at 05:28, Boris Mann wrote:
On the flexibility angle, I'm going to propose a patch with two/ three changes: * page not promoted by default * page with comments off by default * (don't know if we can easily do this) page with "submitted by" turned off by default
3 x YES, and I'd like to go one step further. Add a parent ID to pages (or nodes in general) so we can create content trees with proper breadcrumbs (eg. Home >> About us >> Management >> Joe Boss (CEO)) and navigation links. We might be able to deprecate book.module in the long run.
I'd accept patches for all of that so make sure to submit it to core rather than keep it in your install profiles. Thanks.
Maybe create an issue for it already? ;-)
-- Dries Buytaert :: http://www.buytaert.net/
Quoting Cog Rusty <cog.rusty@gmail.com>:
They only "work the same" from a developer's perspective. For an end user who will be using them to submit content, different workflows can make a huge semantic difference. 'Page' (or 'static page' or 'site page', if you prefer) is for building your site while 'story' (or 'user posting' or 'posting') is for adding daily content. Of course if the developer's perspective was what mattered most, then both these default content types could be scrapped.
It was from a new user perspective that I started this thread and there is no apparent difference from the end user point of view as delivered (at least with HEAD). As delivered they "work the same" regardless of whose perspective you use. There is no mention of workflow in the content type (or should that be node type) administration page nor in the page and story descriptions. I could see no difference in the workflow when I viewed page vs story content submissions. In fact the story content type description makes little sense with regard to the story page submission form. Earnie
On 12/26/06, Earnie Boyd <earnie@users.sourceforge.net> wrote:
Quoting Cog Rusty <cog.rusty@gmail.com>:
They only "work the same" from a developer's perspective. For an end user who will be using them to submit content, different workflows can make a huge semantic difference. 'Page' (or 'static page' or 'site page', if you prefer) is for building your site while 'story' (or 'user posting' or 'posting') is for adding daily content. Of course if the developer's perspective was what mattered most, then both these default content types could be scrapped.
It was from a new user perspective that I started this thread and there is no apparent difference from the end user point of view as delivered (at least with HEAD). As delivered they "work the same" regardless of whose perspective you use. There is no mention of workflow in the content type (or should that be node type) administration page nor in the page and story descriptions. I could see no difference in the workflow when I viewed page vs story content submissions. In fact the story content type description makes little sense with regard to the story page submission form.
Please follow along in the issues raised in this thread. We've already acknowledged that workflow should be different for these two types, and we're working on getting this committed. The different naming is absolutely relevant from an end user perspective: I usually go farther and rename the menu items to "static page" and "news story" or "press release", and set workflow appropriately. See http://drupal.org/node/104763 -- patches to change wording of page and story are also welcome, those definitions will also now be in default.profile when this patch gets in. -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 Skype borismann http://www.bryght.com
On 27 Dec 2006, at 03:04, Boris Mann wrote:
It was from a new user perspective that I started this thread and there is no apparent difference from the end user point of view as delivered (at least with HEAD). As delivered they "work the same" regardless of whose perspective you use. There is no mention of workflow in the content type (or should that be node type) administration page nor in the page and story descriptions. I could see no difference in the workflow when I viewed page vs story content submissions. In fact the story content type description makes little sense with regard to the story page submission form.
See http://drupal.org/node/104763 -- patches to change wording of page and story are also welcome, those definitions will also now be in default.profile when this patch gets in.
OK, let's get this fixed in Drupal 5. To that extend, let's move the discussion to the issue tracker. :) -- Dries Buytaert :: http://www.buytaert.net/
Quoting Dries Buytaert <dries.buytaert@gmail.com>:
On 27 Dec 2006, at 03:04, Boris Mann wrote:
It was from a new user perspective that I started this thread and there is no apparent difference from the end user point of view as delivered (at least with HEAD). As delivered they "work the same" regardless of whose perspective you use. There is no mention of workflow in the content type (or should that be node type) administration page nor in the page and story descriptions. I could see no difference in the workflow when I viewed page vs story content submissions. In fact the story content type description makes little sense with regard to the story page submission form.
See http://drupal.org/node/104763 -- patches to change wording of page and story are also welcome, those definitions will also now be in default.profile when this patch gets in.
OK, let's get this fixed in Drupal 5. To that extend, let's move the discussion to the issue tracker. :)
Is there documentation somewhere that tells me what issue trackers to subscribe to that deal with the Core modules? Drupal of course but are there others? Earnie
On Thu, 2006-12-21 at 20:28 -0800, Boris Mann wrote:
And for an upgrade path from 4.7.
On the flexibility angle, I'm going to propose a patch with two/three changes: * page not promoted by default * page with comments off by default * (don't know if we can easily do this) page with "submitted by" turned off by default
+1 thats where I start most of my configs...
Quoting Khalid B <kb@2bits.com>:
The reason they exist is historical, and is just for flexibility.
I understand the historical bit; it is the reason for the Again in the subject line.
Having two content types, even though identical in fields, provides more flexibility in workflow. For example, one can be moderated by default, and have comments on by default, the other can be not so.
But page and story have no difference as installed. So perhaps story should be installed with no comments specified. If it were there would at least be a difference between the two. Maybe even have the "Create a new revision" set for story.
In 5.0, you can define your own type, or delete story if you don't like it.
That is too obvious. I think page should be locked and not allowed to be deleted so that the end user doesn't screw himself. Earnie
On Fri, 22 Dec 2006, Earnie Boyd wrote:
In 5.0, you can define your own type, or delete story if you don't like it.
That is too obvious. I think page should be locked and not allowed to be deleted so that the end user doesn't screw himself.
Earnie, you see we are moving to "user defined content types" from "you need to hack code or database directly to do that"? Do you also understand that by locking down the page type, you say that every Drupal site on the planet needs that type, and will have that type listed on search refinement pages, on content creation pages, etc? Or we go back to "you need to hack code or database directly to remove that type". Gabor
On 12/22/06, Earnie Boyd <earnie@users.sourceforge.net> wrote:
Having two content types, even though identical in fields, provides more
flexibility in workflow. For example, one can be moderated by default, and have comments on by default, the other can be not so.
But page and story have no difference as installed. So perhaps story should be installed with no comments specified. If it were there would at least be a difference between the two. Maybe even have the "Create a new revision" set for story.
Lots of options. As stated, we can now programmatically set these things in default.profile. So we will.
In 5.0, you can define your own type, or delete story if you don't like it.
That is too obvious. I think page should be locked and not allowed to be deleted so that the end user doesn't screw himself.
LOCKED is another value that is available. "So the end user doesn't screw himself" isn't connected to anything else. If I'm just using blogs and have no "pages", I'd want it deleted. In any case, I posted issue #'s earlier in the thread. I'll be hangin' out there. -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 Skype borismann http://www.bryght.com
On 22 Dec 2006, at 5:15 PM, Boris Mann wrote:
LOCKED is another value that is available. "So the end user doesn't screw himself" isn't connected to anything else. If I'm just using blogs and have no "pages", I'd want it deleted.
In any case, I posted issue #'s earlier in the thread. I'll be hangin' out there.
There's also work going on to have cck types be provided by modules, the same way that views does it (default types, that can be cloned). Ie: install a video module, and it provides a field for video on any content type, but also creates a default video node type. Another small thing i'd like is to be able to disable the body field. Right now I am removing it via form_alter.
On Friday 22 December 2006 8:46 am, Earnie Boyd wrote:
In 5.0, you can define your own type, or delete story if you don't like it.
That is too obvious. I think page should be locked and not allowed to be deleted so that the end user doesn't screw himself.
I've a Drupal 4.7 site in beta right now where every node is defined by CCK. The page and story modules are both disabled. If we were "forced" to keep the page node type around, that would clutter up the UI with stuff that we don't want. +1 for using page and story to show how you can have different node types do different things, like disabling comments on page by default. -1 for taking away the user's ability to reconfigure the site however he wants. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
On Thu, 2006-12-21 at 22:54 -0500, Earnie Boyd wrote:
One of the things that has bugged the snot out of me is this story and page module. Not seeing a difference I went looking for what it the difference might be. Then I find a post by Steven Peck http://lists.drupal.org/archives/documentation/2006-08/msg00063.html that say basicly nothing. Certainly that is what appears to be. What is worse is they are both turned on and both can be deleted from the content types. I think that now page should be on by default and not allowed to be deleted; it becomes the require content type. I think that story should be removed from core and maintained as a contributed module as an example of how node modules can be created. I think doing these will help remove confusion from the beginning Dural experience.
Earnie
There are a couple of reasons its advantageous to have both similar modules as a starting point for users. Their differences are their conceptual role in your website, which will lead to different templates for each, and different functionality enabled through nodeapi for each. The new world of drupal nodes will all have these vague lines of differentiation that will mostly be defined by the site configuration, theme. It just means more flexibility. .darrel.
participants (16)
-
adrian rossouw -
Boris Mann -
Bèr Kessels -
Chris Johnson -
Cog Rusty -
Darrel O'Pry -
Dries Buytaert -
Earnie Boyd -
Gabor Hojtsy -
James Walker -
Jeremy Epstein -
Khalid B -
Larry Garfield -
Morbus Iff -
Moshe Weitzman -
Rob Barreca