Well, to even more clarify this story/page thing (it's very confusing indeed in my opinion), I would not just suggest to change "story" content type to "article" (see [1]) but to change the "page" content type, too.

I think, it'd be much clearer to mention that this option creates a page that is proposed to be (at least quite) static.

I set this to "needs more info" because I haven't got any feedback on this yet (just a few comments somewhere here on drupal.org, but this wasn't really discussioned anywhere).

[1] http://drupal.org/node/197765

Comments

gábor hojtsy’s picture

If you have the PHP input format, you can use any PHP code on the page, which makes it anything but static. Granted, most uses of the content type would be a static page.

JirkaRybka’s picture

I think "static" refers to the page being just put somewhere constantly, like "about us", "FAQ", "Contacts" or as a wrapper around some code in the mentioned PHP input format - as opposed to stories always moving off from the top inside various content overviews, front page including.

It might be also interesting, that Joomla (which we evaluated briefly with friends, before finally building our site on Drupal), calls this sort of thing as "Static content".

Bevan’s picture

Status: Postponed (maintainer needs more info) » Closed (won't fix)

I don't think static communicates the use of the content type. Please reopen if you disagree

LindenLion’s picture

Status: Postponed (maintainer needs more info) » Active

Two facts about the very special content type 'Page'!

  • The only documented difference between a 'Page' node and a 'Story' is that a 'Story' is by default promoted to /node.
  • Something which I haven't found documented anywhere is that the content type 'Page' is the only content type without the date-time-author-stamp! In fact, it is impossible to create a content type which behaves exactly the same as a 'Page', and once the content type 'Page' is deleted (at /admin/content/types) it can't be recreated... ouch!

UPDATE: it can be recreated by setting the global display settings of content types under theme settings, see also other comments.

I reopened this issue because of the second fact. Pages are quite static for the fact that they don't have a time stamp! (Which is why it's probably a bad idea to have FAQs as Page content types).

I changed this to a bug report because a content type which cannot be recreated should not be possible to be deleted. A solution would be to add an option for nodes to display a node stamp (author/date/time).

See michaelkillian.com/node for a demonstration of content types in Drupal.

keith.smith’s picture

Status: Closed (won't fix) » Postponed (maintainer needs more info)

The "Submitted by" is just turned off for Story in the theming layer, right? You can adjust these settings using the Global options at admin/build/themes/settings. If this solves your immediate problem, please set this issue back to "won't fix".

dman’s picture

indeed. The timestamp comes and goes according to your theme configs. By default it's off for pages and on for stories ... which works. You can toggle then as you please.

LindenLion’s picture

Title: Changing "page" content type to "static page" » Move or duplicate the toggle option for the node stamp from the theming layer to the global content type settings.
Project: Drupal core »
Version: 6.x-dev »
Component: page.module » usability

Thanks Keith! I went to Global options in my theming settings and indeed I could disable/enable the stamp. Now you've showed me I know it!

I think though that this a serious usability problem (taking myself as case study :-)

(D5.1 & D6.1:)
I looked for this setting under the content type settings and couldn't find it, but what I could find is the place where I can change the labels of the title field and the body field globally for all nodes of this content type. (The workflow and comment settings are only default settings for new nodes which can be overridden by node administrators.)

So I expected the 'display author-date-time-stamp' to be at the same place where I could change the names of the title and body field.

I had the feeling it might have something to do with the theming, but I didn't realize it could be global theme settings so I didn't even bother checking there. This is because I thought if the theming options where the problem then you would have to set it up every time again when you change theme. So it's not a bug, but a serious usability problem: having the option at a place where it is not expected... Also, I don't think it makes sense to have it under the theming options because the node stamp is not a fancy decoration, it is actually a critical part of information about the node.

I propose to move or duplicate the option for enabling/disabling the stamps to the individual content type settings. It could be under the same section as the submission form settings if we rename it to something like 'Global <content type name here> settings'.

I think this would be a small step in the direction of making content types more user-friendly...

I am aslo going to open another issue proposing to rename 'Content types' to 'Node types' for future releases, but first I'll have a think what else that implies. I think the whole concept of content types needs some radical refreshment!

dman’s picture

Totally agreed.
It really is in the wrong place to find. every single time I go to make that change I look in three wrong places before finding it. And I KNOW the option exists!
+1 for duplication of that selector. Easy code to add.

LindenLion’s picture

Category: task » bug
Priority: Normal » Critical

So who is going to duplicate the node stamp option from the global theme settings to the global node type settings? I've never done much coding, but if anyone is willing to help me with this one I can give it a try...

Cheers, Michael

sutharsan’s picture

Project: » Drupal core
Version: » 7.x-dev

Moving issues from User experience project to Drupal core usability component.

redndahead’s picture

Component: usability » base system
Status: Active » Fixed

From what I can see this has already been implemented. If someone knows the issue # feel free to mark this a duplicate with the issue #.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.