Make q=node behavior optional/configurable

My vote is for removing it completely. Everywhere else I need a list of nodes, I have to use views and I never understood why /node should be the exception.

+1

Both of you are coming from the point of view of an experienced developer who is used to using views etc for creating lists like this.

The point of the page thought is that it gives something to display as a site's homepage as soon as Drupal has been installed - which most of the time will be for a new user - who will appreciate the instructions it gives.

However, a toggle on / off (default on) could be useful.

I can code the solution proposed in #3. I'll have something ready for tomorrow night, as I'd really like to see this get in =D

Because of the hook_menu_alter() this behavior *is* optional and configurable. I'm not sure that adding a new configuration checkbox will give us any good. At the minimum, this requires an usability review.

So reviewing, I don't necessarily see this as critical functionality at all. But I do see its use, as DamZ proposed one can touch it by code - is it more or less that people don't know how to?

The setting itself is rather harmless if you can come up with a label and description that people understand.

How about - instead of having the default page of q=node listing, which is partnered by the evil "start screen", we implement a few choices as a start screen, and then set up a default home page based on that choice?

That could form part of the install process, and would necessitate that at least any starting screen display would not be displayed to the public, right?

How about a choice of something like (I'm half asleep) :
- "display all content by recently added" (current default WHEN some content has been added)
- create some content now (select story/page and create then add as home page)
- something better

That would be a billion times easier with Views in core, of course...

I agree with that sentiment - I was just running with an idea that was somewhat rooted in usability for the new user, which seems to be forming a large part of D7 efforts (for whatever reason).

Note that the default "empty content" node page in Drupal 7 is already quite different than discussed above (see attached screenshots). And there is an issue at #126221: Make 'node' empty text themable. to make this page themable.

Also, you can already redirect ?q=node to a different page via the user interface (just use the Path module), right?

So I tend to think adding a new configuration checkbox just targeted at this is not a good idea. Maybe we want to explore doing something automatic, though (it certainly does seem that most people who replace the front page with something else no longer have any need for the ?q=node page anymore).

Do we need a place to disable MENU_CALLBACK menu items, and not just MENU_NORMAL_ITEM items? Or is that an appropriate way to divvy up the functionality available to different menu items?

Right, so I forgot that the /node page had changed in head. I'm going to set this back to unassigned until we decide on a good alternative.

I like the idea about a contrib module that can short circuit paths =D

The problem is that the core content types have the 'Promoted to front page' flag, which puts them on /node. If we want to add an option to remove /node, I would think it would have to remove the 'promoted' flag from the node form, too. In fact, if the front page is not set to /node, I think that option should go away or get renamed or something. But that's for another issue!

I don't think it follows that "Promoted to front page" would have to go away. It could just be changed to "Promoted" and site builders can interpret it however they want. In the same vein, there's a "Sticky at the top of lists" option for nodes that can survive never being used. Really, we'll just have to get the Flag module into core for D8. ; )

Hmmm. If you set homepage to /node (default setting) and use page-front.tpl.php for theming your homepage (instead of setting something else as your homepage and using page.tpl.php) - you won't run into such problem.

Any reason why you can't just use page-front.tpl.php ?

Why would you want to have to hack a template file to change the contents of the front page? That doesn't make sense.

My opinion suggests: /node functionality should be moved to a (small) "node_frontpage" module (or something like that), allowing it to be disabled. (enabled in default, already disabled in expert profile)

"Promoted to frontpage" should become "Promoted" (might want to keep it "Promoted to frontpage" when frontpage is set to /node and module is enabled)

no frontpage notice will show when no frontpage path has been set, or /node is empty (with appropriate links)

That way, power users can disable the /node functionality by disabling the module.

+1 for the suggestions in #19. Promoted to front page is very misleading from a UX perspective when the front page is not /node (or a view that replicates /node).

I agree with splitting out 'promoted', 'sticky', and /node behaviors into a separate module. Maybe there are some other node module functionalities that could go in there as well. Alternatively, settings for enabling/disabling these features would be fine.

Somewhat related: #1210366: Per-bundle node listing pages, blocks, feeds., #1066830: Change /node path to /latest and allow admins to disable., and #404300: "Promote to front page" is a misnomer

I've developed a module to add this functionallity to Drupal 7.

Maybe it could be useful, it is currently in my sandbox, I hope it can pass the aproval aproval issue:
http://drupal.org/project/node_page_admin

/node is now a view. It can be disabled. So if I'm right this issue can be closed.