Jump to:

Using the url 'node' for Drupal's default front page is a bit awkward. While it makes sense from a technical standpoint (it's provided by Node module after all), there are a few important problems.

The path -- 'node' -- uses internal Drupal terminology rather than a meaningful path for visitors. This makes it difficult to use for anything other than the default home page.

The visitor-facing 'latest content' page shares a URL with the admin/contributor-facing 'add new content' page. "node" and "node/add" seem related, but have little to do with each other given the access rules and promotion rules that govern what shows up at node.

It's an undifferentiated river of news, and there's no way to find lists of a single type of content without installing Views and replacing it entirely.

I'd like to propose the following:

The 'node' path should be renamed to 'latest'. Although it's technically 'latest-promoted', it's a better representation of what's there than 'node'.

Possibly change the descriptive text of the 'Promote to front page' flag, to remain applicable if someone chooses another front page URL.

Allow administrators to disable the generation of the 'latest' page entirely form the content settings page, in case they want to build their own listing pages at different URLs with views and don't want it cluttering things up.

There are a couple of second-order additions that would be easy to build on top of this change: for example, a per-content-type option to generate a type-filtered listing page underneath the 'latest' url. 'latest/articles' for example. #23298: Entity bundles should declare a plural form of their label would be a nice compliment to it, as generating the plural form would already be taken care of. Even without that, however, changing the URL would make it much easier to reuse.

Comments

There's quite a few things to discuss here. Not sure I have any answers, just more questions.

First of all, in principal it sounds a sensible idea.

If we get rid of /node, how do we feel about the /node/[nid] paths? Do they then feel sort of stranded? Or is that not really a problem, as it's just an internal path and we should all be using path aliases, anyway?

Should /latest just be a path alias for /node?

It's always fun to go to a fancy-looking Drupal site and type /node to see everything messed-up… ;-) Being able to switch off /node (or /latest) would be useful.

Does "Promoted to front page" still make sense? Should it be there as a flag or should it be a field (included in the standard profile)? Should the node module be making the assumption that any nodes might appear on the front page as the front page may not be /node (and often isn't)?

We absolutely need to namespace all node paths, since in D7+, nodes are just one possible entity type that may contain "content".

Though I can also understand the problem of clean URL design... 'node/recent' showing latest content, but 'node' itself pointing to nirvana, is probably suboptimal... same applies to a hypothetical user listing... which, as of now, couldn't live on 'user'.

Plural forms could be considered as an option, but they're namespace violations. They set a quasi standard allowing "foo" to register router paths being the plural of itself, "foos". Hence, consider two independent modules, "view" and "views", "box" and "boxes", etc.pp. -- who's right?

In the end, I don't think the router path is actually wrong. We can simply add a URL alias for 'node' to be 'latest' or whatever. And could also rename node.module to content.module, which in the end, would probably make a lot more sense in light of D7+ entities in Drupal.

Yeah, I can see that being problematic. of course, providing any sub-pages underneath /node would collide with the existing node/$nid path. So something would have to be done if we wanted it to be filtered in any way. At the end of the day, there are really two scenarios where the current system falls down and simply using path aliases can't help:

When someone simply does not want the node listing page to be accessible at all. Right now the only solution is to use hook_menu_alter and change access callbacks, or something funky like that.

When someone wants to provide a different listing page for each (or only a few) specific types of content. Setting one particular type to always be 'promoted to front page' works for ONE type, but not for anything else.

It was suggested in IRC that these settings (provide a listing page for 'promoted content', provide a listing page for [article/simple page/etc] content, and so on) could be consolidated on the Content Publishing administration page. I'm willing to accept the need to use path aliases for the listing pages if a user wants to override them, as long as the pages themselves can be explicitly turned off if necessary.

One concern that's been raised is that it would collide with Views. This, IMO at least, is a non-starter. Node module's existing /node page already collides with the Views module, Tracker module collides with views, the content administration form collides with Views. Providing a small number of settings for how core's default listing pages are built doesn't put it in the realm of a configurable, pluggable, theme-able, alterable list generator and manager. ;-) Until the day we're willing to bundle Views with the core Drupal download, we need some way to make the listing page a bit more granular. Views would still be an easy transition for people who need to customize the appearance or rules that drive their listing pages.

Personally? I'd advocate exposing a listing page/sidebar block/rss feed for 'promoted nodes' and each node type. Use the Content Publishing settings to toggle each one (or allow them to be toggled on the edit form for that particular content type).

I'm strongly +1 on changing this to 'latest.' Long ago I was conflicted about it, because I believed that our node/1 URLs made it important to provide a listing page as a parent URL. However, from a purity standpoint our current front page is a bad match for that purpose: it isn't a list of nodes. Rather, it's a list of promoted nodes with sticky nodes prioritized. 'Latest' makes sense -- it accurately describes the intent and operation of the default home page, makes the paths for any filtered sub-URLs more sensible, and so on.

Since we use that path to "promote" (current terminology that I don't like particularly) content to it and because some content might be "sticky on top" (so not actually latest), it might make sense to use /featured instead.