Posted by ekkosmos on September 2, 2011 at 4:37pm
111 followers
| Project: | Pathauto |
| Version: | 7.x-1.2 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
Problem/Motivation
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
None.
API changes
None.
Original report by ekkosmos
I don't know why the pathauto patterns are not showing up... (see attached image)
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| img_patterns.jpeg | 32.58 KB | Ignored: Check issue status. | None | None |
Comments
#1
I have the same problem the Patterns page is coming up blanc but there aren't any errors in the logs.
#2
The problem seems to be the Entity tokens module. Once i disable it the Patterns page works again.
#3
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.
#4
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.
#5
i confirm this also
#6
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.
#7
I found it for me, it was Mobile Tools.
#8
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.
#9
I have same problem, but I have a lot of modules, so it's really hard to find out conflicting module.
#10
Part of the problem is that
module_invoke_all('pathauto', 'settings')returns an empty array, in line 18 of pathauto.admin.inc:// using latest dev version, starting at line 10:
<?php
**
* 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.
#11
After update from 6 to 7.8 I am having the same problem.
Only modules installed are cck content migrate token and path auto
#12
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.
#13
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.
#14
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.
#15
For me it was the module Webform table element. Turning it off did the trick.
#16
Same problem, "allow_call_time_pass_reference On" in php.ini and flush cache helped me. PHP 5.3.3-7+squeeze3
#17
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.
#18
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.
#19
Going to mark this as cannot reproduce then.
#20
Ok I will try using Mobile Theme instead of Mobile Tools. Thanks for the tip.
#21
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.
#22
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.
#23
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.
#24
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 module.inc), invoked from module_invoke_all('pathauto', 'settings') hook call in pathauto.admin.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.
#25
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.
#26
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.
#27
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.
#28
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!!!
#29
Experiencing this - http:BL is our culprit...
#30
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..)
#31
For the wide majority of module users this DOES NOT HAPPEN, so let's please leave this at cannot reproduce.
#32
Okay Dave! Maybe I was a little annoyed. Sorry about that.
I tracked the problem down- for me it was caused by @Tagadelic module.
#33
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.
#34
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?
#35
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"...to 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.
#36
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.
#37
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.
#38
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.
#39
My issue was resolved by @awolfey in #37.
#40
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.
EDIT
I rebuilt the registry, cleared the cache and the problem persists.
#41
#42
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:<?phpdrupal_add_js('link/to/existing/js.js');
?>
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...! :-)
#43
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.
#44
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.
#45
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.
http://www.emmajane.net/php-what-call-time-pass-reference-story
#46
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!!!
#47
I'm in no way sure if this fixes the problem in general and it's pretty hacky, but by adding
<?phpmodule_implements('pathauto', false, true);
?>
to pathauto.admin.inc just before
<?php$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.
#48
@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
#49
Thanks @attiks!
#50
#47 worked for me.
Thanks Kaz
#51
#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.
#52
Why is this just happening to pathauto? Lots of different ways to break this page it seems.
#53
#47 worked for me too. Thanks a lot !
#54
#47 worked for me also.
#55
YAY! #47 works. You rock!
#56
Ok, so how do we get this fixed in the next stable release? Obviously #47 isn't a permanent solution.
#57
#47 worked for me too. Thanks a lot !
#58
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.
#59
I've experienced the same issue on a complex site.
#47 worked for me also.
#60
i had that problem with the latest dev of variable and i18n. downgraded back to the latest stable, works.
#61
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.
#62
But no one has actually verified or identified a problem in Pathauto aside from other modules that conflict and cause errors, so no.
#63
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.
#64
So far the problems debugged so far have been other modules doing things wrong, so that's not really interoperability.
#65
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.
#66
I found this issue on a site and also traced it back to a different module calling
<?phpdrupal_add_js()
?>
module_hook_info()to run before all.modulefiles had been loaded, includingpathauto.module, which in turn resulted inpathauto_hook_info()not existing when the static cache of hooks was being built. Moving thedrupal_add_js()call into a proper function (or into the.infofile) fixes the problem.#67
@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.
#68
#47 works for meI am not using any of the reported modules; I uninstalled all modules added prior to the bug; no idea what happened, but #47 fixed itIt 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!
#69
#47 working for me too.
#70
@jdanthinne (and all others) can you check your modules and theme code for the presence of php code outside of any function?
#71
#47 working for me too. Thanks!
#72
@attiks : Is there an easy way to do that (± 60 modules enables, so a lot of files to check…)?
#73
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.
#74
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.
#75
After upgrading 1.0 to 1.1 all my patterns diapered.
#76
#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…
#77
#47 works for the interface, but bulk updating the Paths is not fixed by that.
#78
#47 worked for me!
Thanks!!!!
#79
#47 works perfectly!
Thanks!!!!
#80
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
#81
@Summit
I don't know if you saw my post about #47 failing to solve this
#82
#47 worked for me.
Before the modification, I couldn't see the collapsible tab "Content paths"... but now all is right.
Thanks
#83
#74 temporarily fixed my problem (disable Variable Realm)
#84
Hi Guys, for me working again. It was a language issue.. sorry to bother you guys.
greetings, Martijn
#85
How have you solved the language issue? Have you any details?
#86
#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.
#87
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 pathauto.pathauto.inc 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:
<?phpfunction pathauto_invoke_all($op) {
module_load_include('pathauto.inc', '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...
#88
See Drupal core issue here #496170: Bad logic in module_implements() ?
#89
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.
#90
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.
#91
Number 47 worked for me.
#92
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.
#93
Latest (dev) version of variable 2.x should fix this issue.
#94
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.
#95
#74 worked for me. Thanks jdanthinne
#96
#47 worked. Hacky but perfect 'till the next update.
Thanks.
#97
Disabling Variable Realm module brought the patterns page back for me...
#98
Yeah, thanks for #47 !
#99
#97: same for me
#100
Variable 7.x-2.1 (stable) solves this issue, no need to disable variable realm, specially if you need it.
#101
We have found a "work a round". In the pathauto.pathauto.inc the function pathauto_pathauto() is empty. I have overridden this function by this:
<?phpfunction pathauto_pathauto($arg) {
// delegates the arg´s to node_pathauto()
return node_pathauto($arg);
}
?>
and still it works fine.... hope it´s help.
#102
For what is the workaround needed? The new version of Variable should fix this issue.
#103
No the newest Version doesn´t fix this problem for us.
#104
After cron run and clear cache newest variable version (+ latest i18n) seems to fix this issue for me. Thx guys.
#105
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.
#106
Well, it did return the pattern page but, for me, the patterns are not applied while editing/creating pages.
//edit
After clearing caches and submiting aliases pattern page it seems to work.
#107
Agree with #100, upgrading from variable 7.x.2.0 to 7.x.2.1 solved the problem for me.
#108
upgrading to variable 2.1 fixed it here. and we have a ton of modules.
#109
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.
//edit
Did some tests - clearing caches breaks patterns. Need to submit pattern page to get it work.
#110
Same as #108: upgrading to variable 2.1 fixed it
#111
Hi,
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.
#112
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
#113
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.
#114
Updating to Variable 7.x-2.1 (2 July, 2012) from 1.x dev also fixed this for me. Thanks for the suggestions above.
#115
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!!!
#116
Variable 2.1 fixed this for me, too. Thanks guys.
#117
Update to variable 2.1 fixed this problem, thanks.
#118
Same problem, Same solution as #16. Check your logs if you get any php notices or errors and try to fix them.
#119
#47 worked for me. I have set up multi-site, only one site had the problem.
#120
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.
#121
Same problem as #120. I create a bug report for this issue with Mobile Switch : http://drupal.org/node/1828094
#122
solution #47 ftw !
#123
#124
I have the same problem.
D 7.17
Token 7.x-1.4
Pathauto 7.x-1.2
I found a magic solution
#125
Raising the PHP memory limit solved this issue for me. Just an FYI.
-Trevor
#126
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.
#127
Having the same issue here, cant really go around disabling modules. Will try the php.ini solution and report back.
#128
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.
#129
Great hack. Yes, it's hacky, but if things do not work as expected, sometimes hacking it works.
#130
#124 worked for me .
#131
#124 worked for me .
#132
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/cird.dev/htdocs/includes/database/database.inc:2139Stack trace:
#0 /Users/stephenm/Sites/cird.dev/htdocs/includes/database/database.inc(2139): PDOStatement->execute(Array)
#1 /Users/stephenm/Sites/cird.dev/htdocs/includes/database/database.inc(664): DatabaseStatementBase->execute(Array, Array)
#2 /Users/stephenm/Sites/cird.dev/htdocs/includes/database/database.inc(2318): DatabaseConnection->query('SELECT expire, ...', Array, Array)
#3 /Users/stephenm/Sites/cird.dev/htdocs/includes/lock.inc(167): db_query('SELECT expire, ...', Array)
#4 /Users/stephenm/Sites/cird.dev/htdocs/includes/lock.inc(146): lock_may_be_available('theme_registry:...')
#5 /Users/stephenm/Sites/cird.dev/htdocs/includes/theme.inc(447): lock_acquire('theme_registry:...')
#6 /Users/stephenm/Sites/cird.dev/htdocs/includes/bootstrap.inc(442): ThemeRegistry->set(Array)
#7 [internal function]: DrupalCacheArray in /Users/stephenm/Sites/cird.dev/htdocs/includes/database/database.inc on line 2139
UPDATE
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.
#133
As with #120, disabling Mobile Switch solved the problem.
#134
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).
#135
"""#47""" worked for me.. Even I had same problem..
#136
#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().
I've updated the issue summary with these remarks.
#137
Got the same problem and #47 works. Thank you!
But is there any better practice to solve this problem?
#138
I had the same problem and I updated variable to 2.1 and it works now (also updated entity api to 1.0).
#139
This path works correctly.
Thanks to whitingx
#140
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.
#141
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.
#142
I solved the problem by boosting the max packet size in MySQL from 1MB to 16MB.
#143
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 !
#144
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.
#145
This did not work for me :(
#146
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.
#147
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.
#148
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.
#149
Hi, #47 and therefore patch #140 worked great for me!
greetings, Martijn
#150
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. http://drupal.org/node/1800562#comment-6859344. I installed the Token Tweaks module, set the limit to 2, and my problem was resolved.
#151
#14 solved it for me.