I edited my node, unchecked the `Generate automatic URL alias` checkbox and typed my custom url into the path box and clicked save.

This is the value I typed: `blog/blog.cfm/aid/496/Test-url-alias`

I don't get any errors when I save, but the url doesn't seem to take effect. When I edit the node again and go look at the url alias the `Generate automatic URL alias` checkbox is checked again. My value is still in the text field, but the field is disabled because the checkbox is checked meaning it should use an automatic alias.

Why won't my changes stick and use my custom url alias?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

stella’s picture

I have the same issue. When I look at the database for the node, I can see two entries for each language in the database:

+-----+---------+-------------------------------+----------+
| pid | source  | alias                         | language |
+-----+---------+-------------------------------+----------+
| 165 | node/43 | registered-naionrai/schemes   | en       |
| 244 | node/43 | content/schemes               | en       |
|  83 | node/43 | naionrai-claraithe/sceimeanna | ga       |
| 246 | node/43 | content/sceimeanna            | ga       |
+-----+---------+-------------------------------+----------+

It looks like drupal_get_path_alias() in pathauto_field_attach_form() just returns one alias, and since that one matches the pattern based one, it sets the checkbox to enabled. I tried it with all 3 "Update action" options, but nothing changed.

I'm using entity translation in case that makes a difference.

Riptidez’s picture

Having the same problem. Can set my own alias when I create a node, however I can't override existing nodes that had "Generate automatic URL alias" previously checked.

Dave Reid’s picture

Status: Active » Postponed (maintainer needs more info)

None of the simpletests can confirm this behavior. I'd need specific steps to reproduce this issue on a clean install of core + Token + Pathauto only enabled.

SGhosh’s picture

I had a clean install of core, token, pathauto. I created a node, unchecked generate automatic url, saved my custom url, and there does not seem to be any problem.

@kennywyland - please give the exact steps on reproducing this problem.

henrikakselsen’s picture

I have the same issue. My page has some multilingual content and only one language seem to be affected by it.

root66’s picture

I've the same issue, but with "und" (undefined) language nodes only. When the manual path (pathauto unchecked) is saved, the alias is written to the url_alias table and the 'language' field is empty. When loading the node again, the pathauto checkbox is checked again, because pathauto can't find the 'url_alias' table row, because it selects something like "AND language = 'und'" and there's a row with a empty language only.

Martijn Houtman’s picture

I have the same problem. Steps to reproduce:

1. Enable i18n and i18n_content, and set basic page to translatable, with translation
2. Enable pathauto
3. Enable a second language, e.g. Dutch
4. Create a basic page, in English, with 'create automatic url alias' checked
5. Translate the page to a different language, e.g. Dutch (also url alias checked)
6. Go back to original page, uncheck url alias and edit it
7. Go to translated page, uncheck url alias and edit it
8. Go back to original node, edit it, and the 'url alias' checkbox is checked again (it should be unchecked)

Tested on a D7.19 install with i18n 1.8 and pathauto 1.2. Can anyone try to confirm if they also have this behavior?

onewomanbiz’s picture

I have the the reverse issue. I cannot get the automatic alias checkboxes to stay checked on one site.
I have a multisite single Drupal Core, 2 databases, one English site, one French site.

English site auto url stays checked and able to set urls. French site the auto url will not stay checked and cannot generate auto urls. Any ideas?

zemax’s picture

I have the same issue but I think I know where it comes from.
When updating a node with translations and WITH SYNCHONISED FIELDS, the translations are also updated automaticaly by the i18n module, and the pathauto hook re-generate the paths directly from the pattern for these translations nodes.

If I disable the synchronisation between fields, the paths remain correct.

zemax’s picture

Solved my problem by adding the same tests that are done on the form :
In pathauto.module, line 347 :

function pathauto_entity_presave($entity, $type) {
	if (!isset($entity->path['pathauto'])) {
		$entity_type = $type;
		$langcode = $entity->language;
		list($id, , $bundle) = entity_extract_ids($entity_type, $entity);
		
		if (!empty($id)) {
			module_load_include('inc', 'pathauto');
			$uri = entity_uri($entity_type, $entity);
			$path = drupal_get_path_alias($uri['path'], $langcode);
			$pathauto_alias = pathauto_create_alias($entity_type, 'return', $uri['path'], array($entity_type => $entity), $bundle, $langcode);
			$entity->path['pathauto'] = ($path != $uri['path'] && $path == $pathauto_alias);
		}
		else {
			$entity->path['pathauto'] = TRUE;
		}
	}
  
  // About to be saved (before insert/update)
  ...
stella’s picture

@zemax can you add a patch for your changes please?

zemax’s picture

FileSize
3.11 KB

Here is the patch.
Don't know if it will fix your bug (which seems to be related with multiple aliases ?)

alanburke’s picture

When the pathauto field is attached to the the translation form - it ignores whether a path has already been set for the source translation.
Hence when the source node is saved, pathauto is set to true, and a new alias is saved.
The problem is that the entity already has pathauto set to true when the translation form tries to attach itself.
The expected behaviour is that if a manual path is set for the source translation, the pathauto should be false
[as it is when editing the source translation] and the path from the source entity should be the default value.

Still trying to workout where that 'pathauto=true' is set when loading the translation form.

krishanchandra’s picture

Go TO URL Alias Configuration -> Go To Setting Tab --> Update action
Select This option - Do nothing. Leave the old alias intact.

artfulrobot’s picture

Thanks, this fixed it for me.

davidlovere’s picture

I am running pathauto with internationalization, and was having this problem. Here's what fixed it for me, quite simple:

For each affected content type, enable Multilingual support.

Charles Belov’s picture

I was getting this too - in my case I was trying to change the alias, not get rid of it - but I'm adding this in case it is relevant to your issue.

When you edit the URL path setting, there is a link Configure URL alias patterns. I decided to follow that link, and found that the alias pattern for the particular content type is:

[node:menu-link:parents:join-path]/[node:menu-link]

So I left the URL Path Setting tab and went to the Menu Settings tab, and changed the link title and saved.

The alias changed to what I wanted it to be.

Hope this helps.

VVS’s picture

Solution for me:

Go to /admin/config/search/path, delete old path with warning.
Resave the node with custom path.

ricovandevin’s picture

Issue summary: View changes

I've overlooked this issue earlier and created another one on #2194305: Checkbox Generate automatic URL alias behaves strange. The problem might be that drupal_lookup_path() returns a language neutral alias instead of a language specific one when both exist for the same node. In #2194305: Checkbox Generate automatic URL alias behaves strange there is a link to an issue for the core Path module where a patch for that bug in core can be found.

Growiel’s picture

I had the same kind of problem.

Whenever I updated a node via node_save(), the alias config was reset to "create an automatic alias".

This is VERY easy to reproduce:

1: Install brand new Drupal.
2: Install Pathauto and Token.
3: Create two nodes, make sure the second one has a custom alias.
4: Create a custom "test" module with:

function test_node_update($node){
    if($node->nid == 1){
        node_save(node_load(2));
    }
}

5: Activate test module.
6: Save the first node which will node_save() the second one.
7: Go to edit page of the second one and see that it now has "Generate automatic alias".

The patch in #12 fixed it for me.

It need to be commited ASAP, I lost a long time finding out why the hell where my translations getting screwed up.

Growiel’s picture

Priority: Normal » Major
Status: Postponed (maintainer needs more info) » Reviewed & tested by the community
jenlampton’s picture

FileSize
1.08 KB

Patch also works for me. I needed a version to apply to the 7.x-1.2 version. Attached.

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 22: pathauto-1847444-22.patch, failed testing.

tobiberlin’s picture

I used patch #12 but now the following notice message show off during cron (in Drupal logs):

Notice: Undefined property: RulesReactionRule::$language in pathauto_entity_presave() (Zeile 363 von /sites/all/modules/pathauto/pathauto.module).

Notice: Undefined property: OgMembershipType::$language in pathauto_entity_presave() (Zeile 363 von /sites/all/modules/pathauto/pathauto.module).

This is the code there - line 363 is the last line of the snippet:

  // Prevent rebuilding custom paths from node_save
  // when syncing translations
  if (!isset($entity->path['pathauto'])) {
  	$langcode = $entity->language;

Seems that this patch makes trouble with entities like organic group membership or rules?!

Best,
Tobias

jenlampton’s picture

Title: "Generate automatic URL alias" stays checked after uncheck and save » "Generate automatic URL alias" stays checked after uncheck and save (and vice versa)

Yeah, I take it back too. The patch in #22 does not actually work for me. In fact, I think this whole issue is a dupe of https://drupal.org/node/936222

jenlampton’s picture

Status: Needs work » Closed (duplicate)

updating status. Please test the patch in the other issue!

ndobromirov’s picture

FileSize
3.2 KB

This is fixing the notices issue for me.
Based on the patch in #10.

glass.dimly’s picture

Version: 7.x-1.2 » 7.x-1.x-dev
Status: Closed (duplicate) » Active

I was experiencing the behavior that "generate automatic alias" remains checked after node save even after unchecking and adding a manual alias, and the new URL worked but forwarded to the old URL.

I patched from a comment, the supposed duplicate of this issue and I can confirm that the "generate automatic alias" no longer remains checked on save after applying the patch.

However, the old alias is still preferred over the new.

Disabling Global Redirect causes all aliases to function without forwarding.

Confirmed with both update actions, "Do nothing. Leave the old alias intact." and "Create a new alias. Leave the existing alias functioning."

I'm re-opening this and unmarking as duplicate because the "lack of forwarding to a the canonical URL" is a separate bug from "generate automatic alias remains checked after node save." Also, strangely enough, with "Create a new alias. Delete the old alias." The old alias doesn't get deleted and still functions. WTF.

Though, the lack of forwarding to a the canonical URL bug may belong in either Global Redirect or Path Redirect's issue cue.

I'm leaving this as "Major" and changing it to the dev branch, where I've replicated the issue. Sorry to mess with this big bug with so many subscribers, but that's how I sees it.

nrutkowski’s picture

I am having the same issue as glass.dimly. I need to change my url aliases for specific pages, however when I update them through workbench moderation the new alias does not replace the old one. I have tried all the settings for URL aliases ("Do nothing. Leave the old alias intact", "Create a new alias, Leave the existing alias functioning", "Create new alias, Delete the old alias") and none of them solve this issue.

The alias is updated in the $node object, however is displaying a 404 error if you manually enter the alias into the address bar.

I am using Pathauto Persistent to prevent the "Generate automatic URL alias" checkbox from staying checked when I save a draft, but the alias just does not seem to stick with the node.

jennypanighetti’s picture

I'm having the same issue as glass.dimly. When I edit a node and UN-check the "generate automatic alias" box, it stays checked and the previous alias is the one that's preferred. I have to go into the alias module and manually delete the alias in order to get it to stay! And, really, I don't want to delete the alias, I just don't want it to be the preferred path.

Stuck on a live server with thousands of nodes...

emanaton’s picture

Of note, i was just having this issue on a translatable site, and krishanchandra's steps above fixed it for me.

hschott’s picture

I think I'm having the opposite problem. To start, generate url alias is checked when creating new content. When saved the url shows the node id. If I choose edit the generate url alias is unchecked. I can't get it to generate an alias, but can type in my own url.

hschott’s picture

My issue was the url alias /patterns changed. Once I set the paths using new tokens, it worked. Still having problem. It creates the alias, but it's not using the tokens correctly. Getting urls like this: featured/create-featured

mccrodp’s picture

Status: Active » Needs review
FileSize
1.11 KB

The patch in #22 is working for me and I re-rolled against latest dev in attempt to pass all tests.

I added a check for $language property that was causing the test failure.

if (!isset($entity->path['pathauto']) && !empty($entity->language)) {
    $langcode = $entity->language;

Was this patch working for other people having this issue, from #28 onwards?

katannshaw’s picture

@mccrodp: Patch #34 fixed this issue for me.

wiipiiw’s picture

#34 is also working for me. Thx!

podarok’s picture

Status: Needs review » Reviewed & tested by the community

#34 works for me too
Let's get committed

aminebourkadi’s picture

Thank you very much, how to install the path #34 ?

mccrodp’s picture

@aminebourkadi Are you asking, how to apply a patch?

All looking good so far!

aminebourkadi’s picture

The patch #34 didn't fix my issue , no url rewriting is workin and i still get the native drupal url like "node/23" .
As i see i have 2 problems here:

  1. The url "admin/config/search/path/patterns" don't return the old path configuration forms :Only local images are allowed.
  2. The second notice is that when i try to add or edit an existant node ( with no url alias ) i get the message:
    The Titre de page utilise les jetons (tokens) invalides suivants : [node:title], [site:name].
    The Description utilise les jetons (tokens) invalides suivants : [current-page:title], [node:summary], [node:field-tags].
    The Résumé utilise les jetons (tokens) invalides suivants : [current-page:title], [node:summary].
    The Mots-clés utilise les jetons (tokens) invalides suivants : [node:field-tags].
    The Image utilise les jetons (tokens) invalides suivants : [node:field_photo].
    The URL canonique utilise les jetons (tokens) invalides suivants : [current-page:url].
    The URL raccourcie utilise les jetons (tokens) invalides suivants : [current-page:url:brief].
    The Page URL utilise les jetons (tokens) invalides suivants : [current-page:title].
    The Titre utilise les jetons (tokens) invalides suivants : [node:title].
    The Description utilise les jetons (tokens) invalides suivants : [node:summary], [node:field-tags].
    The URL de l'image utilise les jetons (tokens) invalides suivants : [node:field_photo].

Can anyone help me please

mccrodp’s picture

This patch should not affect the Alias Pattern form display at admin/config/search/path/patterns. It contains code for pathauto's hook_entity_presave only.

  1. Did this patterns form display issue exist before you patched the module?
  2. Do these tokens work elsewhere on the site?

I think both of these issues may be related to each other but separate from the problem in this issue. You may need to look at your tokens, it may be an issue with Token module you are experiencing.

aminebourkadi’s picture

I found the solution here and it's pretty fine right now

Marko B’s picture

#34 seems to work fine and described the problem very well. thanx

ygerasimov’s picture

Status: Reviewed & tested by the community » Needs work

Unfortunately patch makes fieldable_panel_panes to be unusable. The problem is that path property got changed to be array. pathauto should actually check whether this entity should have pathauto settings or not.

ygerasimov’s picture

Status: Needs work » Needs review
FileSize
1.73 KB

Here is updated patch that adds a check if entity type supports pathauto. It looks pretty hacky to me, but I don't see nicer solution at the moment.

Dave Reid’s picture

This needs SimpleTests to confirm the problem and ensure this won't regress in the future.

banoodle’s picture

I'm having this same problem. I just upgraded to 7.x-1.x-dev and then applied pathauto-1847444-45.patch.

The patch applied cleanly/successfully, but it has not helped my problem (I did clear system cache).

I'm really baffled because I'm pretty sure this does work on some of the sites I manage. I'm going to check on that and see what's different.

lenoz’s picture

Much the same to report as banoodle here. Updated both pathauto and globalredirect to latest 7.x dev versions, tried applying patch #45 too, cleared caches but nothing has changed.

At the moment I am having to do the following to create a manual alias for a taxonomy term:

  1. edit the term to uncheck "generate automatic alias" and add the manual alias I want
  2. find the automatic alias (which we don't want) on the alias list, and delete it
  3. manually add the deleted alias path as a new redirect to the term

Regardless of the "what happens when an alias changes?" option, the manually chosen alias should always take precedence as the canonical one, but as glass.dimly reports in #28, even with "Create a new alias. Delete the old alias." the old alias does not get deleted, which at least would be a useful fallback!

lstirk’s picture

Hi we are also having this issue. I have tried all the patches or stable & latest dev. When I untick the auto alias box and enter a new one and save the node the alias is not updated and the box is ticked again

caesius’s picture

Edit: This comment is rather long and may be hard to follow; in my next comment I list specific steps on how to reproduce this issue on a clean install if you just want to skip to it

Posting this here because a client was having an issue very similar to that described in the OP, although I'm not sure if the subsequent comments and patches are addressing the same issue. Applying the patch does not change observed behavior.

Here's the deal: there are nodes on the client site of the "resource" content type which have more than one alias assigned to them -- a custom alias and an automatically generated alias. She wants both aliases to work, but the custom alias should be used by default. Right now the automatic alias is being used -- meaning that's what you'll see in the address bar if you don't explicitly use the custom alias. When the client tries to edit the node to use the correct alias (she had assumed the custom alias had been deleted) the "Generate automatic URL alias" checkbox is checked and the custom alias appears in the greyed-out textbox. Unchecking the box and re-saving without changing the alias does nothing.

Initial state of URL aliases with both the short custom alias and the long automatically generated alias:

mysql> select * from url_alias where source = 'node/13939';
+------+------------+----------------------------------------------------------------+----------+
| pid  | source     | alias                                                          | language |
+------+------------+----------------------------------------------------------------+----------+
| 4913 | node/13939 | taps2013                                                       | en       |
| 4915 | node/13939 | resources/taps-compliance-point-sale-packaging-and-outdoor-ads | en       |
+------+------------+----------------------------------------------------------------+----------+

The issue seems to be that the textbox is populated with the first database result for the URL alias, while the alias the client sees actually being used is the one that shows up later in the database. This is obviously buggy behavior. Moving on...

Uncheck "Generate automatic URL alias" and blank out alias textbox, then save the node. This deletes the custom alias and leaves the automatic alias:

mysql> select * from url_alias where source = 'node/13939';
+------+------------+----------------------------------------------------------------+----------+
| pid  | source     | alias                                                          | language |
+------+------------+----------------------------------------------------------------+----------+
| 4915 | node/13939 | resources/taps-compliance-point-sale-packaging-and-outdoor-ads | en       |
+------+------------+----------------------------------------------------------------+----------+

Edit node. "Generate automatic URL alias" checkbox is checked and the automatic alias shows up in the greyed-out checkbox. Uncheck checkbox and put in taps2013 alias, save node. This leaves only the custom URL alias:

mysql> select * from url_alias where source = 'node/13939';
+------+------------+----------+----------+
| pid  | source     | alias    | language |
+------+------------+----------+----------+
| 4915 | node/13939 | taps2013 | en       |
+------+------------+----------+----------+

Edit node. Check automatic generation checkbox and save node. This leaves us back where we started with the automatic alias showing up after the custom one, thus showing up by default:

mysql> select * from url_alias where source = 'node/13939';
+------+------------+----------------------------------------------------------------+----------+
| pid  | source     | alias                                                          | language |
+------+------------+----------------------------------------------------------------+----------+
| 4915 | node/13939 | taps2013                                                       | en       |
| 5538 | node/13939 | resources/taps-compliance-point-sale-packaging-and-outdoor-ads | en       |
+------+------------+----------------------------------------------------------------+----------+

The way we are able to actually get taps2013 to show up is by going to the URL aliases configuration, deleting the taps2013 alias, and then recreating it. However the underlying bug still remains but in the opposite form -- on editing the node the automatic alias checkbox is *un*checked and the automatic alias shows up in the editable textfield, while the custom alias is what is shown to the user.

So the problem is fourfold:
1: The alias that takes precedence needs to be consistent throughout the system. (this is the only actually buggy aspect of the issue; the rest are arguably feature requests)
2: Pathauto is clearly capable of handling multiple aliases per node, so there should be a way to allow aliases to persist through changes without being deleted.
3: There needs to be a way to manage multiple aliases on the node edit form so that the user can immediately know if multiple aliases are assigned to a node.
4: The weight of URL aliases needs to be manageable through the GUI without having to delete and recreate them.

Update: It appears we also experiencing issues with multilingual content. After recreating the custom URL alias as described after my last database snippet, this was the db state for the node aliases:

mysql> select * from url_alias where source = 'node/13939';
+------+------------+----------------------------------------------------------------+----------+
| pid  | source     | alias                                                          | language |
+------+------------+----------------------------------------------------------------+----------+
| 5540 | node/13939 | resources/taps-compliance-point-sale-packaging-and-outdoor-ads | en       |
| 5541 | node/13939 | taps2013                                                       | und      |
+------+------------+----------------------------------------------------------------+----------+

I had selected "All Languages" instead of specifying English, so the language for taps2013 was und. As stated, the resources/... alias was what showed up in the URL alias textbox and the automatic alias checkbox was unchecked, so I blanked out the textbox, saved the node, and had this:

mysql> select * from url_alias where source = 'node/13939';
+------+------------+----------+----------+
| pid  | source     | alias    | language |
+------+------------+----------+----------+
| 5541 | node/13939 | taps2013 | und      |
+------+------------+----------+----------+

The taps2013 alias is still what's being used, but when I edit the node the automatic alias checkbox is unchecked and the textbox is blank. This can obviously lead to confusion about where an alias is actually coming from.

So from here I edit the node, check the automatic alias checkbox, and save the node. This is where things get really weird:

mysql> select * from url_alias where source = 'node/13939';
+------+------------+----------------------------------------------------------------+----------+
| pid  | source     | alias                                                          | language |
+------+------------+----------------------------------------------------------------+----------+
| 5542 | node/13939 | resources/taps-compliance-point-sale-packaging-and-outdoor-ads | en       |
| 5541 | node/13939 | taps2013                                                       | und      |
+------+------------+----------------------------------------------------------------+----------+

Even though the pid of the automatic alias is greater than the custom alias, it gets selected first by the database! So even if it were assumed that the pid determines the weight of an alias, that's not what's actually happening if you don't explicitly order by pid.

caesius’s picture

Here are specific steps to reproduce this issue on a clean install, including a record of the DB state and commentary indicating what the actual problems are.

1. Install and enable pathauto module
2. Select update action "Create a new alias. Leave the existing alias functioning." at admin/config/search/path/settings
3. Create basic page with title Auto. Uncheck "Generate automatic URL alias" and put "custom" in the URL alias textbox. Save node. You are directed to "custom".

State of url_alias after saving node:

mysql> select * from url_alias where source='node/1';
+-----+--------+--------+----------+
| pid | source | alias  | language |
+-----+--------+--------+----------+
|   1 | node/1 | custom | und      |
+-----+--------+--------+----------+

4. Edit node. Check "Generate automatic URL alias" and save node. You are directed to "content/auto".

New url_alias state:

| pid | source | alias        | language |
+-----+--------+--------------+----------+
|   1 | node/1 | custom       | und      |
|   2 | node/1 | content/auto | und      |

(BUG) On editing the node, "Generate automatic URL alias" is checked and "custom" appears in the greyed-out textbox.

5. (BUG) Edit node. Uncheck "Generate automatic URL alias". Do not edit the URL alias textbox. Save node. You are directed to "content/auto". url_alias state persists and on editing the node again the automatic alias checkbox is checked again.
6. Edit node. Uncheck "Generate automatic URL alias". Blank URL alias textbox. Save node. You are directed to "content/auto".

| pid | source | alias        | language |
+-----+--------+--------------+----------+
|   2 | node/1 | content/auto | und      |

7. Enable multilingual support under publishing options at admin/structure/types/manage/page
8. Edit node. Switch Language from "Language neutral" to "English". Save node. You are directed to "content/auto".

| pid | source | alias        | language |
+-----+--------+--------------+----------+
|   2 | node/1 | content/auto | en       |

9. Add a URL alias at admin/config/search/path/add. Use Language "All languages", Existing system path "node/1", Path alias "custom".

| pid | source | alias        | language |
+-----+--------+--------------+----------+
|   2 | node/1 | content/auto | en       |
|   4 | node/1 | custom       | und      |

Here the order in which these two aliases show up in the database doesn't matter because language-specific aliases take precedence over "und" aliases. When you edit the node the automatic alias checkbox will be unchecked and "content/auto" will show up in the URL alias textbox because it's the English alias for an English node.

10. Edit node. Blank URL alias textbox. Save node.

| pid | source | alias  | language |
+-----+--------+--------+----------+
|   4 | node/1 | custom | und      |

11. Edit node. Check "Generate automatic URL alias." Save node. You are directed to "content/auto".

| pid | source | alias        | language |
+-----+--------+--------------+----------+
|   5 | node/1 | content/auto | en       |
|   4 | node/1 | custom       | und      |

Again the order does not matter, but as you can see the automatic alias with pid 5 is selected before the custom alias with pid of 4. So now let's do something where this would actually be a problem.

12. Edit the automatic URL alias at admin/config/search/path. Select Language "All languages". Save alias. You are directed to "content/auto".

| pid | source | alias        | language |
+-----+--------+--------------+----------+
|   4 | node/1 | custom       | und      |
|   5 | node/1 | content/auto | und      |

Well the select order somehow got fixed, so it's probably not actually an issue. (BUG) However on editing the node the "Generate automatic URL alias" checkbox is checked and the URL alias textbox is greyed-out and blank.

Dave Reid’s picture

Matt V.’s picture

Status: Needs review » Needs work

I'm marking this as "Needs work" since Dave Reid mentioned in comment #46 that it needs tests.

fabio84’s picture

Patch in comment #45 works for me

rcodina’s picture

I think this issue may be related to this one.

dxx’s picture

Patch works for me since 3 months.

Abhishek Verma’s picture

Thanks @krishanchandra...

Leeteq’s picture

IMO, this issue should be enough in itself for a 1.4 release.

The other issues in the 1.4 plan should not keep this one from hitting a stable release "asap". I suggest renaming #2548927: Plan for Pathauto 7.x-1.4 release to 1.5 (with the existing issues/"timeframe" minus this issue), and then (if needed) make a new 1.4 "plan" with only this issue, along with any other such things that are important/urgent enough for a quick, simple new release.

Dave Reid’s picture

This needs to be re-rolled after the 7.x-1.3 release. Also warrants checking if this even needs to be fixed now that the checkbox state is saved to and loaded from the database now.

mnshantz’s picture

On a site running Drupal 7.39, workbench-moderation 1.4 and pathauto 1.3 I needed the patch so the "Generate automatic URL alias" checkbox would stay checked after publishing the node. Without the patch if you went in and edited the draft after publishing the "Generate automatic URL alias" checkbox would be unchecked. Sorry, I was wrong, the patch doesn't correct the issue I'm having with the "Generate automatic URL alias" checkbox not staying checked. I still have the issue with 1.3. The patch worked for me with 1.2 if I turned off pathauto_persist. If I have pathauto_persist on then the patch doesn't work.

rp7’s picture

Experiencing the same as #60.

@mnshantz
Did you find a fix or (temporary) workaround?

jmary’s picture

Update of the patch for pathauto v1.3

rebecca904’s picture

Set administration page to jquery 1.5, this fixed my issue. See https://www.drupal.org/node/1728528.

mccrodp’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 62: pathauto-patch_for_pathautho1.3.patch, failed testing.

rp7’s picture

We are experiencing the same issue as in #60. We are using Workbench Moderation and the "Generate automatic URL alias" checkbox is not staying checked, which leads to non-aliased URL's.

In the Workbench Moderation module I see the following line in workbench_moderation_store():

$live_revision->path['pathauto'] = 0;

If I remove this line, at first sight everyone seems to work just fine.
Any idea why pathauto is explicitly being disabled? Or should I direct my question to the Workbench Moderation issue queue?

Dave Reid’s picture

@RaF7: Yes, if you are using Workbench Moderation, you'll want to subscribe to #2616854: Pathauto 1.3 - URL Alias state checkbox as it's not anything wrong with how Pathauto operates.