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 #47 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... (see attached image)

#140 pathauto_admin.patch791 bytesalarcombe
PASSED: [[SimpleTest]]: [MySQL] 316 pass(es).
[ View ]


Priority:Normal» Major

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

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

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.

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.

i confirm this also

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.

I found it for me, it was Mobile Tools.

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.

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

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()
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.

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

Only modules installed are cck content migrate token and path auto

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.

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.

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.

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

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

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.

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.

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

Going to mark this as cannot reproduce then.

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

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.

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.

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.

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.

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.

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.

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.

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!!!

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

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..)

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

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.

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.

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?

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.

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.

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.

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.

My issue was resolved by @awolfey in #37.

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.

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

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...! :-)

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.

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.

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.

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!!!

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

('pathauto', false, true);

to just before
= 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.

@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

Thanks @attiks!

#47 worked for me.
Thanks Kaz

#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.

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

#47 worked for me too. Thanks a lot !

#47 worked for me also.

YAY! #47 works. You rock!

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

#47 worked for me too. Thanks a lot !

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.

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

#47 worked for me also.

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

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.

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.

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.

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

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.

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.

@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.

#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!

#47 working for me too.

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

#47 working for me too. Thanks!

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

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.

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.

After upgrading 1.0 to 1.1 all my patterns diapered.

#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…

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

#47 worked for me!

#47 works perfectly!

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


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!

#47 worked for me.

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

#74 temporarily fixed my problem (disable Variable Realm)

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

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

#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.

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');
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...

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.

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.

Number 47 worked for me.

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.

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

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.

#74 worked for me. Thanks jdanthinne

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


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

Yeah, thanks for #47 !

#97: same for me

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

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.

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

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

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

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.

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.

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

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

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.

Same as #108: upgrading to variable 2.1 fixed it


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.

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

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.

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

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!!!

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

Update to variable 2.1 fixed this problem, thanks.

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

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

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.

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

solution #47 ftw !

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

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

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


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.

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

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.

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

#124 worked for me .

#124 worked for me .

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.

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

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).

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

#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.

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

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

This path works correctly.
Thanks to whitingx

new791 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.

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.

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

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 !

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.

This did not work for me :(

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.

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.

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.

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

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.

#14 solved it for me.

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

Patch #140 worked for me!

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

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.

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.

#140 worked for me! Thanks for the fix!

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

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. :-)

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

Patch #140 works for me

Had same problems: solved without patches but with :

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

#140 worked here with the latest -dev.

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

#140 worked for me

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.

Issue summary:View changes

Better summary

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?

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

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.

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

#140 work like a charm

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.

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

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.

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

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.

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.

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

#140 fixed both tabs over here.

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.

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

The patch #140 do not actually fix the bug.

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

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.