I've run into a strange bug wherein the text field for URL Alias is only enabled when Generate Automatic URL Alias is checked. This seems like the opposite behavior than what is expected.

The workaround to entering a custom alias is to check Generate Auto, enter the custom URL, then uncheck Generate Auto and click Save.

The code workaround is to replace this line:

$form['path']['alias']['#states']['!enabled']['input[name="path[pathauto]"]'] = array('checked' => TRUE);

with this line:

$form['path']['alias']['#states']['enabled']['input[name="path[pathauto]"]'] = array('checked' => TRUE);

I tried version 1.2 of Pathauto but this didn't seem to fix anything. Not sure what caused this but it happened out of nowhere, and I can't seem to find anyone with a similar problem.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Dave Reid’s picture

Status: Active » Postponed (maintainer needs more info)

I've seen a report of this before but I've never been able to reproduce it. The logic that is in Pathauto right now says that "This 'URL alias' field should not be enabled if the pathauto checkbox is checked." which is exactly the logic we want. I'm confused how this would even happen.

geddy’s picture

I concur, it is very strange. However, I cannot reproduce it either in a fresh installation of the module. Somewhere, something is screwing it up. However, I have the workaround figured out and I'll be sticking to this! :)

bartmcpherson’s picture

FileSize
33.95 KB

Unable to reproduce with 7.x-1.x in Drupal 7.15.

proindustries’s picture

I also ran into this issue, and Geddy's fix worked for me.

Currently running pathauto 7.x-1.2+0-dev (we tried with 7.x-1.2, same thing) and Drupal 7.14 (and a good mixture of other modules).

Happy to provide a full module list, or help troubleshoot this in other ways, let me know!

Adam Clarey’s picture

I am also seeing this, however i am unable to change the url by enabling the checkbox, changing the url then un-checking the box. I literally have to delete the 'disabled attribute on the input element using FireBug.

The code workaround also fixed it for me.

austinhappel’s picture

Version: 7.x-1.0 » 7.x-1.1

Also seeing this issue. Drupal 7.14, pathauto 7.x-1.1. Oddly, for me, the default Drupal User 1 (admin) user does not have this problem. Other roles we've defined in the system, however, do have this issue. For instance, I have an `administrator` role, with slightly reduced permissions from drupal User 1. Drupal user 1 (admin) has no problems. Users in the `administrator` role exhibit the problem listed in the issue (checking "generate automatic url" enables custom url textfield).

Naturally, the proposed fix solves the problem for the users in the `administrator` role, but causes User 1 to now exhibit the issue.

Other things I've found:

  • Adding User 1 to the 'administrator' role does not fix the issue.
  • Giving the `administrator` role any one of the permissions it does not have does not fix the issue.
  • I see no relevant javascript errors, either.

I have a _lot_ of modules installed, but for what it's worth, here are the permissions that User 1 has, that the `administrator` role does NOT have

[field_permissions]
  access private fields
  administer field permissions

[node]
  administer content types

If it would help, I'd be glad to pass on any additional info about my install, if it would help.

jamesmorrish’s picture

I also have the same problem. If I'm logged in as user 1 it behaves as expected. If I'm logged in as another user the behaviour is opposite to what you would expect - so if "Generate automatic URL alias" is checked you can edit the URL alias, and if it's not checked you can't.

I've attached a patch for this as a quick fix, but really this should be addressed in a better way!

I'm happy to provide any information to help the author fix the issue.

webdrips’s picture

I too am seeing this issue with 7.x-1.2 and dev. What's strange is the issue appears on only one site out of a six-site multisite, so something must have triggered the issue. The only thing I can think of was a user got deleted and so did her content, so we restored the database using Backup and Migrate.

Also wanted to add the problem doesn't happen with user 1 as others have reported, and a complete uninstall/re-install did NOT fix the issue either.

I can ask permission to share the database with this issue if that will help someone solve the issue as I was able to load the database locally and experience the same issue.

webdrips’s picture

Actually I just found the apparent cause of the issue: it has to do with the theme enabled for content editing. If we use the Seven theme for content editing, works like a charm without any changes; otherwise, this patch is needed for the theme I'm using.

This makes me think this is some sort of Javascript conflict.

I'm pretty sure I can share the theme I'm using (or maybe others can too).

Can others on this thread confirm this?

xadag’s picture

Issue summary: View changes

Hello, i had this problem to,

i've founded that if you use the jquery update module and you set the jquery version in administration page to default (so if you use a version > 1.5 in front page and so in administration page).

The behaviour of the checkbox is oposite.

But if you set administration page to jquery 1.5, it work well.

Hope it will help people :)

resmonde’s picture

Hi,

Thanks to xadag, I edited my jquery update settings (/admin/config/development/jquery_update) such that my site uses jquery v1.7.

However, for Admin purposes such as Content editing, I stipulate Drupal should use jQuery v1.5.

Panic over - I can once again have any node sport any sort of custom path I want.

jayjaydluffy’s picture

thanks xadag!

rcodina’s picture

Setting jQuery version to 1.5 in administration pages worked for me too. Thanks @xadag!!!

rcodina’s picture

I remark I was using drupal 7.24. After upgrading to version 7.39 problem disappeared too (also with jQuery > 1.5).