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.

  1. 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.
  2. 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.
  3. 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:

  1. 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'.
  2. Possibly change the descriptive text of the 'Promote to front page' flag, to remain applicable if someone chooses another front page URL.
  3. 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.

Thoughts?

Comments

mcjim’s picture

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)?
joachim’s picture

I'm sure there's an issue somewhere about changing the UI text for 'Promoted to front page', IIRC it didn't make it into 7.

> 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?

Yes, and yes.
It'll feel odd to developers for a bit -- but then /taxonomy is a 404 already, so we can learn to live with it :)

sun’s picture

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.

eaton’s picture

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:

  1. 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.
  2. 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).

eaton’s picture

klonos’s picture

...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...

Guess what? Views is now in core and /node (as in the site's front page) is actually a view enabled by default! Also, /node is not the first thing people see (though still a valid path). So,

@eaton: Is this issue here still relevant?

klonos’s picture

...and to what extent is this a dupe of #545758: Make q=node behavior optional/configurable? I think that at least the "allow admins to disable" part is.

eaton’s picture

Guess what? Views is now in core and /node (as in the site's front page) is actually a view enabled by default! Also, /node is not the first thing people see (though still a valid path). So,

@eaton: Is this issue here still relevant?

Hah. It's definitely relevant -- I *KNEW* that comment would come back to bite me eventually. ;-)

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.

klonos’s picture

I think that if we go ahead with the change to 'latest', then we should also rename the 'Frontpage' view to 'Latest content' (or plain 'Latest').

...but that's kinda OT here: #2029199: Rename the 'Frontpage' view to 'Latest content' or 'Featured content'.

klonos’s picture

Title: Change 'node' path to 'latest', allow admins to disable. » Change /node path to /latest and allow admins to disable.

...

klonos’s picture

Please also take a look at my proposal in #1201592-57: Front page settings cleanup

klonos’s picture

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.

xjm’s picture

Component: node.module » node system
Issue summary: View changes

(Merging "node system" and "node.module" components for 8.x; disregard.)

mitokens’s picture

GaëlG’s picture

Status: Active » Closed (works as designed)

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