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.

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.

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

subscribing

Tracking. It's really annoying to have to uncheck that box every time for every node.

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

Problem with that is another issue -- http://drupal.org/node/228762

It seems like a lot of other per-node/per-alias features got tacked onto this issue, which in turn resulted in the eventual rollback.

I propose a slightly different approach to making the node form checkbox behavior more intuitive. The path generation behavior could be specified on a per-node basis--overriding, but mirroring somewhat, the general pathauto config options:

1. Do nothing. Self-explanatory; pathauto doesn't touch existing aliases or create a new one.
2. Generate URL alias if none exists. Mostly important on node creation; if there is no alias for the node, make one.
3. Re-generate node alias on node update. This would be useful for keeping individual URL aliases in line with the values of their tokens without having to resort to a bulk update.
4. Use custom alias. Just use the value entered in the path module's normal box.

Again, these settings would be applied and remembered on a per-node basis. To implement this I'd add a simple table with only two fields: the nid, and the saved value of the option for that node.

The table would need to be created on install, deleted on uninstall. The table would be accessed only on node creation or update, so no performance hit normally. Not sure whether bulk updates should "pass over" individual nodes with "use custom alias" set or not...

Anyway, there would be no need to track the alias or anything--that still goes in the core path table. No need to track who created the alias, because whoever sets the value for this option on the node form has create URL alias permission anyway. If a user does not have that permission on node create, the default behavior from the general pathauto settings is used.

xjm - patches are definitely welcome. This is the most duplicated feature request in the Pathtauto queue so I'd love to be able to fix it.

I build sites that have non-technical staff adding content. They often don't like the paths that Pathauto comes up with and so they have the motivation to uncheck the Automatic Alias box to get the path they want. But of course they don't remember Automatic Alias on subsequent updates because it's not the current concern and it's just too technical for most.

I would love to see this addressed in D5 and onward. I don't have the technical skills to pull this off. Greg, do you have a chipin or some way we can all pay you to make time to add this functionality?

I'm not interested in working on this myself for 5.x. If someone else would like to build a chip-in and do the work themselves, I would welcome it.

Thank you for the reply. Are you interested on working on it for D6?

Well, since this is a feature it would really have to be done for 6.x-2.x if it is done at all.

What I meant by which version is that that ideally there would be a change to core url_alias table which provides object type and object ID along with the src/dst. This is only possible in 7.x and I haven't started working on it or making a case for it yet...If I work on this it will likely be for 7.x.

Alright. Since no one has stepped up with a patch or a "chip in", and everybody keeps asking about the feature, I've gone ahead and created a ChipIn. So, if you want the feature, you can help get it in by donating to the cause.

Greg and I have discussed this, and (as he's stated a couple times before) he doesn't want to work on it, for various reasons. We have agreed on an approach though, so that the final result of the work will get committed.

Excellent! I just put $50 on it. 11 more people at that some amount and we have ourselves a solution!

subscibing

I haven't implemented this work-around, but it seems to me that it would work and might even be a better solution if the maintainer of content isn't very technical.

I usually create a content type for pages in each section of the site. This is so I can create the path that I want. Sure, I could do it by having the editor select a taxonomy term, but there are often different fields needed from section to section. For content type "A", I might have this path defined:

a/[title-raw]

But what if we took away the Menu Settings field from editors completely and instead provided a CCK field called "Page Title" or something like that which explained to the user that this field was going to be the actual file name in the URL. Then you could set up Pathauto like so for that content type:

a/[field_page_title]

.. or something like that.

Then all the path stuff would happen in the background. Sound good?

i've been thinking about this for a while, and it seems to me like the thrust of the issue makes things more complex by assuming we should only not update the alias if it's manually created. it's probably better to simply not update any existing alias by default - that is, changing the url alias requires deliberate user action. this is good for two reasons: it encourages permalinks, and not updating the alias when one already exists is very simple to code. i've implemented this as a dependent module that overrides the default pathauto checkbox state, but on reflecting, it may make sense to integrate this behavior into the module itself.

@michaek - how is that different from the behavior available under "General settings" in the "Update action" radio button "Do nothing. Leave the old alias intact." ?

Marked #274454: Manual and automatically maintained aliases and #315539: Disabling automatic path does not work; overwrites manual setting on next time as duplicates of this.

subscribing

+1. Subscribing.

subscribing

sub

subscribing

@greggles, the problem for me is that this doesn't work as expected.

If the "Do nothing" option is selected, you would expect the "Automatic alias" checkbox to be unselected. It's not just a semantic issue - that is, you would expect that whenever "Automatic alias" is selected, an automatic alias *will* be created for you when you submit regardless of general setting - but a functional issue. Once a node has had an alias automatically generated for you, you can't automatically generate another at some time in the future, for example, if you have a book page that has moved between parents.

In summary, this is what I would expect:

1. When you have "Do nothing" selected, the "Automatic alias" checkbox should be unselected if there's an existing alias.
2. When you have "Do nothing" selected and the "Automatic alias" checkbox is unselected because there's an existing alias, and you choose to manually select the "Automatic alias" checkbox, a new alias should be created.

Thinking about it, this would also require an extra "Do nothing" setting so that there's now two instead of one:

1. Do nothing. Leave the old alias intact. If Automatic alias is selected, create a new alias and leave the existing alias functioning.
2. Do nothing. Leave the old alias intact. If Automatic alias is selected, create a new alias and delete the old alias.

I hope this make sense. Please disregard if this issue has already been fixed in 6.x-2.x-dev but I didn't think so because of all the new subscribers to this post.

Actually, when thinking about the second part of the problem, I think it would be good to have two checkboxes on the node edit page: "Create Automatic Alias" and "Delete Existing Alias".

Then in the Pathauto settings, there would be two separate sets of radio button groups:

1. If an existing alias exists:
Create Automatic Alias should be [checked] or [unchecked]
Delete Existing Alias should be [checked] or [unchecked]

And then when you submit the node edit form, these checkboxes do exactly what they say way they will. The Delete Existing Alias checkbox would only appear on the node edit form if there's an existing alias.

@dazweeja - I have no context for your comment and am not going to spend time to try to understand it. This issue is postponed and waiting on funding (and not even all that much funding). So, if you are unhappy with the way pathauto currently works and want to see this issue fixed, send some money to the chipin.

http://freso.chipin.com/fixing-issue-180440-dont-automatically-replace-m...

I didn't think programming was the issue - it's only a couple of small changes to pathauto_admin_settings and pathauto_form_alter after all - I thought the issue was more about what's the best way to solve the problem. I'm not really sure what the solution is that you'd like me to chip in for so I can't judge whether it solves the problem that I think is being described in this thread. There seems to be a bit of discussion in this thread about what the problem is and various people have tried to solve it in different ways. That's what I was trying to contribute to.

I was replying to your last comment (#45) which suggested you didn't know why michaelk would want to do what he did. If he's like me, he wants "Automatic alias" unchecked if there's an existing alias so that he can choose to check it and automatically create a new alias. If he has configured "Do nothing" and the checkbox is ticked, a new alias won't be created. If he has configured "Create new alias", he has to untick the node every time he edits the node or his existing alias will be overwritten (this is what the subject of this thread refers to). They are both part of the same problem.

I was also suggesting that the current system is confusing from a UI perspective too - if he's chosen "Do nothing" and there's an existing path, the checkbox should be unchecked otherwise it's confusing to the user about what's going to happen when he/she submits.

My solution solves this problem without the need to create a new table. The least disruptive fix is to have four options for the variable pathauto_update_action instead of 3, and have pathauto_form_alter behave as described in my posts. Ideally, I would replace pathauto_update_action will two new variables pathauto_create_alias and pathauto_delete_alias, each either true or false, but this is slightly more work.

I'm sorry if my suggestion is unwanted and I certainly didn't intend to be rude. I follow some threads on core and they seem to describe a problem and then everyone chips in with what they think is the best way to solve it. I think it's great that you've contributed your time to this so of course you can do things the way you want. I'm happy to rewrite the two functions in question and submit them to you if you think my solution is a good one.

Sorry, should have said that pathauto_create_alias, _pathauto_set_alias and _pathauto_existing_alias_data might need some minor tweaking too.

This problem has been driving me mad! I just donated $50. Hopefully it can be patched sooner than 7.x!

sorry if i was unclear. what i meant is that the "Create Automatic Alias" checkbox on the node edit form should be unchecked by default for an existing node.

its current behavior, being checked by default, can result in inadvertent overwriting of existing aliases.

if the "Do nothing. Leave the old alias intact." option is selected in the configuration, that does prevent accidental overwriting, but it is not possible to change the alias for an existing node intentionally. that's not desirable, if the node has the "wrong" alias.

i don't think this is an edge case - i think it is quite normal that a user may create a node but forget to assign a custom alias, then wish to correct that mistake, while still expecting custom aliases not to be unexpectedly overwritten. is that clearer?

Subscribe!

This drives me nuts as well. IMHO, it MUST be fixed, not in Drupal 7, but here and now by doing whatever it takes. The bottom line is that Drupal 6 has to work smoothly without causing any user anxiety!

I dont have the codding skills to offer code to do this but what if there was an admin setting that determined that an alias is only created when new content is created. That way when I have a custom path if I updated anything nothing changes because I set that setting. This would add a quick query for the setting when saving a node but it would not change anything for bulk updates. A button could be add that would override this to regenerate alias. I am not sure how hard that would be. I have read through this and this seams logicly similar to implement than the posts above. I would however agree that this is a big issue for many sites.

Thanks,
Steve

Subscribing. Four Kitchens has chipped in $50 towards the solution of this important issue.

subscribing also - Donated $100. Come on people, this is an important issue for a great module. What's $50? Just add it to your next project.

subscribing

I think that I solved the problem and actually worked fine for me. You need to overwrite the current pathauto.module with the one attached and alter the "url_alias" table with the following instruction: ALTER TABLE `url_alias` ADD `auto` ENUM( '1', '0' ) NOT NULL DEFAULT '1';

I tested it on my local installation, but I don't know if altering the table can create issues on other modules.

The attached pathauto.module avoid the automatic change of the alias if the user hasn't the "create url aliases" permission.

I don't think that's the issue here, as often times someone *will* have that permission but you still don't want it to automatically remove the old URL.

What I've seen suggested by another developer (Ryan Price) was to separate the form into "New Node" vs "Existing Node". With a new node the "create automatic alias" would be checked, but when editing an existing node it would be left unchecked so as not to override what was already entered.

I don't think that's the issue here, as often times someone *will* have that permission but you still don't want it to automatically remove the old URL.

What I've seen suggested by another developer (Ryan Price) was to separate the form into "New Node" vs "Existing Node". With a new node the "create automatic alias" would be checked, but when editing an existing node it would be left unchecked so as not to override what was already entered.

Here's a patch for v5.x-2.3 to do what I suggested in comment 67 above.

For v5.x support, would it be possible to create a branch for v5.x-3.x-dev to cover this architectural change? That way the v5.x-2.x line won't be massively changed but there'll still be a proper path for us on sites still stuck in the dark ages ;-)

@ Damien: The short answer is: no.
We don't have the man power to further develop the 5.x branch(es). Any new development (ie., not bug fixes) is and will be 6.x based.

Since only half of the $600 was raised, I've created a new ChipIn for the remaining $300.

There are 7 people since the announcement of the original ChipIn who have contributed with nothing but "+1" or "subscribe" or "this is really important!!!" or similar. $300 divided by 7 is $42.86. If we add the five with similar useless comments from before the announcement, it's $25 per person. If it is really that important, this should not be too much to part with.

Anyway, have a nice weekend! :)

With a new node the "create automatic alias" would be checked, but when editing an existing node it would be left unchecked so as not to override what was already entered.

@DamienMcKenna, That's an interesting idea and probably works fine on some sites, but it's not what the overall userbase of Pathauto needs.

Freso,

I was thinking of just creating the v5.x-3.x-dev branch and leaving it as-is until someone comes up with a good patch to cover all of the changes. If the current dev team doesn't have the time to do this, it may be possible to twist my arm :)

@greggles: How about if I turned it into a setting, e.g. "Default state of 'Automatic alias' checkbox when editing node"?

Freso, is there an exact plan on what the fix would be?

This would actually be a really simple fix if we have a function that returned the generated alias from a node object without actually saving the alias to the database.

'#default_value' => (pathauto_get_alias($node) == $node->path,)

I am pretty new to developing for Drupal, so excuse my lack of knowledge about hooks, and variables, etc., so this is a very non-technical explanation of how I would design a solution without adding new columns, tables, and other overhead. If it makes any sense then hopefully one of you can take this approach the rest of the way.

-add two hidden fields to the "Automatic Alias" section of the form, one to store the previous node title, and another to store the previous alias value

-upon form submission, compare the value of a generated alias for the previous node title to the previous alias value. If they are different, then the alias must have been manually generated, correct?

-If the alias was manually generated then compare the value of the previous alias to the actual submitted value. If they're the same, then the user didn't want to change the alias so skip the automatic alias generation.

make sense? more difficult to do than it actually sounds?

@pcranston Yep that's basically exactly what I proposed in #76.

As a very basic solution, I'm using this in hook_form_alter. It's not quite right since it disables the 'automatic alias' checkbox when ANY alias has been set - automatic or user specified , but it's better than having the checkbox always checked and user specified aliases replaced with automatic ones all the time.

// If a path has already been set for this node, don't automatically tick the 'Automatic alias' box.
if(strlen($node->path)){
  $node->pathauto_perform_alias = FALSE;
}

It means I get an automatically generated alias when I first create a node, and I simply have to check the automatic alias checkbox and save the node if I want it to be regenerated at any point.

@pcranston, @dave reid - and what about the situation where the pattern does not include the title? We need a robust solution.

@mrfelton -

it's better than having the checkbox always checked and user specified aliases replaced with automatic ones all the time.

Better for you != better for all.

Here's the patch I've been testing locally. It adds a new 'return' $op to pathauto_set_alias that simply returns the generated pathauto alias without saving it to the {url_alias} table. We then use this value in pathauto_form_alter() compared to $node->path to set the default value for the $form['path']['pathauto_perform_alias'] checkbox.

Interesting to note, the $node->pathauto_perform_alias variable never seems to be set, ever.

I couldn't get mrfelton's exact code to work, but I was able to figure out a minor modification to get it working for me (Drupal 6.6, Pathauto 6.x-1.1). His approach is totally sufficient for me.

I added this code to pathauto.module after the delcaration for $form['path']['pathauto_perform_alias']:

// If a path has already been set for this node, don't automatically tick the 'Automatic alias' box.
if(strlen($node->path)){
	$form['path']['pathauto_perform_alias']['#default_value'] = FALSE;
}

(like I said in my post yesterday, I'm not too familiar with editing hooks, etc, so if I could have just dropped that statement in a file somewhere else other than editing the module directly let me know)

@pcranston:
You could create a small custom module with just this in it - probably better than editing pathauto directly.

/**
 * Implementation of hook_form_alter
 */
function mymodule_form_alter(&$form, $form_state, $form_id){
  // Only do this for node forms
  if (isset($form['#id']) && ($form['#id'] == 'node-form') && arg(0) == 'node') {
    $node = $form['#node'];

    // If a path has already been set for this node, don't automatically tick the 'Automatic alias' box.
    if(strlen($node->path)) {
      $node->pathauto_perform_alias = FALSE;
    }
  }
}

-----

@Dave Reid:
I like it - but it's not quite working for me. Changing

'#default_value' => !empty($node->pathauto_perform_alias) && (!isset($node->path) || ($alias == $node->path)),

to

'#default_value' => !$node->pathauto_perform_alias && (!isset($node->path) || ($alias == $node->path)),

seems to do the job though... Why did you use empty()?

forgot to attach patch

@Dave Reid - your idea strikes me as a potentially good one, but it also seems like it would not work for a lot of situations like where people use the current date/time tokens as part of the pattern.

greggles:
* How often would people want the automatic URL to change after a page has been published?
* How about if we have two configuration settings: one to decide whether the flag is enabled by default when editing a page that has not already been published, and another editing a page when the page *has* been published?

* How often would people want the automatic URL to change after a page has been published?

Very often. 3 out of the 4 update actions do that and they are the most popular.

* How about if we have two configuration settings: one to decide whether the flag is enabled by default when editing a page that has not already been published, and another editing a page when the page *has* been published?

We cannot add more configuration options to the UI.

greggles:
Let me clarify on question 1: how often would someone edit a page and not only have previously changed the pathauto configuration but also want the URL format to change? In the situations I've seen a) the taxonomies and pathauto settings are assigned ahead of time and pretty-much never touched, b) any time the node is being updated the path the wish is for the path to stay as it was, c) any time the desire is to change path it is manually updated to a specific string, d) on the occasions when URL schemes from pathauto are changed the process has been to recreate the URLs en masse rather than one at a time.

On question 2, why can we not change the UI? This is a bug, not a feature and need to allow people to decide which way they prefer? Just the fact that there are 87 comments (now 88) on this thread should suggest to you that many people consider this a flaw.

Now that you've clarified question 1 - I'm not sure, but I guess not that many.

2: the number 1 complaint about pathauto is that it has too much stuff in the UI. So, even if this issue has a lot of comments on it I refuse to add yet another checkbox to the UI (I don't even see how that would help fix the underlying problems, but it is absolutely not part of the solution).

greggles: for q.1, that's what we've been trying to explain all along, I'm glad we finally phrased it so you understood our dilemma.

For #2, would you consider adding it as a patch, releasing a dev / beta version to see what the feedback is, then add a poll to see whether people like it or not? Or, just have the variable available but just not provide a settings option for it, so those of us who know could override it through our settings.php? With the latter option, there wouldn't be any visible change unless someone RTFM / RTFC and made the change themselves.

Please forgive my ignorance, but it seems like this would all be a non-issue if Pathauto just remembered whether or not the 'Automatic alias' checkbox was checked for each node. Is this not possible?

this would all be a non-issue if Pathauto just remembered whether or not the 'Automatic alias' checkbox was checked for each node. Is this not possible?

That is what freso _will_ build if/when people finish contributing to the chip-in.

The issue has been discussed completely. I'm closing comments because there is nothing more to discuss. If you feel strongly about this, chip in.

Double edit: original chipin closed, new chipin - http://freso.chipin.com/fixing-issue-180440-dont-automatically-replace-m...

#369840: If a user changes the automatic path, try to remember that in the future is now committed which fixes this issue. Please help test the 6.x-1.x-dev branch and report any problems there so I can make a new release.

Better status. Also, it's somewhat amazing nobody has chimed in with results of testing.

Greg, despite the lack of support financially and otherwise, this was a needed and useful fix. Thanks to you, Dave Reid, and the other contributors for doing it. I'll try and free up some time to work with it.

-Greg

Well now, don't know about all of ya but I found this to be a little disconcerting but have figured out a safe and stable work around.
I do not want tons of aliases that are worthless in db so I will not use "Do nothing leave old aliases intact" to make the unchecking of url path settings automatic alias stay unchecked when updating. So until a fix is made for this unusual dilemma I am going into admin/site-building/url-aliases/list then typing in url I want to change then filter or enter find the url alias I want to change click edit save old alias in mouse change alias to what I want then save. I then go to admin/site-building/url-redirect/add-redirect and copy old url into from and type new address into to and save. Magically then the check box for url path settings automatic alias becomes unchecked and stays that way even though I have something else checked besides "Do nothing leave old aliases intact"!!! For me I would have to type in the new alias in the node edit page anyway so doing the filter and finding it in url alias is not to much of a bother nor doing the redirect. I would like it to work as one thinks it should but until then this works for me. Hope this helps.

@97: what version of pathauto are you using? It should all be working better since 6.x-1.2.

using 6.12

Hi, Is this change also working for latest 6.2.dev branch please?

Thanks a lot for your reply on this already closed issue!
Greetings,
Martijn

@Summit: Its in all three major branches right now: 7.x-1.x, 6.x-2.x and 6.x-1.x.

Great! Thanks for your quick response!