When a module is turned on, I like it to do something. but in the case of pathauto, the something it does is not actually that helpful for the development of a site. Having all the content live at paths that start with content/ is not that much better than the system default of node/X.

Reasons the default path pattern should be removed:

- There is no value in the word "content" either to humans, or search engines.

- I've never seen a website that actually had a page that lives at /content.

- A website would have a real, live, human being decide where each type of content should "live" and assign path patterns based on the actual structure of the site.

- When a new content type is added this real, live, human being should return to the patterns tab and decide where the new type of content should live.
- - If there is an almost-acceptable path created for content of a new type, its easy to forget the step of creating a new path pattern. If instead no path pattern is used, it's very easy to notice that node/46 needs to have an pattern assigned.
- - Once a site has accidentally created incorrect aliases for a new type, it is not easy to delete the aliases for only that type (see [#http://drupal.org/node/870404])

CommentFileSizeAuthor
#4 remove-default-path-pattern-1215616-4.patch691 bytesqtbeee
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

jenlampton’s picture

Version: 5.x-2.x-dev » 6.x-2.x-dev

whoopsie :)

Dave Reid’s picture

Version: 6.x-2.x-dev » 7.x-1.x-dev

Having all the content live at paths that start with content/ is not that much better than the system default of node/X.

The point isn't necessarily the content prefix, but it's having the node title in the URL like 'content/title-of-the-node' rather than 'node/1'. We have to use some kind of prefix so that the default configuration isn't insecure and allows users to overwrite what look like internal paths.

Once a site has accidentally created incorrect aliases for a new type, it is not easy to delete the aliases for only that type

If this is the case, they can use the 'Update URL alias' action which by defaults updates with the new pattern and deletes the old alias.

- A website would have a real, live, human being decide where each type of content should "live" and assign path patterns based on the actual structure of the site.

- When a new content type is added this real, live, human being should return to the patterns tab and decide where the new type of content should live.

- - If there is an almost-acceptable path created for content of a new type, its easy to forget the step of creating a new path pattern. If instead no path pattern is used, it's very easy to notice that node/46 needs to have an pattern assigned.

Agreed we should probably start exposing the Pathauto settings in the bundle forms (e.g. content type forms, vocabulary forms, etc). This prevents the user from having to jump between two places to do this.

If we remove the default, you can be the one that answers all the support requests with 'Why isn't this working after I enabled it?' :)

Maybe in pathauto_install() we should check if the current install profile is 'default' and if so, install the default variables. That kinda respects what we're trying to do in the default vs expert profiles.

Also see #1165612: Change default pattern for content from "content/[node:title]" to "content/[node:type]/[node:title]" which is being discussed.

jenlampton’s picture

Version: 7.x-1.x-dev » 6.x-2.x-dev

I agree that the module should do something when it's turned on. What I disagree with is a default for ALL node types.

What if we added defaults for the types that come with the Standard install profile (see #1215676: Provide default patterns for Basic page and Article node-types with standard install profile) but didn't mess with the default path pattern - which shouldn't exist for any site anyway :)

qtbeee’s picture

I wrote a little patch that removes the default path pattern, we probably need to provide other defaults.

bverc’s picture

Perhaps the solution is to have the default set to [type]/[title-raw]

/2 cents

geodaniel’s picture

What are the security implications of having just the node title as the default (without the content/ prefix)? Presumably the module won't let you accidentally overwrite another path?

Jons’s picture

Issue summary: View changes

In admin/config/search/path/patterns I removed the 'content/' bit in front of 'content/[node:title]' and this generates the alias without 'content/' by default.

The only strange thing is that on the node page, the 'url path settings' tab still shows content/xxx (with 'Generate automatic URL alias' checked).

If 'Generate automatic URL alias' is unchecked the value is as set by editor, as expected.