if an alias is manually created, don't automatically replace it on edit

This is actually an old issue, but the problem is how do we know that the alias was created manually? There is no indication in the database of this fact. Pathauto could create it's own database for that, but I don't like that idea in terms of scalability/performance.

So, until someone adds a column to the path_alias table that indicates a priority or a "who added this" kind of information then this feature can't be added. That can't happen until Drupal7, so I'm marking this issue as postponed.

Can you clarify why this can't happen until D7? I'm sure this is naive in some way, but it seems like pathauto could just add a column to url_alias or create its own table that's just (pid (int FK), manual (bit)) to track that information.

Adding columns to core tables is not considered a good idea. I certainly won't do it.

Creating a new table that is related would work, of course, and I'd entertain a patch for that. However, whomever makes it should benchmark it on a site with 500,000 nodes and make sure that node submission and bulk updates perform the same before and after creating that table.

The support for weighting and the concept of "who created the alias" is at least this old: http://drupal.org/node/32958

If you want to see this feature then I suggest working on getting that extra column (or two - a second for weights) into core.

What about simply querying the alias if one already exists and using that one by default instead of an automated one, with the option of an "Automatic alias" defaulted to "off". I haven't looked into the code to completely see how this would function but this seems like a simpler option to me.

Possible?

brenda003 - isn't the solution you describe already available via the "Do nothing, leaving the old alias intact" update action?

Marked http://drupal.org/node/182143 as a duplicate of this.

Perhaps the middle ground would be this:

If nothing that would require a change in the alias has actually changed, don't update the alias.

For example, if I'm only editing the body of a Page, I don't need a new alias for it.

I know this all comes down to having properly setup the pathauto settings to always produce the right alias for each given type of content, but sometimes exceptions are required.

-- nex

nex - that may be possible, but require more work/code than I'm willing to do for this. if someone else does and gets tests/reviews from a few other people then I'll consider it, but not otherwise.

How about generate the alias during the form_alter of the node edit screen. Compare it to the one that's already in the path box. If it is the same alias, leave the 'automatic alias' box checked. If the alias doesn't match, leave the box unchecked, because this node is using a customized alias.

@goddfadda - I prefer the "create a new table" proposal. That seems more robust and actually could have benefits for the gsitemap module as well.

for the record, the columns would be something like: pid, object type, id, alias_created_by. With a unique index on pid.

The performance problem only exists on creation of aliases. Now that bulk updates are scalable I'm no longer really concerned about slight additional load during alias creation.

That is to say, I don't think there's need for performance benchmarks as a hurdle for this patch to go in.

It's not the prettiest thing ever, but it works.

Note that this is a case where I would really appreciate people helping me test this and also where (since it creates a new db) if you test you should be familiar with creating/dropping database tables.

Also, the table that this creates has a bunch of columns that are unnecessary for the purposes of this patch and it doesn't really keep accurate information (there's no hook_pathapi, for example, so there's no way to listen for the case that an alias is deleted, or updated). But the information it keeps is accurate enough for the purposes of this issue. I'll create more issues later to build out the full functionality.

In terms of performance - I built a test site with ~8,000 nodes and didn't see any statistically significant differences in performance. This patch gets involved on object insert, bulk generate, and node edit. So, those pages are already things that people are used to having as slow operations and they are already scalable. I don't see this as a huge deal.

I applied this to 5.x-2.x.

I need to rewrite it to use the schema API for 6.x and I haven't looked into that just yet...

Committed to the trunk as well - though I didn't test it yet...

Users of HEAD at this stage should be cautious enough anyway.

Automatically closed -- issue fixed for two weeks with no activity.

Reopening because I discovered that this patch fixes the problem as long as the user has "create url aliases" permission.

If the user does not have this permission -- and the "URL path settings" part of the content submission form is hidden -- the existing (custom) alias is overwritten by a new auto-generated one.

To reproduce:

1) as administrator, create a node and set its alias to something custom, like "about"
2) log out
3) log back in as a user without "create url aliases" permission.
4) open the /about node, edit it (or not) and save your changes.
5) page will direct to new custom alias.

Pathauto was set to "Create a new alias. Delete the old alias."
This patch was applied before testing: http://drupal.org/node/198413

Kevin

Marking active.

Kevin -- thanks for finding this.

The feature is done, but had a bug or two. New bugs should be in their own issues ( like http://drupal.org/node/201659 for the one you've found here).

I had to roll this back because it was causing several other bugs and I don't have the time now to fix them all. See the other issues it caused and explanation for why I can't do this plus the fact that nobody else decided to step up. The offer for a co-maintainer always stands, of course, if anyone wants to pick this up and run with it.

I'm attaching the patch that rolled this back so that work can progress from this point in the future (though it would probably be best to do on a separate branch this time).

I plan to work on some changes to the core alias system in Drupal7 to allow a feature like this and also remove some of the headaches that pathauto and xmlsitemap and other similar modules have when dealing with aliases. Those changes will make adding this feature back much easier.

Marked #250584: 'Automatic alias' option for nodes is counter intuitive as a duplicate.

Subscribing, and will review all the existing work. I'd like very much to help on this. I have some travel coming up in a few days, but by the end of the month, I should have been able to review this and see if there's anything I can do.

subscribing

subscribing

Can't you just go into the 'Pathauto' settings, then click on 'General', and where it says 'Update action' click on 'Do nothing'?

Sanehouse, thanks for the tip, that solved it for me.

I am going to see what I can come up with, (greggles sorry for the duplicate, i couldn't find this one). My plan is to do a check and see if the alias when the page is being edited matches what pathauto would generate. if it does leave the box checked, if it is different then uncheck the box to allow the users custom alias to remain. I hope to have something early this week but I do not know how much time I will have to work on it.

edit:
under the pathauto settings update action, on update do nothing, leave old alias intact. Can someone confirm that this works for them too? It would have been nice to find that before opening the issue....oops

@bmagistro:
I think the point of this issue is that if you choose "Create a new alias. Delete the old alias." for the option "What should pathauto do when updating an existing content item which already has an alias?", you might only want it to change the alias if it was one that pathauto originally generated. If you unchecked the box on the node edit form and entered your own alias, then later edited the page again, you might want to keep your custom alias. (Similarly if you select the 2nd option Create new and keep existing - you might only want the additional, new alias if the original was not a custom alias.)

There is a potential problem with your suggested approach if the admin changes the automatic naming scheme. Then an existing alias might be considered "custom" since it didn't match the new rules, and hence it would be left unchanged even though it should be changed. (Of course leaving URLs unchanged might be desirable in order to prevent missing content when people try to access the content via a bookmark or link on an external site, but that's a different question altogether.)

There's quite a lot of complexity here!

@bmagistro: Yes, i can confirm that the 'do nothing' option works for us, and I think that is the same effect as your proposed change would have, so I'm not sure I see the value added in your approach.

Unfortunately, therefore your solution may not work for us, because we only want pathauto to change the URL when fields are altered that affect pathauto. If the user has changed the URL and saved the content, at that point the pathauto-generation algorithm won't match the existing URL. So when the page is opened for a possible change, your test is valid. But after I've changed something that is in the pathauto field, you can't tell whether the different between the pathauto URL algorithm and the existing URL was from a field being changed, or a pre-existing condition.

Unless you save state information before the node is modified, of course. Then your saved state tells you whether the URL was automatic before. (And you'd probably want to have an option (yes/no/prompt/apply to all) as to whether pathauto overwrites, in the case where the URL was not automatic but the fields also changed.) If you have access to the saved state I think this should work, and likely we would be willing to test it for you (our site has a few thousand nodes).

@graybeal:
@gpk:

I decided not to make any changes as that works the way I wanted. I am just wondering if I made that change on other sites when I did the initial setup and just didn't pay attention to it this time....

subscribing. hopefully this will eventually make its way into a 5.x/6.x release.
RP