Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.this is something i find myself doing pretty regularly when I first install the module.
"content" doesn't really tell the user anything. It seems like it is only there for namespacing nodes.
Most content types have an intelligible type though, so it makes sense to me that the URL should reflect that.
Comments
Comment #1
dave reidI think the problem is what if someone makes a content type 'User' to make profile pages, and now by default we could get aliases like 'user/logout' for a node with title 'logout'. If we change the default to content/[node:type]/[node:title] that would probably make more sense, but we shouldn't ship with a default that has a token at the first-level of the URL.
Comment #2
dave reidBLARGH. We currently violate this with the default term pattern!
davereid--
Comment #3
thedavidmeister commentedso is that a "yes"? :P
Comment #4
jenlamptonI don't think this is a good default either - Drupal doesn't assume anything about the struture of sites - and the most sites will not match this pattern all the time. For example: a 'Photo' type of content might prefer to have it's alias at gallery/[title] or portfolio/[title] than at photos/[title].
This also presents the problem of singular vs plural. Should it be blog/[title] or blogs/[title]? What about words that don't pluralize nicely? newss/[title] or news/[title]? And what about content type names that account for the difference already like blog-post and news-post?
I think this is going one step too far - and I would like to reinforce my idea to remove any quasi-intelligent default for ALL TYPES. (see #1215616: Remove the default path pattern since content/[title-raw] is a bad defaut)
There's no way we can make an assumption that makes sense for 80% of ALL paths for ALL node types (I agree with a having a token at the highest level being a problem) but we shouldn't replace that with one that works for only 5%. :(
Comment #5
thedavidmeister commentedi agree with jenlampton in that there probably shouldn't be any default at all, but are you saying that my suggestion only works for 5% of use cases? because if you don't use plurals, it works far more than 5% of the time... send me a random list of 500 singular nouns and we'll see how many could work well in a reasonable use case :P
if you have a "node-per-photo" setup like you suggest, it makes perfect sense to display "photo/[title]" actually. It may be more "wrong" than "gallery/[title]" for some use cases, but it is also "less wrong" than "content/[title]", which is what we have to actually compare this request to - the current system, not another proposed system.
imo plurals don't make sense, a url isn't totally analogous to file system like that. you don't have a "folder" called "blogs". The user clicks "create content->blog post" and the url displays "blog-post/[title]" which is totally sane, and inline with the way that pathauto/drupal deals with taxonomy terms, as pointed out by Dave Reid.
i guess a large portion of my objection to the current "content/[title]" convention is that many developers use content types as structure, or configuration, rather than content.
a gallery is a perfect example of that, if the galleries for the site are fixed by the developer upon launch, are they really content? or are they actually part of the architecture?
if content types are given semantically sensible names (nouns), then the [type]/[title] default would work whether the content type was configuration, structure or content.
IMO the technical objections raised by Dave Reid are actually more salient... how do you stop paths for nodes conflicting with taxonomy terms and users??
you probably can't in reality, without throwing confusing validation messages at end users, so i'll mark this as "won't fix"
Comment #6
jenlamptonYes, I would claim that the pattern you provided would work for less than 5% of all cases.
Here's why:
I have never visited a photo gallery on a website that lives at /photo but there are many that live at /photos. The plural in the path of the gallery implies that you are looking at more than one photo. On a well architected site that is often the path of the page view of all items of that type. Then individual items of that type should have a consistent path pattern: /photos/[title-raw]. When a site is built this way it creates the best possible experience for visitors. The paths on the site match the architecture. People can use breadcrumbs to get back "up" a level, as well clicking in the URL bar of their browser and hitting backspace.
When the path includes the name of the singular type, there's rarely content that would make sense at the path "up one directory" from the nodes. This generates a page not found error when people attempt to navigate a site in the usual ways (see above).
Even worse would be adding two "levels" up (two slashes in the path). This amplifies the confusion for visitors if they get a page not found twice (and who has a page on their site at /content anyway?)
Additionally, more slashes in the path is actually bad for SEO. Search engines see this as "distancing" content from the home page. More slashes = more "directories" = less important content.
So, I still hold that singular in the path makes more sense than plural. And with that assumption, the suggested alias pattern would only work for the set of nouns who's singular is the same as their plural, or where pluralness is implied by the meaning, for example: news or blog. That I believe is probably less than 5% of all nouns. This is a moot point now anyway, but there's my .02 if you want it. :)