They are identical at the code level. You could search/replace story/page and swap files and not change a thing. As recently as a couple of months ago there was a subtle difference in permissions (I forget what, it was trivial), but that has been removed. I think it is a shame having two identical modules; it confuses people.
I use stories for user-submitted content that requires commenting, moderation, file attachments, and so on.
I use 'page' for all of the static bits of content that are scattered throughout the site. It works out well, and I think that's what the designers intended. The real problem isn't, IMO, the fact that page and story are almost exactly the same. It's that we need ways to specify different 'content types' that map to the same node module.
Right now, I have a couple duplicates of page.module on my site for different applications. Each copy has a different set of permissions, different commenting and attachment setups, and using taxonomy_default, a different default locatoin in the site's structure. It works well, but I wonder if the attention onf flexinode and such are overkill for this sort of thing.
One problem with getting rid of story or page would be the number of sites that would need to be upgraded. While it would be trivial to change all stories to pages in an upgrade script, it would render many existing sites foobar. If a polymorph-node were introduced that could be a story or a page (plus anything else you wanted to call it), backwards compatibility could be preserved. Interesting idea. May not be especially hard to implement.
The Need:
Simple title-plus-body content types that differ only in add-on features, permissions, and taxonomy settings. Page and Story are examples of this need.
Why Not Flexinode?
With CCK in development, and Flexinode's sub-optimal data storage/theming, I'm leery. Also, Flexinode is geared towards creation of content types with additional fields and data types -- for simple nodes, it adds a lot of overhead.
The Possible Solution:
Create a tool for spitting out prefabricated 'xxxx.module' files as needed, or create a polymorphic 'basic node' module that can spawn off page, story, and other node types. This might work in a way similar to flexinode, without the elaborate mechanisms for alternate fields.
I was thinking more along the lines of just making the node_type hook dynamic and allowing the admin to enter new node names. The problem with this, of course, is getting the other hooks called later. If I tell Drupal that page.module is also responsible for a node type called "huba", does Drupal look for huba_view and huba_load, or do page_view and page_load still get called, in which case they can handle the different node types internally. You follow me?
http://drupal.org/node/29794 has a new module he threw together -- it does just what we're discussing. No frills, no bells or whistles, just a simple content module that lets you spin off multiple content types dynamically for unique permissions and theming.
Comments
not much
Story is designed to have the option of moderation, etc. Page was designed more along the lines of static content.
-sp
---------
Drupal Best Practices Guide - My stuff Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
They are identical.
They are identical at the code level. You could search/replace story/page and swap files and not change a thing. As recently as a couple of months ago there was a subtle difference in permissions (I forget what, it was trivial), but that has been removed. I think it is a shame having two identical modules; it confuses people.
- Robert Douglass
-----
Rate the value of this post: http://rate.affero.net/robertDouglass/
I recommend CivicSpace: www.civicspacelabs.org
My sites: www.hornroller.com, www.robshouse.net
An interesting point...
I use stories for user-submitted content that requires commenting, moderation, file attachments, and so on.
I use 'page' for all of the static bits of content that are scattered throughout the site. It works out well, and I think that's what the designers intended. The real problem isn't, IMO, the fact that page and story are almost exactly the same. It's that we need ways to specify different 'content types' that map to the same node module.
Right now, I have a couple duplicates of page.module on my site for different applications. Each copy has a different set of permissions, different commenting and attachment setups, and using taxonomy_default, a different default locatoin in the site's structure. It works well, but I wonder if the attention onf flexinode and such are overkill for this sort of thing.
--Jeff
--
Eaton — Partner at Autogram
sounds like its worth a try .. :-)
Maybe its a way to have different nodetypes of the same "codebase" for different users ... ? Like
story4me,
story4you,
story4others
But maybe that can be achieved simpler :-)
Roland
Could preserve backwards compatibility too
One problem with getting rid of story or page would be the number of sites that would need to be upgraded. While it would be trivial to change all stories to pages in an upgrade script, it would render many existing sites foobar. If a polymorph-node were introduced that could be a story or a page (plus anything else you wanted to call it), backwards compatibility could be preserved. Interesting idea. May not be especially hard to implement.
- Robert Douglass
-----
Rate the value of this post: http://rate.affero.net/robertDouglass/
I recommend CivicSpace: www.civicspacelabs.org
My sites: www.hornroller.com, www.robshouse.net
Continuing with the idea...
...Now I'm really thinking through this.
The Need:
Simple title-plus-body content types that differ only in add-on features, permissions, and taxonomy settings. Page and Story are examples of this need.
Why Not Flexinode?
With CCK in development, and Flexinode's sub-optimal data storage/theming, I'm leery. Also, Flexinode is geared towards creation of content types with additional fields and data types -- for simple nodes, it adds a lot of overhead.
The Possible Solution:
Create a tool for spitting out prefabricated 'xxxx.module' files as needed, or create a polymorphic 'basic node' module that can spawn off page, story, and other node types. This might work in a way similar to flexinode, without the elaborate mechanisms for alternate fields.
Thoughts?
--
Eaton — Partner at Autogram
I was thinking more along
I was thinking more along the lines of just making the node_type hook dynamic and allowing the admin to enter new node names. The problem with this, of course, is getting the other hooks called later. If I tell Drupal that page.module is also responsible for a node type called "huba", does Drupal look for huba_view and huba_load, or do page_view and page_load still get called, in which case they can handle the different node types internally. You follow me?
- Robert Douglass
-----
Rate the value of this post: http://rate.affero.net/robertDouglass/
I recommend CivicSpace: www.civicspacelabs.org
My sites: www.hornroller.com, www.robshouse.net
chx is the man
http://drupal.org/node/29794 has a new module he threw together -- it does just what we're discussing. No frills, no bells or whistles, just a simple content module that lets you spin off multiple content types dynamically for unique permissions and theming.
--
Eaton — Partner at Autogram