Deleting Path Duplication Function - Effects?

Thanks Greggles

I've never tried the vocab/catpath pattern - I might give it a go on the next new section I create.

Your solution (I believe) is that Pathauto should send back an error to the user and say "that path is already taken, please consider another one". I think this would be quite confusing to a non-administrator user. They don't know what it is that they did that caused a duplicate path because to them they were just adding a term to a freetagging category, or creating a new node or some other similar action. For example, if you can create terms but not administer pathauto this would be very confusing.

Your understanding is right.

OK, I see the concerns (I've been thinking about them for some time now) and I'll try and speak as both a user and an adminstrator:

As admin, the problems (clearly) rest. But it goes beyond that: Modules get "confused" leading to dupe-path issues as well as unexpected behaviour (Taxonomy_Menu for one, as mentioned)... and then there's the database which becomes cluttered/bloated.

Ultimately, this must translate to the user if expected behaviour is "lost", and, over time, the system becomes weighed down.

As admin, well, I think there are probably 2 camps in the wild ATM:

- Those that are unaware that certain aspects of their site are either behaving unexpectedly, and/or, have dupe paths (I've seen enough of them to know they exist).
- Have nailed the problems down but are paranoid whenever any new content is added, whether by admin or user, and will, at some point, be faced with pruning down the "excess fat".

I'd see the "error" messages as being more of a clarification in most cases (it's all in the wording) as most dupes are probably caused by dupe terms, rather than file-paths:

- If there is a duplication of term about to take place; ask the user if they want to use the existing term (ie... within the existing vocab/hierarchy), or create a new one within another vocab (or hierarchy).

- If there is a duplication of filename about to take place, then simply offer it back for editing to make it unique.

I see this as giving the user control more than anything else. What's more, I don't think this is behaviour that anyone who's saved a file has not experienced before: "This file already exists. Do you wish to overwrite this file?... Click no to rename... blah blah".

My question about removing the dupe function was more of a personal one than anything because I'm seriously considering removing it as my "enjoyment" of both using, and adminstering Drupal is taking a knock.

I proffer the wider picture because it just seems the right thing to aim for in terms of having a predictable operation that interacting modules can depend, a leaner database and, single paths... these are negatives which outweigh the one in favour of minimising user interaction, IMHO, and, dare I say, in-keeping with Drupal philosophy.

basically the problem is that Drupal works fine with a duplicate node tite, or terms in different vocabularies that may cause a collision but which are unique in themselves.

Because Drupal assigns an unique interger id to each new piece of content (term or node)?... Regardless of of what's in that content (ie... whether it's dupe or not)?

So, if a user sees a message saying "Your title should be unique" or "Your taxonomy term should be renamed to be unique" that may be totally in appropriate.

I'm not sure if I'm understanding you in the right context here: Are you saying that it'd be inappropriate because Drupal, per se, "works fine with a duplicate node tite, or terms in different vocabularies that may cause a collision but which are unique in themselves."?

Especially given that an admin could configure aliases to only be 10 characters long, then when a user creates content which is unique at the 11th character they will be super confused.

I see your point on that score but I think that would be more of an admin set-up issue; afterall, we have that same "limit" option (or problem, whichever way you want to look at it) now

But if we do a rename of the paths we will have the same number of paths as before,

Well, not if I have path:

example.com/category/index.htm

and

example.com/category/index.htm-0

Just to be clear: I'm not talking (primarily) about unique content which "happens" to share the same file-paths as another file (though that's part of this discussion obviously); I'm talking about system/module operations which result in different file-paths to the same content as a result of this feature, which then become referenced by modules (or whatever).

The incidence of a user dupe-naming a title, is likely to be low. Dupe-naming a term is going to be higher, hence my suggestion that the same term-name, be "allowed" to be seen to be unique, if it belonged to another vocab - or directory - which then leaves open the option to present a choice to the user, ie... rename, overwrite (if permission), or assign to existing parent of the same name.

Currently (unless I'm missing sommat the [vocab]/[catpath] pattern resolves), I can only have the term, "software" once. Creating another "software" term, in another vocab or category, results in:

example.com/software/index.htm-0

Also, I don't make changes to help performance unless there is a thorough benchmark. I'm assuming you have no benchmark and my hunch is that this isn't a significant bottleneck.

I don't, you're right. However, if abstract argument can't win it alone, do we really want redundant paths bloating-up the database (apart from anything else)?

... already we have redundant: taxonomy/pathauto/term (From memory, could be wrong, but you know the one I mean!) entries, in addition to the one's being discussed.

Well, there's not much that Pathauto can do about that. To fix that you should file bugs in the other modules.

Well, here's the muddy bit then. As I see it, there's more pain and "damage" inflicted by this than not - It seems untidy, has a questionable existence (at least in certain contexts (no database wants duplication does it)), takes away user (and admin) control, causes problems with the SE's, problems with module operation and ultimately, problems with the user and admin experience (takes ages plucking out the detritus from the database don't ya know!).

If we can agree that we don't want the same content - in every respect - to be served by different paths (for the same purpose), and that it is not good practice to have those paths twice in the DB, when, again, they are for the same purpose, then surely we have to ask for the user's intention, at minimum?