When loading admin/config/search/path/patterns, the forms either do not appear, or only partially appear. (Attached image from original report).

There appears to be several factors here, (not limited to): some of which seem related to (A) Entity Token, some of which seem related to (B) low PHP RAM settings, some of which seem related to (C) static cache and early bootstrap invocation of module_implements().

Proposed resolution

  • Raising memory_limit seems to solve B (and A?)
  • Patch at comment #43 seems to solve C (though it is possibly a workaround to flawed core API)

Remaining tasks

Better diagnosis of the multiple circumstances that cause the problem, which may not be local to pathauto, but rather other contrib/custom/core modules.

User interface changes


API changes


Original report by ekkosmos

I don't know why the pathauto patterns are not showing up...

patterns not showing up

#260 Selection_343.png28.71 KBjoaomachado
#254 Selection_341.png8 KBjoaomachado
#246 pathauto-pattern-1267966-256.patch1.3 KBcbeier
PASSED: [[SimpleTest]]: [MySQL] 337 pass(es). View
#238 1267966-238.patch542 bytesstefan.r
PASSED: [[SimpleTest]]: [MySQL] 337 pass(es). View
#230 replace_pathauto_module_implements-1267966-230.patch2.03 KBsundersingh
PASSED: [[SimpleTest]]: [MySQL] 316 pass(es). View
#211 replace_pathauto_module_implements-1267966.patch2.03 KBquicksketch
PASSED: [[SimpleTest]]: [MySQL] 337 pass(es). View
#209 pathauto-admin_patterns-1267966-209-D7.patch791 bytesLiam Morland
PASSED: [[SimpleTest]]: [MySQL] 337 pass(es). View
#140 pathauto_admin.patch791 bytesalarcombe
PASSED: [[SimpleTest]]: [MySQL] 316 pass(es). View


dazz’s picture

Priority: Normal » Major

I have the same problem the Patterns page is coming up blanc but there aren't any errors in the logs.

dazz’s picture

The problem seems to be the Entity tokens module. Once i disable it the Patterns page works again.

ekkosmos’s picture

For me the problem seems to come form Field Collection Table 7.x-1.0-alpha1 module. When I activate it is pathauto patterns are not showing up and when I deactivate all is ok.

alexdmccabe’s picture

This isn't just the patterns not showing up - they actually no longer function while they don't show up. Every alias created by pathauto is defaulting to the title of the node as the URL.

I'm not certain which module is causing the conflict for me, however.

ekkosmos’s picture

i confirm this also

Dave Reid’s picture

Category: bug » support
Priority: Major » Normal
Status: Active » Postponed (maintainer needs more info)

I cannot duplicate this with core and Pathauto + Token. You'll have to find out which contrib module is responsible by disabling them in groups to narrow them down.

alexdmccabe’s picture

I found it for me, it was Mobile Tools.

artofeclipse’s picture

subscribe ...

this issue happens to my site, but i don't have any of those modules in this thread, there must be an issue with token or path auto it's self.

Cray Flatline’s picture

I have same problem, but I have a lot of modules, so it's really hard to find out conflicting module.

jghyde’s picture

Priority: Normal » Critical

Part of the problem is that module_invoke_all('pathauto', 'settings') returns an empty array, in line 18 of

// using latest dev version, starting at line 10:
 * Form builder; Configure the URL alias patterns.
 * @ingroup forms
 * @see system_settings_form()
function pathauto_patterns_form($form, $form_state) {
  // Call the hook on all modules - an array of 'settings' objects is returned
  $all_settings = module_invoke_all('pathauto', 'settings');  //  <-- Returns an empty array
  foreach ($all_settings as $settings) {
    $module = $settings->module;
    $patterndescr = $settings->patterndescr;
    $patterndefault = $settings->patterndefault;
    $groupheader = $settings->groupheader;

    $form[$module] = array(
      '#type' => 'fieldset',
      '#title' => $groupheader,
      '#collapsible' => TRUE,
      '#collapsed' => FALSE,

I'd like to upgrade this bug to critical. The module is not functional until this bug is fixed.

Kristjan Logason’s picture

After update from 6 to 7.8 I am having the same problem.

Only modules installed are cck content migrate token and path auto

Dave Reid’s picture

Priority: Critical » Normal

Sorry, but the majority of module users cannot duplicate this still otherwise there would be a lot more comments than 11 of them. If you can duplicate this with a fresh install of core with only Token and Pathauto modules installed, then it needs to be critical.

Audrius Vaitonis’s picture

This can be the same problem. Function module_invoke_all('pathauto', 'settings') returns empty array. I have this problem just on live server. Dev and staging servers are fine, this complicated debugging, but if you need any info I can try to get it.

PHP version on live server is 5.3.6, Linux redhat 64 bit.

raveman’s picture

Encrease php memory limit in php.ini. If you have token/entity and references there are too many field connections to build "replace patterns" section of the page.
And, it is good idea to increase mysql packet size from 16M to 32M..

PS: now i have memory_limit = 196M, earlier was 128M and i had same issue (blank page is displayed). I had 6 node references, which was cross-referenced.
Now i've simplified node reference fields and re-using existing field declarations.

MHilliker’s picture

For me it was the module Webform table element. Turning it off did the trick.

Sano’s picture

Same problem, "allow_call_time_pass_reference On" in php.ini and flush cache helped me. PHP 5.3.3-7+squeeze3

Samlet9908’s picture

I want to add my experience also. Since I have relatively few extra modules installed, I tried commenter #7 suggestion of Mobile Tools. I turned it off an un-installed, and voila the pattern page came back and patterns now work.
I'd really like to use Mobile Tools, so a fix would be awesome. Thanks.

alexdmccabe’s picture

Not sure exactly what you're trying to do, but we settled on Mobile Theme as a replacement. It doesn't have all of the features of Mobile Tools, but then, we didn't need them. You may want to look into it.

Dave Reid’s picture

Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)

Going to mark this as cannot reproduce then.

Samlet9908’s picture

Ok I will try using Mobile Theme instead of Mobile Tools. Thanks for the tip.

Audrius Vaitonis’s picture

Thanks to #17,
allow_call_time_pass_reference On helped, I had to add this to php.ini file. PHP version 5.3.6 redhat linux.

Looks like feature "call_time_pass_reference" is deprecated.

Liam Morland’s picture

I was having this problem. It was caused by a custom module. The module file called drupal_add_js() right in the body of the file, that is, outside of any function. I moved that function call into a hook_init() implementation and the problem was gone.

iainp999’s picture

Same issue here guys.

Not been able to pin down exactly what's causing it, and not using any of the conflicting modules that were mentioned.

Will keep digging and post back if I reach a conclusion.

crispymix’s picture

Hi - I'd just like to add I've experienced this also. I had recently created a custom module which on being disabled would bring the page back. In an attempt to track the problem, I worked my way back through the calls until I got to module_implements which makes a call to the Drupal cache (line 660, invoked from module_invoke_all('pathauto', 'settings') hook call in (line 18).

In attempt to figure out why my code, which didn't implement any hook for pathauto, would cause this, I discovered that it was making a call to drupal_realpath in the .module to define a constant (not in a function call), and commenting this out would fix the issue. I have no idea why, but I'm hoping this information can help in some way - it sounds similar to #22

Note that I tried Mobile Tools to see if caused a similar problem but couldn't recreate it, and I have allow_call_time_pass_reference On as well as the dev versions of token and pathauto.

iSampo’s picture

This happened also for us, just documenting here for people stumbling to this.
Webform Table Element was the issue on our site. Updating to newest version fixed it.

The issue seems to be the same than in other comments. Pathauto didn't like a function call outside of any hooks or other module defined functions.

ThomasH’s picture

Same thing happened to me.

The problem only occurred when using PHP 5.3, where pass by reference has been deprecated. I was making a call to taxonomy_save_term in my custom module. It does not seem to matter whether the function containing the problem is actually called or not. If it is somewhere in the code, it will break pathauto's pattern page and other functionality.

ronny89’s picture

in my case it was the Collapse Text-module that evoked that behaviour.

in this case, the problem seems to relate to #1166504: call-time pass-by-reference has been deprecated in drupal_load(), so using the to the dev-version solved the problem while keeeping the module activated.

angel.h’s picture

I had the same problem - it was caused by a constant definition in my custom module!!?? I had the same constant defined in another module and this obviously crushes pathauto. Go figure!!!

pfaocle’s picture

Experiencing this - http:BL is our culprit...

Daniel Schaefer’s picture

Status: Closed (cannot reproduce) » Active

The issue is not fixed. I've not been able to track down the cause for this problem. I don't even know which module/etc. could have caused it. I followed a few suggestions but have not been able to solve the issue for me. You know, I love Drupal but the problem is, I'm losing way too much time trouble-shooting. This should not happen.. (just saying..)

Dave Reid’s picture

For the wide majority of module users this DOES NOT HAPPEN, so let's please leave this at cannot reproduce.

Daniel Schaefer’s picture

Status: Active » Closed (cannot reproduce)

Okay Dave! Maybe I was a little annoyed. Sorry about that.
I tracked the problem down- for me it was caused by @Tagadelic module.

Andy Tawse’s picture

As with Sano above, I fixed this problem by turning on allow_call_time_pass_reference then clearing the cache.

I'd noticed a "Deprecated function: Call-time pass-by-reference has been deprecated in drupal_load()" message for a while but couldn't see how it was related, and it wasn't doing any harm until URL aliases stopped working one day when users were saving nodes (patterns page didn't show any form field either).

I tried turning off recently added modules and I'd tried debugging and got down into module_hook_info() where I thought the problem was but I couldn't work it out. I couldn't recreate on my local server, only on the live site.

Oh well, it's fine now.

capellic’s picture

Panelizer also causes this problem.

-- update --

I had run into this problem, recalled it worked before enabling Panelizer. So I turned it off, the page reappeared. Then I turned Panelizer back on and reloaded the page. The page appeared. Huh?

adroid’s picture

Reasons for that 'blank patterns page' are so random.

I've just discovered blank patterns page.
I decided to dig a bit and first step was to enable core module "Database logging" log Drupal messages. (I have it disabled on that site)
And simply enabling that module made Pathauto patterns page appear...I didin't do anything else.

So I tried to disable "Database logging" module to see if patterns dissapear...but no, patterns did not dissapear. That was confusing.

michaelfavia’s picture

FWIW i got stung by this as well. A simple drush cc all issued twice for the site cleared it right up. Not sure what caused it as nothign was in the apache errorlog etc but ill chalk it up to a heisenbug and roll on. You dont need to report what module disableing did it for you imo because it isnt a contrib module breaking it it is a caching issue of some type that is resolved by a rebuild.

The reason everyones "i just disabled this module or that mode" are working is because it is simply triggering a registry rebuild i assume.

awolfey’s picture

This was also a deprecated allow_call_time_pass_reference problem for me. Well, the problem was that a function call was passing by reference. I'm not sure why that would cause the page to fail.

jmcoder’s picture

Had same problem. Was writing own module and (bangs head), which made use of calltime pass reference, but had already corrected the module and eliminated the deprecated code (fixed this, I believe, before visiting the patterns page).

Flushing cache twice solved it.

capellic’s picture

My issue was resolved by @awolfey in #37.

brandy.brown’s picture

Version: 7.x-1.x-dev » 7.x-1.0-rc2
Status: Active » Closed (cannot reproduce)

I am running the latest dev version with the same problem. Is there a way to solve this problem in laymen's terms? ... I have no idea what #37 is talking about. Thanks.

I am hesitant to say it can be solved by registry rebuild since the rebuild page clearly states that if you can run update.php and can install and enable modules, you don't need to do a registry rebuild. I will try that and report, however.

I rebuilt the registry, cleared the cache and the problem persists.

brandy.brown’s picture

Version: 7.x-1.0-rc2 » 7.x-1.x-dev
Status: Closed (cannot reproduce) » Active
lmeurs’s picture

Version: 7.x-1.0-rc2 » 7.x-1.x-dev
Status: Closed (cannot reproduce) » Active

I had the same problem, one of my own modules imported a javascript through drupal_add_js() at load time and that caused it! So a completely empty module with only:


was breaking it up. After I removed this import and flushed the cache once, the problem seems solved. So I do not know if this is the problem or that this line just triggers something else, but I can continue Drupaling again...! :-)

Mixologic’s picture

Okay, I can add some more intelligence here.

I had this same thing happen. Here's what happened.

I had a feature that I built and installed into sites/all/modules. I remembered that I wanted it in sites/all/custom/features/modules, so I disabled my module, moved it, and re-enabled it.

Well, this didnt update the system table to reflect the modules new location. So an include_once that was happening *early* in the bootstrap process was failing, launching into a hook_watchdog, which was somehow causing the module_implements cache to be built without all the rest of the pathauto hooks built into it (via module_implements_alter). No amount of clearing cache would work. I had to *disable my module*, clear the cache, then re-enable it.

Apparently if you have a module that's somehow interfering with the bootstrap, it *also* prevents a proper cache clear from happening. Pathauto's method for inserting its hooks in the module implements chain is just weird enough that this all colludes together to make for a pita.

So, basically anybody getting this error is most likely running into an issue that is preventing the cache from being properly re-set. Try disabling anything that might be a culprit and then clearing cache.

attiks’s picture

We ran into this today again, most of the time it's caused because inside the module there's an include not encapsulated inside a function.

mgifford’s picture

I think this might be an issue with the ShareThis or jQuery UI module for me. Haven't verified this yet, but will shortly.

@attiks, suggestions for finding includes not in functions? I'm assuming that this would be something Coder would find, but perhaps not.

Also, there are a lot of allow_call_time_pass_reference still in contrib modules '&$', not easy to know which is causing grief.

cmak’s picture

I also had a same issue, I figured out disabling my custom modules and found that hook_form_FORM_ID_alter was causing the problem. It was missing the third argument $form_id. So check all your form alters if any.
Flush cache and the patterns form was visible again!!!

Kaz de Groot’s picture

I'm in no way sure if this fixes the problem in general and it's pretty hacky, but by adding

module_implements('pathauto', false, true);

to just before

$all_settings = module_invoke_all('pathauto', 'settings');

it seems to pick up all the modules, and show the relevant options.

While this clears the (module_implements) cache, I didn't notice any slowdown as a result of this change.

attiks’s picture

@mgifford feature request created, i think coder can detect this #1507566: Detect php outside of functions
Related #1498782: Check for pass-by-reference in code

mgifford’s picture

Thanks @attiks!

markboniface’s picture

#47 worked for me.
Thanks Kaz

Perignon’s picture

#47 Worked for me too. I had a custom module of mine doing a drupal_add_js() and every time I turned it on Pathauto admin pages went blank.

mgifford’s picture

Why is this just happening to pathauto? Lots of different ways to break this page it seems.

rfc2460’s picture

#47 worked for me too. Thanks a lot !

jmdeleon’s picture

#47 worked for me also.

brandy.brown’s picture

YAY! #47 works. You rock!

mgifford’s picture

Ok, so how do we get this fixed in the next stable release? Obviously #47 isn't a permanent solution.

eric.chenchao’s picture

#47 worked for me too. Thanks a lot !

Perignon’s picture

Ya this still remains an issue, when I upgraded Pathauto it broke the fix. Then I remembered I had to hack pathauto to make this patterns screen appear again. I have a truck load of modules in my site and thus far pathauto is the only one that exibits this behavior and it's directly tied to drupal_add_js() call. I've created a simple module that loads just a "hello world" js and it still causes pathauto patterns page to go blank.

cjtriplett’s picture

I've experienced the same issue on a complex site.

#47 worked for me also.

marcoka’s picture

i had that problem with the latest dev of variable and i18n. downgraded back to the latest stable, works.

mgifford’s picture

Priority: Normal » Critical

I'm going to bump up the priority here.

This is an issue that enough people have now independently verified. It blocks a huge piece of the interface. It's got to be fixed in an upcoming release.

Dave Reid’s picture

Priority: Critical » Normal

But no one has actually verified or identified a problem in Pathauto aside from other modules that conflict and cause errors, so no.

Perignon’s picture

You have an interoperability problem here. Interoperability should be high on any developers priority list in such a hugely modular software framework that Drupal is - without that priority we have a serious problem in the community IMHO.

Dave Reid’s picture

So far the problems debugged so far have been other modules doing things wrong, so that's not really interoperability.

mxh’s picture

God damnit this was scary. Suddenly everythin disappeared. Without hacking, it also works to enable allow_call_time_pass_reference in php configuration and clear cache twice.

jhedstrom’s picture

I found this issue on a site and also traced it back to a different module calling


from the global scope, rather than from within a function. This caused module_hook_info() to run before all .module files had been loaded, including pathauto.module, which in turn resulted in pathauto_hook_info() not existing when the static cache of hooks was being built. Moving the drupal_add_js() call into a proper function (or into the .info file) fixes the problem.

attiks’s picture

@jhedstrom (and all others) we solved all our problems by moving code into proper functions, there's no need for a patch against pathauto AFAIK to solve this, other module maintainers should fix their modules.

decibel.places’s picture

#47 works for me

I am not using any of the reported modules; I uninstalled all modules added prior to the bug; no idea what happened, but #47 fixed it

It worked but only for a minute.

I increased PHP memory from 128M to 192M and enabled allow_call_time_pass_reference = On

the form is back!

jdanthinne’s picture

#47 working for me too.

attiks’s picture

@jdanthinne (and all others) can you check your modules and theme code for the presence of php code outside of any function?

xcafebabe’s picture

#47 working for me too. Thanks!

jdanthinne’s picture

@attiks : Is there an easy way to do that (± 60 modules enables, so a lot of files to check…)?

attiks’s picture

Not that I know, #1507566: Detect php outside of functions is created for coder, but not (yet) implemented. I assume that if you're good with grep you can right something ;p

If you have to do it manually, start with the smaller (# of installs according to drupal) first.

jdanthinne’s picture

I've found that Variable Realm was the cause (disabled it and page came back).
Seems related to #1574520: Dev version breaks Pathauto patterns admin page.

batigol’s picture

After upgrading 1.0 to 1.1 all my patterns diapered.

mikl’s picture

#64: Apparently, there's something very brittle in the way pathauto_module_implements_alter work. Your code might be correct, but perhaps there is a more robust way to accomplish the same thing, that is not so sensitive to (apparently very common) mistakes by other module authors.

I have a site where it clashes with the "Variable Realm" module, so currenly, I have to disable the site's multilingual features to edit my Pathauto rules…

Wolfgang Reszel’s picture

#47 works for the interface, but bulk updating the Paths is not fixed by that.

miguered’s picture

#47 worked for me!

josedanielestrada’s picture

#47 works perfectly!

Summit’s picture

Hi, #47 didn't work for me. All nodes after a while have node/NID instead of pathauto. Tried disabling panalizer, but no success.
Greetings, Martin

decibel.places’s picture


I don't know if you saw my post about #47 failing to solve this

It worked but only for a minute.

I increased PHP memory from 128M to 192M and enabled allow_call_time_pass_reference = On

the form is back!

bettisfr’s picture

#47 worked for me.

Before the modification, I couldn't see the collapsible tab "Content paths"... but now all is right.

lstoetzel’s picture

#74 temporarily fixed my problem (disable Variable Realm)

Summit’s picture

Hi Guys, for me working again. It was a language issue.. sorry to bother you guys.
greetings, Martijn

Wolfgang Reszel’s picture

How have you solved the language issue? Have you any details?

duvalbruno’s picture

#47 worked for me.
Thanks Kaz

Issue (seems to be) coming from LoginToBoggan.

I agree with #76, you can't rely on other module's developer to have clean code. You should ensure yours is bullet proof to others messing up...hard to do.

Thanks for the good work.

Jose Reyero’s picture

Category: support » bug

I'm doing some research about this, specially since #1574520: Dev version breaks Pathauto patterns admin page
and it seems to me that all these issues with different modules (included variable_realm) are happening because sometimes modules call hooks from hook_boot().

Refresh the cache from the pathauto patterns admin page and you'll see...

Drupal core logic about this is, to say it softly, weak, and for these cases module_implements('module_implements_alter') is invoked from bootstrap, when pathauto module is not yet loaded, thus pathauto_module_implements_alter() is not added to the list of hooks so it never runs later on.

The easy and more reasonable fix would be IMHO, if you don't want this to keep happening with random modules, to remove pathauto_module_implements_alter() and replace it with a plain include of before you ever invoke the 'pathauto' hook.

For this you may want some 'wrapper' function to be used instead of module_invoke_all('pathauto'), like:

function pathauto_invoke_all($op) {
  module_load_include('', 'pathauto');
  return module_invoke_all('pathauto', $op);

Really, relying on hook_module_implements_alter() is bad business, specially since your module doesn't implement any of the bootstrap hooks.

Changing to 'bug report', though I think this is a Drupal core bug more than pathauto, but still...

Jose Reyero’s picture

Jose Reyero’s picture

Also fyi, we'll try to fix it on variable module, see #1664154: Fix variable hooks invoked during bootstrap (Variable realm breaks pathauto)

Though I still think it would be safer to rewrite that part in pathauto too, as this thread proves the issue happens / has happened with other modules too and it's really hard to trace.

Dave Reid’s picture

It is not my desire to include the Pathauto code for core on every single page request, and adding a wrapper at this point for something that should be supported by core doesn't really work, especially for code that wants to call Pathauto APIs. I'm in favor of fixing this in core because that's what the root issue seems to be.

ericinwisconsin’s picture

Number 47 worked for me.

trong.nguyen.tcec’s picture

Hi, Mikl.
You are correct. Variable real, Variable Store make the Pathauto disappear. Just enable Variable to fix this error.
Drupal 7.14, Variable 7.x-2.0, Pathauto 7.x-1.1.
I found the same thing.
Thank for your sharing.
Trong Nguyen.

Jose Reyero’s picture

Latest (dev) version of variable 2.x should fix this issue.

phm’s picture

I had the same problem. After adding the hack at #47 my patterns returned and showed me an error message indicating I had an invalid token in the first pattern. After removing the offending token everything returned to normal and I could remove the hack again.

pyshgavak’s picture

#74 worked for me. Thanks jdanthinne

dcoulombe’s picture

#47 worked. Hacky but perfect 'till the next update.


joaomachado’s picture

Disabling Variable Realm module brought the patterns page back for me...

joelrotelli’s picture

Yeah, thanks for #47 !

stijntilleman’s picture

#97: same for me

bmunslow’s picture

Variable 7.x-2.1 (stable) solves this issue, no need to disable variable realm, specially if you need it.

fiveandfriends’s picture

We have found a "work a round". In the the function pathauto_pathauto() is empty. I have overridden this function by this:

function pathauto_pathauto($arg) {
  // delegates the arg´s to node_pathauto()
  return node_pathauto($arg);

and still it works fine.... hope it´s help.

Wolfgang Reszel’s picture

For what is the workaround needed? The new version of Variable should fix this issue.

fiveandfriends’s picture

No the newest Version doesn´t fix this problem for us.

batigol’s picture

After cron run and clear cache newest variable version (+ latest i18n) seems to fix this issue for me. Thx guys.’s picture

I completely uninstalled all three modules: token - pathauto - metatags (associated with token) and off path.
I clear all cache. I reinstalled these modules starting with token and pathauto.
And the problem was solved.

Countach’s picture

Well, it did return the pattern page but, for me, the patterns are not applied while editing/creating pages.


After clearing caches and submiting aliases pattern page it seems to work.

familymangreg’s picture

Agree with #100, upgrading from variable 7.x.2.0 to 7.x.2.1 solved the problem for me.

mike503’s picture

upgrading to variable 2.1 fixed it here. and we have a ton of modules.

Countach’s picture

This is really weird, today again it stopped apllying patterns to newly created pages. It works again after submitting pattern page in aslias settings. And I have Variable 2.1.


Did some tests - clearing caches breaks patterns. Need to submit pattern page to get it work.

adiatis’s picture

Same as #108: upgrading to variable 2.1 fixed it

maxplus’s picture


I have tried:
- upgrading variable to latest 2.1
- upgrading i18n to latest 1.7
- uninstalling pathauto and reinstalling it
- clearing cache
- hack of #47

=> nothing worked

The only thing that worked for me was upgrading my php memory limit from 128M to 192M like in #81 without "allow_call_time_pass_reference = On" because that gave a server error.

decibel.places’s picture

slightly off-topic but

My client's Acquia hosting had php memory_limit set to 128M and the Workflow edit page displayed blank (wsod)

It took opening a ticket with Acquia to increase the memory to 256M, which fixed the issue

AFAIK nobody runs a reasonably complex Drupal site at less than 192M php memory

If you're using Acquia hosting, this default could be a problem

you can check your php info at /admin/reports/status/php

Amber Himes Matz’s picture

I can confirm that #66 -- a custom module calling drupal_add_js in the global scope rather than within a function or hook -- was the actual source of the problem.

Pathauto seems to be the victim here, not the source of the problem.

Danny Englander’s picture

Updating to Variable 7.x-2.1 (2 July, 2012) from 1.x dev also fixed this for me. Thanks for the suggestions above.

pmkanse’s picture

HI All,
If you have any files included outside the function, you will face the issue.
You can define the hook_init function include all required files.
enjoy Drupal!!!

jiakomo’s picture

Variable 2.1 fixed this for me, too. Thanks guys.

Spleshka’s picture

Update to variable 2.1 fixed this problem, thanks.

ptrl’s picture

Same problem, Same solution as #16. Check your logs if you get any php notices or errors and try to fix them.

ram4nd’s picture

#47 worked for me. I have set up multi-site, only one site had the problem.

irp-socotec-nucleaire’s picture

Version: 7.x-1.x-dev » 7.x-1.2

For us, Mobile Switch is the source of this bug.
As #113 wrote, I think that Pathauto seems to be the victim, not the the problem.

mattew’s picture

Same problem as #120. I create a bug report for this issue with Mobile Switch :

sunchaser’s picture

solution #47 ftw !

whitingx’s picture

476 bytes
PASSED: [[SimpleTest]]: [MySQL] 316 pass(es). View
quiptime’s picture

I have the same problem.

D 7.17
Token 7.x-1.4
Pathauto 7.x-1.2

I found a magic solution

  1. Overlay module active - No Patterns visible
  2. Deactivated the Overlay module - Patterns are visible, any patterns configured
  3. Overlay module again activated - Patterns are visible
ambientdrup’s picture

Raising the PHP memory limit solved this issue for me. Just an FYI.


tlarrieu’s picture

Same manifestation and fix as #28. Had two custom modules defining the same constant. This was generating watchdog errors such as "Notice: Constant ELOG_READER already defined in include_once()...". Once I fixed that issue, the pathauto patterns page form elements started showing again.

dabito’s picture

Having the same issue here, cant really go around disabling modules. Will try the php.ini solution and report back.

joedevdrupal’s picture

My memory limit is set to 512MB and am still getting the memory error. There is a conflict with Entity Tokens module and or Rules...

What is the fix for this. Pathauto is working with Entity Tokens module turned off, but then Rules will not work...

This is very frusterating.

hwi2’s picture

Great hack. Yes, it's hacky, but if things do not work as expected, sometimes hacking it works.

josejayesh’s picture

#124 worked for me .

josejayesh’s picture

#124 worked for me .

capellic’s picture

Entity Tokens (part of Entity API) was my problem, 7.x-1.0-rc3+11-dev. (Not to say other versions don't have problems.) Once I shut that module down (as well as it's dependencies, Rules in my case), admin/config/search/path/patterns came back to life. (I never had to turn off Entity API.)

But here's what's odd. I have another site running the same version of Entity Tokens and there is no problem. What's difference is that I have Auto Node Titles active on a content type, so I added one to a content type to the site is working-- no luck in reproducing the error.

Above, someone mentioned that they had a bad token. Not sure where to even start looking for that.

I'll continue to hunt.

These cases seem to be related to what I'm dealing with:
#1825706: 500 Internal Server Error
#1800562: Entity tokens and Pathauto problem

This is what I'm seeing in my error log:

[16-Dec-2012 20:56:26 UTC] PHP Fatal error:  Uncaught exception 'PDOException' with message 'SQLSTATE[HY000]: General error: 2006 MySQL server has gone away' in /Users/stephenm/Sites/
Stack trace:
#0 /Users/stephenm/Sites/ PDOStatement->execute(Array)
#1 /Users/stephenm/Sites/ DatabaseStatementBase->execute(Array, Array)
#2 /Users/stephenm/Sites/ DatabaseConnection->query('SELECT expire, ...', Array, Array)
#3 /Users/stephenm/Sites/ db_query('SELECT expire, ...', Array)
#4 /Users/stephenm/Sites/ lock_may_be_available('theme_registry:...')
#5 /Users/stephenm/Sites/ lock_acquire('theme_registry:...')
#6 /Users/stephenm/Sites/ ThemeRegistry->set(Array)
#7 [internal function]: DrupalCacheArray in /Users/stephenm/Sites/ on line 2139


Turns out my issue was that MAMP only has 1MB as it's default setting for packet size. In MAMP 2.x, you can increase the packet size (I did 32 MB) in the my.conf template file and then restart the server.

TechNic’s picture

As with #120, disabling Mobile Switch solved the problem.

joedevdrupal’s picture

I get the following error along with memory errors when trying to access the patterns tab of pathauto settings.

Notice: Constant CONTENT_DB_STORAGE_PER_CONTENT_TYPE already defined in include_once() (line 9 of /home/***/public_html/***/sites/all/modules/cck/content.module).

bharathkumarkn’s picture

"""#47""" worked for me.. Even I had same problem..

c4rl’s picture

#47 worked for me. I want to clarify to everyone that "the problem" is actually multiple problems having the same effect, though seemingly mutually independent.

There appears to be several factors here, (not limited to) some of which are related to (A) Entity Token, some of which are related to (B) low PHP RAM settings, some of which are related to (C) static cache and early bootstrap invocation of module_implements().

  • Raising memory_limit seems to solve B (and A?)
  • Patch #47 seems to solve C (though it is possibly a workaround to flawed core API)

I've updated the issue summary with these remarks.

hanamizuki’s picture

Got the same problem and #47 works. Thank you!
But is there any better practice to solve this problem?

farse’s picture

I had the same problem and I updated variable to 2.1 and it works now (also updated entity api to 1.0).

trong.nguyen.tcec’s picture

This path works correctly.
Thanks to whitingx

alarcombe’s picture

791 bytes
PASSED: [[SimpleTest]]: [MySQL] 316 pass(es). View

Further to whitingx's patch, the following patch adds the same fix to the bulk update admin page (admin/config/search/path/update_bulk) on 7.1

The problem appears to be that node_pathauto, defined in pathauto.module is not called by module_invoke_all('pathauto', 'settings') because it doesn't exist in the module_implements cache. Clearing that cache by calling module_implements() with the reset parameter set to true immediately before the calls to module_invoke_all 'fixes' this. The underlying cause of this has yet to be determined though.

Kaz de Groot’s picture

From what I remember researching this issue a while back, running a 'clear cache' would (in most cases) temporarily fix the problem. This, together with #47 working for a lot of people, suggests that the specific point in the runtime (I expect reasonably early in the bootstrap) where the module_implements cache would normally be filled constricts its correct functioning in some way. As a number of other people have fixed the problem by removing or fixing badly coded modules, it seems that the functions for registering hooks are somewhat fragile.

If I have some time this week, I might trace this problem down it's rabbit hole (e.g. module_implements). I expect that it's some edge case in core.

lpeabody’s picture

I solved the problem by boosting the max packet size in MySQL from 1MB to 16MB.

frhou’s picture

Thanks a lot #42 it was a drupal_add_js at the beginning of one of my custom modules which was causing the pattern form to disappear !

carsonblack’s picture

I have the Entity tokens module enabled because Commerce module is dependent upon it. However, I checked in a fresh install and Entity tokens alone is not the cause of this, it is the other issues discussed here with the module_implements and module_invoke_all() implementation.

Patch in #123 fixed the issue for me.

kirksievers’s picture

This did not work for me :(

mastermindg’s picture

I got an "Internal Server Error" on /drupal/admin/config/search/path/patterns.

I can also confirm that disabling Entity Tokens resolved the issue for me.’s picture

I'm also seeing this problem, and managed to duplicate it both on two servers Windows (IIS) and LAMP. Results are very inconsistent, it seems that enabling/disabling modules and/or clearing cache might make the problem go away or appear. We have versions of everything right up to date (drush up) at the time of writing.

I suspect that some, perhaps many of the reports above saying "disabling module x fixed it" or "upgrading to version x of module y fixed it" - may be incorrect, and the problem being "fixed" just a coincidence.

Summary of what I went through:

Server A: (IIS)
* Confirmed problem evident
* Disable 5 modules from a custom suite called BM -> problem gone
* Re-enable BM module 1 -> problem still gone
* Re-enable BM module 2 -> problem back
* Disable BM module 2 -> problem gone

At this point we assumed that BM module 2 was the "culprit" - my own code - it does not use drupal_add_js anywhere at all. I copied everything on to my own development server (LAMP) for further investigation. At one point the problem was present, and disabling all BM modules made it go away. Then, re-enabling them one by one, the problem did *not* come back. Clearing cache seemed to make no difference.

So, inconclusive.’s picture

Metatags config page at admin/config/search/metatags *also* fails (settings are blank) apparently under the same circumstances. Right now I have two copies of the same site on different servers. The one which exhibit this PathAuto issue also has the Metatags issue, the other one has them both working. Disabling/enabling modules as I described up made the problem go away, and it seems (not confirmed) that the metatags and pathauto issue appear and disappear together. This would apparently indicate that PathAuto itself is not at fault.

Summit’s picture

Hi, #47 and therefore patch #140 worked great for me!
greetings, Martijn

skoehn180’s picture

I was experiencing this issue and none of the suggested solutions fixed it for me except turning off Entity Token. Since I need that module, it wasn't a good solution.

In the Entity API issue queue, I found the answer that worked. I installed the Token Tweaks module, set the limit to 2, and my problem was resolved.

KuroNeko’s picture

#14 solved it for me.

ram4nd’s picture

Priority: Normal » Major
Status: Active » Reviewed & tested by the community

Patch #140 worked for me!

harings_rob’s picture

#140 confirmed for me to. Should be added to the next release.

Spry_Julia’s picture

I can confirm the patch worked for me as well. I had lots of memory allocated to PHP, and I could not find a module conflict, so the patch was the only thing that fixed this issue for me.

kgalal’s picture

I tried all the solutions posted above, but none worked for me. The root cause for me was the SimpleHTMLDom module causing a PHP fatal error, by exhausting allowed memory size (256M). The error was displayed in the apache error log for the virtual host. After disabling Theme Developer and SimpleHTMLDom, the patterns page reappeared.

cgdrupalkwk’s picture

#140 worked for me! Thanks for the fix!

vgalindus’s picture

Hi all after some digging it seems to be definetly related to max_allowed_packet size in mysql.

Johan Groenewald’s picture

This was my solution for the same exact problem (Pattern page of Pathauto blank)

I have mobile switch modules installed. Under the mobile switch basic settings on the configuration page, the mobile theme was set to use the same theme as the desktop theme. So I've set the theme settings of mobile switch to 'Do not use' (Cause I'm using the same theme in desktop and in mobile view). This solved my problem. :-)

k_ankur’s picture

Same as kgalal (#155). The root cause was SimpleHTMLDom API module. Disabling Theme Developer and SimpleHTMLDom API did the trick for me.

hansrossel’s picture

Patch #140 works for me

nfavrod’s picture

Had same problems: solved without patches but with :

Thanks for and that helped me to find a way throught :-)

jason.fisher’s picture

#140 worked here with the latest -dev.

ace11’s picture

#161 worked for me. Downloaded Token Tweaks and set limit to 2.

JadH’s picture

#140 worked for me

Road Runner’s picture

Imagine m surprise when I just notices this same error of all pathauto screens blank. This on a production site too. When and how it happened I am not sure but recently. Then I found this thread. Patch #140 seems to have worked. I hate applying a patch I know nothing about especially to fix errors that no one seems to know much about and this after 2 years. The law of unintended consequences is lurking I am afraid. Thanks to all as well as to developers for staying on this.

Road Runner’s picture

Issue summary: View changes

Better summary

FiNeX’s picture

I confirm that patch #140 works fine. But I'm also experiencing some other issues like metatags which disappears until I've disabled entitycache and many fields doesn't appears on content display settings ( #2127149: Many fields are missing on DS UI ), maybe there is a common root?

FiNeX’s picture

Moreover url aliases are not created even if now the pattern settings are visible.

mxh’s picture

Moreover url aliases are not created even if now the pattern settings are visible.

I have a similar problem. I have set up a pattern where the name of a taxonomy term should be in the path, but sometimes it is included in the automated url generation, and sometimes not. I guess this is an other issue and we should open a new one if this should be further discussed.

zmove’s picture

#140 resolved the problem on the latest dev release of pathauto. It would be nice to see this commited.

elantion’s picture

#140 work like a charm

leymannx’s picture

Only thing that worked for me is as said in #150 & #163: installed Token Tweaks and then set the limit to 1 and finally had the patterns back, plus better performance. #123 && #140 patches had no effect for me.

a_L_p’s picture

The patch in #140 worked for me as well. FWIW, I didn't have entity token enabled and the problem still existed.

DamienMcKenna’s picture

Issue summary: View changes
Status: Reviewed & tested by the community » Needs work

Sorry, but the two added lines need to at least be updated to match the Drupal coding standards, specifically the boolean values should be spelled in uppercase.

charlus’s picture

#150 solved it for me. Installing token_tweaks without changing settings works well.

jberube’s picture

I experienced this problem because I had made a custom module that was (stupidly) making a call to url() at its top level, outside of functions. I was defining a path constant: define('MY_AJAX_URL', url(MY_AJAX_PATH)). So that was dumb. Don't do that.

WillowDigit’s picture

As soon as I turned on the Media 7.x-2.x-dev module my patterns disappeared, except for the file paths pattern. Patch #123 fixed this for me.

bender404’s picture

#140 worked for me with 7.x-1.2 version

MustangGB’s picture

#140 fixed both tabs over here.

Dig1’s picture

Yes I encountered the problem of PathAuto suddenly not showing patterns. After reading through these comments I increased PHP memory from 128M to 256M, cleared cache, ran Cron, ran update. That fixed the problem and the patterns returned. I then slowly reduced PHP memory down to 192M then 160M then back to 128M. Each time clearing cache etc. It is now working again at 128M PHP memory and I will monitor the seems that something is not being cleared in memory but thus far I have not applied any patches.

Thanks for everyone's input so far.

darrylmabini’s picture

I think this is caused by the modules that implements hook_boot() with drupal_alter() module_invoke_all() module_invoke() inside.

vipzhicheng’s picture

The patch #140 do not actually fix the bug.

Alex.Gaft’s picture

Nothing had helped me - I have the page with text, but replacement patterns don't open...

vipzhicheng’s picture

drupal_load('module', 'pathauto');
require_once DRUPAL_ROOT . '/includes/';
module_load_include('inc', 'pathauto', 'pathauto.pathauto');

As a workaround, I added these lines of code to settings.php. then clear cache
Seems fixed.

Dig into using many hours, but still can not find out the real answer.

seems when bug happens, module_implements_alter is empty, and then cause hook_pathauto can not be executed well.

mttjn’s picture

Patch at #140 worked for me. Version 7.x-1.2

Turek’s picture

#140 did the trick for me!

ProYoga.NL’s picture

#161 Token Tweaks 7.x-1.x-dev (2014-Jan-27) with tree limit set to 2 finally fixed the issue. Memory limit still at 128 M. Entity Tokens 7.x-1.5, Token 7.x-1.5 and Pathauth 7.x-1.2 still enabled. Thanks.

Remaining issue on the Status Report:
"The following token types are not defined but have tokens: $info['types']['taxonomy_term']"

Charles Belov’s picture

Happening for me with Pathauto 7.x-1.2 and File Entity 7.x-1.4 on Drupal 7.31.

Fortunately, we can manage without File Entity, so I'm not going to risk a patch.

Significant credit for isolating this issue goes to Derek Evans.

botanic_spark’s picture

I can confirm that #140 worked for me.

nvl.sateesh’s picture

I can confirm that this problem can occur if you have direct calls to drupal_add_js or other similar ones like include, include_once, require, require_once, etc directly in the body of the script. By moving that into appropriate function, and then clearing cache, solved the issue.






function mymodule_init(){
Dave Reid’s picture

@nvl.sateesh: In your case it's probably not the include or require that's actually at fault, but whatever is getting run in the global scope of that included somefile.php file.

ah_ma81’s picture

#183 worked good for me

imperator_99’s picture

I can confirm that #47 worked for me. While I would have loved to turn all the modules off and on, this is a complex and fragile site and I can't really afford to risk it.

bacchus101’s picture

I also took the #47 path and it worked which is good enough for the time being.

gianfrasoft’s picture

#161 solved my situation: I installed Token tweaks and set token limit to 2.

Thank you @nfavrod !

Håvard’s picture

Token Tweaks with tree limit set to 2 finally fixed the issue for me too :)

thoughtcat’s picture

Token Tweaks didn't work for me (some installation problem?). I fixed the problem by increasing PHP memory limit from 64M to 120M. Devel was showing the admin/config/search/path/patterns page PHP peak was 77.5 MB.

Håvard’s picture


I think it's important that the PHP memory limit is the same in both php.ini files. My files are set to 256 MB, but still it did not fix this íssue. Token Tweaks fixed it, but you must set the maximum token tree level to 2 in the module's config page.

vipzhicheng’s picture

Whatever please try #183's workaround.

flyke’s picture

My situation:
- i have a custom module that creates a token: basically if you have node type A with an inline entity form to add nodes of type B, and on node type B you want a token to A (for example to have path of A as part of url alias of B), this is nonexistant in Drupal for no reason at all. So I used this code to create the missing token.
- This worked great without problem on my local server
- When I enabled this on the live server, pattern settings page was blank
- Everything on live server is the same as on my local server (database, enabled modules, files,...)
- I was not using any drupal_add_js in my module
- the module didn't use any include or require files
- I tried the pathauto admin patch, it did not work
- I tried adding the line module_implements('pathauto', false, true); but that did not work
- I downloaded and enabled the token_tweaks module on the live server and set "Maximum depth limit for the token UI" to 2.
-> Everything works now on the live server as well.

As a Drupal webdeveloper, these issues are very time consuming but also confusing and sometimes tiresome to find the cause or at least a working solution.

crutch’s picture

I have to increase max_vars to 3000 allows it to load. It seems quite heavy and continues to be an issue for a few years. Is it possible to add a pattern to the database directly bypassing UI? Seems the main issue is really the loading of the UI.

mxh’s picture

Is it possible to add a pattern to the database directly bypassing UI?

Well that's the main purpose of this module: providing a UI to define URL alias patterns.

Of course there are some alternatives, for example:

  • Create a custom module, hook it into hook_node_update and hook_node_insert (or hook_entity_update and hook_entity_insert) and call path_save() in there by defining your desired URL alias pattern. See the API documentation for more details about these functions.
  • Use the Rules module instead of pathauto. I'd recommend this way if you already have installed Rules.
Charles Belov’s picture

Issue summary: View changes
Charles Belov’s picture

Issue summary: View changes

My apologies, pasted into wrong issue.

Charles Belov’s picture

Issue summary: View changes

Cruft removed

klonos’s picture

Issue summary: View changes

linkifying a couple of things and placing the screenshot inline.

klonos’s picture

Chris Charlton’s picture

#140 worked for me. :)

NanaD.Aoyagi’s picture

Patch works!

Liam Morland’s picture

Version: 7.x-1.2 » 7.x-1.x-dev
Status: Needs work » Needs review
791 bytes
PASSED: [[SimpleTest]]: [MySQL] 337 pass(es). View

This is the patch from #140 with coding standards problems fixed. No functional difference.

Dave Reid’s picture

I still think this solution is a bad workaround, as this means that other code is going to fail, like the actual token replacement. It's an indicator that something else needs to be fixed.

quicksketch’s picture

2.03 KB
PASSED: [[SimpleTest]]: [MySQL] 337 pass(es). View

Ran into this today after doing some development where I exited out of the page execution early and somehow borked the module_implements() cache.

I agree that the current solutions are not going to work well. Clearly very hacky and expires caches unnecessarily.

Why don't we just avoid module_implements_alter() in the first place? Since that's the part that's getting screwed up, if we just move the calls to core modules into pathauto_pathauto(), that'll clear everything up. The downside is that you can't rearrange the execution of order via module weight, but I don't think that sort of thing outweighs stability.

This patch removes hook_module_implements_alter() entirely. Although that hook was intended to modify for both hook_pathauto() and hook_path_alias_types(), only hook_pathauto() was really necessary. hook_path_alias_types() is not used by any of the core modules, since pathauto_path_alias_types() covers all core modules.

Thanks to @fiveandfriends in #101 for the idea.

Nitebreed’s picture

Status: Needs review » Reviewed & tested by the community

I can confirm the patch in #211 works!

weavingmedia’s picture

+1 confirming the patch in #211 works. THANK YOU!!!!

alex.designworks’s picture

+1 for #211 RTBC. Please commit.

ladybug_3777’s picture

My original issue that lead me here was seeing the following error on the "patterns" tab for pathauto when entity tokens is enabled:

PHP Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[HY000]: General error: 2006 MySQL server has gone away' in MY_DRUPAL_ROOT\includes\database\
Stack trace:
#0 MY_DRUPAL_ROOT\includes\database\ PDOStatement->execute(Array)
#1 MY_DRUPAL_ROOT\includes\database\ DatabaseStatementBase->execute(Array, Array)
#2 MY_DRUPAL_ROOT\includes\database\ DatabaseConnection->query('SELECT expire, ...', Array, Array)
#3 MY_DRUPAL_ROOT\includes\ db_query('SELECT expire, ...', Array)
#4 MY_DRUPAL_ROOT\includes\ lock_may_be_available('theme_registry:...')
#5 MY_DRUPAL_ROOT\includes\ lock_acquire('theme_registry:...')
#6 MY_DRUPAL_ROOT\includes\ ThemeRegistry->set(Array)
#7 [internal function]: DrupalCacheArray->__destruct()
#8 {main}
thrown in MY_DRUPAL_ROOT\includes\database\ on line 2171

I'm running version 1.2 of pathauto and version 1.6 of entity. When I try and apply #211 I strangely get a message that the patch already exists on my system and asks if I want to revert.

Am I missing something (or is it just that I need to be running the dev version of pathauto instead?). I will admit, I didn't read all 214 comments above.

This is what I get when I run the patch on #211

MY_DRUPAL_ROOT\sites\all\modules\contrib\pathauto>patch -p1 < replace_pathauto_module_implements-1267966.patch
patching file pathauto.module
Reversed (or previously applied) patch detected! Assume -R? [n] y
Hunk #1 succeeded at 53 (offset 16 lines).
patching file
Reversed (or previously applied) patch detected! Assume -R? [n] y

After running the command I get the following error.
PHP Fatal error: Cannot redeclare pathauto_module_implements_alter() (previously declared in MY_DRUPAL_ROOT\sites\all\modules\contrib\pathauto\pathauto.module:39) in MY_DRUPAL_ROOT\sites\all\modules\contrib\pathauto\pathauto.module on line 73

Do I just need another cup of coffee?

leewoodman’s picture

i was seeing this issue with 128M allocated in PHP.ini...changing this up to the same as my live environments 512M fixed it.

crutch’s picture

Increase PHP max_input_vars = 3000 can also help from experience. But, you may not want that high of a setting on live site so I will typically halt authenticated user activity, bring down to dev, load (wait for the display of them) and make pattern changes. Where dev I can have PHP max_input_vars = unlimited. Then push back to live and let authenticated users back in. It's only on rare occasions that we are creating or altering patterns so this process dances around the issue.

FluxSauce’s picture

2.03 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch replace_pathauto_module_implements-1267966-backported.patch. Unable to apply patch. See the log in the details link for more information. View

Backported #211 (thanks, Nate) to apply against pathauto 7.x-1.2.

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 218: replace_pathauto_module_implements-1267966-backported.patch, failed testing.

FluxSauce’s picture

Status: Needs work » Reviewed & tested by the community

Not exactly, bot.

ladybug_3777’s picture

Looks like my issue was also related to my max_allowed_packet size in MYSQL. Anyone else that needs details on adjusting that, check out this post here:

stefanos.petrakis’s picture

This is a quick drush one-liner to fix the problem.
[#150 describes the same solution]

Of course, the assumption is that the problem is caused by "greedy" recursion for Tokens.
You can try to increase/modify and test the 'token_tree_recursion_limit' variable.

drush en -y token_tweaks && drush vset token_tree_recursion_limit 2 && drush cc all

webadpro’s picture

Hello all,

After having debugging for more than 4 hours this specific issue, I had tried token_tweaks didn't change anything, I have debugged the core of drupal in order to find which module would cause the issue and I didn't get any feedback. Tried changing the memory_limit up to 512MB didn't work. My solution was the following, clone the site and uninstall the last modules that were updated one by one.

My final result was the following: Mobile Switch 7.x-2.0-beta1

This bad boy is what cause the issue for myself and hopefully this could shed some lights for others using that exact module.


Anybody’s picture

Confirming that the issue still exists. I'm currently running into this problem.

Anybody’s picture

#211 is NOT solving it for me, even after clearing caches, etc. I've got no clue why.
No errors in log.

Only the file path patterns show up. Everything else is gone.

ann b’s picture

@anybody, have you tried the #150 solution? The Token Tweaks module and setting the limit to 2 fixed the problem for me. No other changes were made to my environment.

kafmil’s picture

I had mobile_tools installed, I disabled it, went in and configured my pathauto settings, exported them to a feature, re-enabled mobile_tools. I can't see the pathauto settings while mobile_tools is installed, but at least this way my settings are in place and they work.

Anybody’s picture

Without (any) related changes the patterns are now showing up on my website again. It's a bit scary ;)

sundersingh’s picture

Version: 7.x-1.x-dev » 7.x-1.2
Status: Reviewed & tested by the community » Needs review
2.03 KB
PASSED: [[SimpleTest]]: [MySQL] 316 pass(es). View

The patch in #211 fixed the issue for me but didn't apply cleanly to 7.x-1.2 so I re-rolled it. Note, I haven't thought about the implications of what this patch is actually doing yet. Just need a quick fix to buy some time.

I was still having mixed results after applying the patch, sometimes pathauto patterns would be empty, sometimes it would show some patterns and sometimes all of them. There seemed to be some correlation with clearing caches, but nothing reliably reproducable. Yet after letting the server sit (going to lunch), things appear to be back to normal. This is a dev server in a VM so there hasn't been any other traffic or ops performed on it. I'll submit this re-roll for further consideration by the community.

DamienMcKenna’s picture

Version: 7.x-1.2 » 7.x-1.x-dev
Status: Needs review » Reviewed & tested by the community

@sundersingh: The existing patch has been reviewed against the latest -dev snapshot, not 1.2, so there might be other things going on with your version that has since been fixed.

squarecandy’s picture

yeah, sadly #211 did not work for me either. I used #183 to get it working again, but that's clearly not a long term solution.

AGriffin’s picture

For me turning off Clean Pagination fixed it.

Dave Reid’s picture

Status: Reviewed & tested by the community » Needs work

Hrm, this would cause a regression if I were to want to do this: $data = module_invoke('node', 'pathauto'). We need a different solution.

Zapa Utu’s picture

Hi All,

I've been dancing in the dark on this issue for some time now and I am just not sure what my next steps should be for debugging this issue for my particular setup. I've read (almost) every comment on this page (and others) and I can see that there's a lot of 'possible' fixes/hacks/patches that may or may not work. Which is leaving me feeling abandoned on isolation island (it's circular). ;)

Outline my situation:

• I have just completed an upgrade from d6 to d7 (currently 7.38) and everything went smoothly (roughly). ;)
• On my local setup everything works great (pathauto patterns page is displaying and no issue)
• On dev server pathauto patterns page is not working, it's just blank and nothing in the error logs (as many of you have stated above)
• We're currently in the final phases and we were planning on going live next week, but now this problem has appeared and this is a major blocker as the client is needing the generated URLs for his contributors who are scheduled to start working on Monday
• I also have way too many modules installed to be sure how/where the issue has happened, so pin-pointing the culprit is impossible

Key questions:

  1. Ok - so I guess my first question is related to the glaringly obvious "php memory limit" proposal many of you have made, but I'd like to know from someone who understands the "bug" to confirm if this is really a solution? Seems to me, if we are looking at a bug, then the server setup is not related? But the difference between local and live servers does beg the question - although it feels odd to me and I need to tell the client the probability of that actually making a difference.
  2. Next question is for the patches - @Dave Reid (and others contributing) - to patch or not to patch? I just need a good answer here, as of course my client does not want to be managing hacked modules, and I don't like the idea at all. But what should I do in terms of getting a 'quick fix' by Monday?

** Please note I am fairly new to Drupal in general, but I am working on corporate websites which can be very content and module heavy, which in turn has forced me to learn very quickly what is going on, so please be patient with me if I sound like I am struggling to get the 'basics'. I am a web developer however, I'm just new(ish) to Drupal, so you can speak 'code' to me, but I'm looking for some serious advice on this problem.

Thanks to all who are constantly sharing your experiences, reports and knowledge. Looking forward to be becoming a valuable contributor one day so that I can return the favor.

stefan.r’s picture

The patch in #496170: module_implements() cache can be polluted by module_invoke_all() being called (in)directly prior to full bootstrap completion may be the safest bet, that way it's solved in all modules that may have similar module_implements() issues.

stefan.r’s picture

Other modules have fixed this issue by adding an empty hook_boot implementation. That way the module is added to the limited list of "bootstrap" modules.

This is all due to a core bug though so other modules may have similar issues (though most will be patched by now), the patch in #496170: module_implements() cache can be polluted by module_invoke_all() being called (in)directly prior to full bootstrap completion should fix the root cause.

stefan.r’s picture

Status: Needs work » Needs review
542 bytes
PASSED: [[SimpleTest]]: [MySQL] 337 pass(es). View
Zapa Utu’s picture

Thanks stefan.r for sending me in the right direction - appreciate the advice, makes the most sense to me to patch the source of the problem. ;)’s picture

"I found a magic solution

Overlay module active - No Patterns visible
Deactivated the Overlay module - Patterns are visible, any patterns configured
Overlay module again activated - Patterns are visible"

Work for me. Tks!

rbns’s picture


"Magic solution" worked for me also.

Overlay module active - No Patterns visible
Deactivated the Overlay module - Patterns are visible, any patterns configured
Overlay module again activated - Patterns are visible"

It is strange, but solved. I'm on Drupal 7.38 wiht a lot of modules on.

Tregonia’s picture

The magic solution was not all that magical for me; i even uninstalled the overlay module. I am still missing the form elements and only have the save button

The patch in #238 did work for me

interdruper’s picture

After unsuccessful trials with Token Tweaks, finally #238 fixed the issue for me. Thx!

bsuttis’s picture

Confirming the patch in #238 brought the form back but the nodes still are not saving with their designated path pattern.. any one else having the same issue?

cbeier’s picture

Status: Needs review » Needs work

I can confirm that the patch from #238 brings the full settings form back. But entered patterns are not saved. After a complete reload of the pathauto settings form, the changes are gone.

After that, I have in addition to the patch #238 also applied the patch from comment #140. And with this patch, also my changes in the form are saved.

I set the status back to "needs work" because the patch from #238 resolves the issue not complete.

cbeier’s picture

Status: Needs work » Needs review
1.3 KB
PASSED: [[SimpleTest]]: [MySQL] 337 pass(es). View

I have combined the patch from #140 and #328, because these two patches resolves the issue for me.

jucedogi’s picture

@cbeier Your patch worked perfectly on my dev machine but didn't work on my partner's machine.
Possibly different PHP versions or settings caused this.
Anyways thanks to that patch I was able to solve the problem so thank you for the file.

cbeier’s picture

@jucedogi: Can you describe what exactly does not work on the machine of your partner? If the settings are not displayed or the changes in the form not saved? Has he (your partner) the problem on the same project or difference project (with different modules)? Maybe he can clear the drupal cache (full) again or reinstall the phpauto module.

Dave Reid’s picture

Please give the latest 7.x-1.3 release a try. We got rid of the hook_module_implements_alter() use in Pathauto.

mxwright’s picture

@Dave Reid the 7.x-1.3 release seems to do the trick for me. Thanks!

sumthief’s picture

@Dave Reid the 7.x-1.3 release works for me too. Thanks.

Nitebreed’s picture

Status: Needs review » Reviewed & tested by the community
crutch’s picture

I have a small tear. Works :)

joaomachado’s picture

8 KB

Browse available tokens = works

Browse available tokens = works

Browse available tokens = DOES NOT WORK


SERVER: Hardware based (6Core, 32GB Memory)
PHP Memory: 500M
Drupal: 7.39
Pathauto: 7x.13
Overlay module disabled
20 Content Types

Could it be that there are too many content types? Each one has about 10 fields...

sumthief’s picture

@joaomachado, I've tested your problem on local machine (4cores with HT, 8GB memory). I have 15 content types (but field quantity less then your) and tokens for content loads but with delay about 4 seconds. You can try to downgrade to 7.x-1.2 and check this problem on your configuration.

joaomachado’s picture

@Shlyapkin Should downgrade to 7.x-1.2 and apply the patch?

sumthief’s picture

@joaomachado, You can try to downgrade to 1.2 version to check browse available tokens feauture is works. If does you can report about the issue.

AndreyEfremov’s picture

Downloaded the latest release 7.x-1.3 Here is the error:

PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'prof111_db.pathauto_state' doesn't exist: SELECT 1 AS expression FROM {pathauto_state} pathauto_state WHERE ( (entity_type = :db_condition_placeholder_0) AND (entity_id = :db_condition_placeholder_1) ); Array ( [:db_condition_placeholder_0] => node [:db_condition_placeholder_1] => 119 ) в функции pathauto_entity_state_save() (строка 492 в файле /home/prof111/

works well

sumthief’s picture

Hi, @AndreyEfremov. Do you execute updates?

joaomachado’s picture

28.71 KB

@Shlyapkin I downgraded to 7.x-1.2 and I went back to the error I used to get before I upgraded to 7.x-1.3

I honestly don't know if the browse feature worked in 7.x-1.2 because I could never get to the screen.
Once I set up the original patterns never had a reason to go and check, because everything always worked everywhere else. It was only when I needed to make a change, that this issue showed up. The other tabs, List, Settings, Bulk Generate and Delete Aliases work fine. I upgraded back to 7.x-1.3 and the Patterns page returns but still no love.

While I had 7.x-1.2 installed, I checked the log file and there was an error from Views_selective_filter, I disabled the module to no avail.

I flushed caches and ran cron every time I made a change by the way.


AndreyEfremov’s picture

@Shlyapkin The problem is that updating the database fails in version 7.x-1.3 in 7.x-1.2 the table is created normally

AndreyEfremov’s picture

@Shlyapkin The problem was solved as follows. Removed the module version 7.x-1.2, deleted the table in phpMyAdmin, downloaded the module 7.x-1.3 table in phpMyAdmin was created. When updating the table is not created. The issue has been resolved.

joaomachado’s picture

@AndreyEfremov what is the table name?

Leeteq’s picture

@joaomachado; I assume it is the new 'pathauto_state' table that is not created, ref. the error quoted in #258:

"PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'prof111_db.pathauto_state' doesn't exist"

joaomachado’s picture

I am a little confused... I cannot find any table called "pathauto_state" using phpMyAdmin. DO I have to created manually if so how?

kenorb’s picture

@joaomachado, @AndreyEfremov: Follow this issue instead: #2591453: Table '' doesn't exist (just run your site updates). This one is different and already solved as part of the patch file.

Leeteq’s picture

Status: Reviewed & tested by the community » Needs work

From the latest comments, it sounds like:

a) The patch is not needed, the issue has been resolved in 1.3, but only for new/fresh installs.

b) Installing 1.3 from scratch creates the pathauto_state table as mentioned in a), but UPDATING from previous versions fails to create that new table.

Setting back to needs work, to fix the failing update.

crutch’s picture

My experience was updated from 7x.-1.2 to 7.x-1.3 on Core 7.38 at post #253 above and pathauto_state table exists and no errors appeared.

Just now updated a different site 7x.-1.2 to 7.x-1.3 (all sites are currently Core 7.41) and table was created with no errors.

joaomachado’s picture

OK - still using Core 7.39, backed up all of my databases, and disabled pathauto module, then under the uninstall tab deleted the pathauto module. using cPanel file manager went to /sites/all/modules/ and deleted pathauto module from server.

Installed the new pathauto 1.3 version using the normal procedure /admin/modules/install (no errors).
Ran update script, no errors, enabled pathauto module no errors, ran update script again (no errors) and ran CRON.

Issue still the same as post #254 and still no pathauto_state table

I will be going through some modules I have that are no longer being used and deleting anything and everything that is not needed and try again.

Note: server is using mariadb 5.5.5-10.0.21-MariaDB and PHP 5.5.30

cesarmiquel’s picture

We were also experiencing this issue and it turns out that as with comment #1267966-28: Pathauto patterns are not showing up and #1267966-126: Pathauto patterns are not showing up: a redefined constant Notice in the watchdog. I would strongly recommend anybody who has this issue to check their watchdog and make sure they don't have any: Notice: Constant XXXXX already... error. After debugging the code we came to the same conclusion as #1267966-10: Pathauto patterns are not showing up but the real culprit was the redefined constant. Removing it fixed our empty screen.

stefan.r’s picture

@cesarmiquel now that #496170: module_implements() cache can be polluted by module_invoke_all() being called (in)directly prior to full bootstrap completion is in Drupal 7.40 a watchdog call in early bootstrap should not be causing any issues any more.

cesarmiquel’s picture

@stefan.r Ahhh... Now I understand why such a seemingly harmless Notice can cause such havoc! In our case it was causing a huge amount of random and non-reproducible problems with tokens. Thanks for your comment.

hollyfox’s picture

Check your php error log to see if it is giving you 'PHP Fatal error: Allowed memory size of 1073741824 bytes exhausted' type error when you load the page. If it is, set your php.ini memory limit higher. Also, make sure that you do not have a memory limit statement in you settings file.

I think that many times, disabling modules may resolve the problem because it reduces the memory in use allowing the page to load, although, if there is no memory error in the log, there may be other issues as stated above.

I hope this helps someone.