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 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
None.
API changes
None.
Original report by ekkosmos
I don't know why the pathauto patterns are not showing up...
Comment | File | Size | Author |
---|---|---|---|
#260 | Selection_343.png | 28.71 KB | joaomachado |
#254 | Selection_341.png | 8 KB | joaomachado |
#246 | pathauto-pattern-1267966-256.patch | 1.3 KB | cbeier |
#238 | 1267966-238.patch | 542 bytes | stefan.r |
#230 | replace_pathauto_module_implements-1267966-230.patch | 2.03 KB | sundersingh |
Comments
Comment #1
dazz CreditAttribution: dazz commentedI have the same problem the Patterns page is coming up blanc but there aren't any errors in the logs.
Comment #2
dazz CreditAttribution: dazz commentedThe problem seems to be the Entity tokens module. Once i disable it the Patterns page works again.
Comment #3
ekkosmos CreditAttribution: ekkosmos commentedFor 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.
Comment #4
alexdmccabeThis 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.
Comment #5
ekkosmos CreditAttribution: ekkosmos commentedi confirm this also
Comment #6
Dave ReidI 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.
Comment #7
alexdmccabeI found it for me, it was Mobile Tools.
Comment #8
artofeclipse CreditAttribution: artofeclipse commentedsubscribe ...
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.
Comment #9
Cray Flatline CreditAttribution: Cray Flatline commentedI have same problem, but I have a lot of modules, so it's really hard to find out conflicting module.
Comment #10
jghyde CreditAttribution: jghyde commentedPart of the problem is that
module_invoke_all('pathauto', 'settings')
returns an empty array, in line 18 of pathauto.admin.inc:I'd like to upgrade this bug to critical. The module is not functional until this bug is fixed.
Comment #11
Kristjan Logason CreditAttribution: Kristjan Logason commentedAfter update from 6 to 7.8 I am having the same problem.
Only modules installed are cck content migrate token and path auto
Comment #12
Dave ReidSorry, 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.
Comment #13
Audrius Vaitonis CreditAttribution: Audrius Vaitonis commentedThis 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.
Comment #14
raveman CreditAttribution: raveman commentedEncrease 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.
Comment #15
MHilliker CreditAttribution: MHilliker commentedFor me it was the module Webform table element. Turning it off did the trick.
Comment #16
Sano-2 CreditAttribution: Sano-2 commentedSame problem, "allow_call_time_pass_reference On" in php.ini and flush cache helped me. PHP 5.3.3-7+squeeze3
Comment #17
Samlet9908 CreditAttribution: Samlet9908 commentedI 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.
Comment #18
alexdmccabeNot 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.
Comment #19
Dave ReidGoing to mark this as cannot reproduce then.
Comment #20
Samlet9908 CreditAttribution: Samlet9908 commentedOk I will try using Mobile Theme instead of Mobile Tools. Thanks for the tip.
Comment #21
Audrius Vaitonis CreditAttribution: Audrius Vaitonis commentedThanks 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.
Comment #22
Liam MorlandI 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.
Comment #23
iainp999 CreditAttribution: iainp999 commentedSame 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.
Comment #24
crispymix CreditAttribution: crispymix commentedHi - 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.
Comment #25
iSampo CreditAttribution: iSampo commentedThis 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.
Comment #26
ThomasH CreditAttribution: ThomasH commentedSame 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.
Comment #27
ronny89 CreditAttribution: ronny89 commentedin 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.
Comment #28
angel.hI 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!!!
Comment #29
pfaocleExperiencing this - http:BL is our culprit...
Comment #30
Daniel Schaefer CreditAttribution: Daniel Schaefer commentedThe 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..)
Comment #31
Dave ReidFor the wide majority of module users this DOES NOT HAPPEN, so let's please leave this at cannot reproduce.
Comment #32
Daniel Schaefer CreditAttribution: Daniel Schaefer commentedOkay Dave! Maybe I was a little annoyed. Sorry about that.
I tracked the problem down- for me it was caused by @Tagadelic module.
Comment #33
Andy Tawse CreditAttribution: Andy Tawse commentedAs 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.
Comment #34
capellicPanelizer 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?
Comment #35
adroid CreditAttribution: adroid commentedReasons 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.
Comment #36
michaelfavia CreditAttribution: michaelfavia commentedFWIW 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.
Comment #37
awolfey CreditAttribution: awolfey commentedThis 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.
Comment #38
jmcoder CreditAttribution: jmcoder commentedHad 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.
Comment #39
capellicMy issue was resolved by @awolfey in #37.
Comment #40
brandy.brown CreditAttribution: brandy.brown commentedI 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.
Comment #41
brandy.brown CreditAttribution: brandy.brown commentedComment #42
lmeurs CreditAttribution: lmeurs commentedI 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...! :-)
Comment #43
MixologicOkay, 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.
Comment #44
attiks CreditAttribution: attiks commentedWe 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.
Comment #45
mgiffordI 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
Comment #46
cmak CreditAttribution: cmak commentedI 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!!!
Comment #47
Kaz de Groot CreditAttribution: Kaz de Groot commentedI'm in no way sure if this fixes the problem in general and it's pretty hacky, but by adding
to pathauto.admin.inc just before
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.
Comment #48
attiks CreditAttribution: attiks commented@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
Comment #49
mgiffordThanks @attiks!
Comment #50
markboniface CreditAttribution: markboniface commented#47 worked for me.
Thanks Kaz
Comment #51
Perignon CreditAttribution: Perignon commented#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.
Comment #52
mgiffordWhy is this just happening to pathauto? Lots of different ways to break this page it seems.
Comment #53
rfc2460 CreditAttribution: rfc2460 commented#47 worked for me too. Thanks a lot !
Comment #54
jmdeleon CreditAttribution: jmdeleon commented#47 worked for me also.
Comment #55
brandy.brown CreditAttribution: brandy.brown commentedYAY! #47 works. You rock!
Comment #56
mgiffordOk, so how do we get this fixed in the next stable release? Obviously #47 isn't a permanent solution.
Comment #57
eric.chenchao CreditAttribution: eric.chenchao commented#47 worked for me too. Thanks a lot !
Comment #58
Perignon CreditAttribution: Perignon commentedYa 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.
Comment #59
cjtriplett CreditAttribution: cjtriplett commentedI've experienced the same issue on a complex site.
#47 worked for me also.
Comment #60
marcoka CreditAttribution: marcoka commentedi had that problem with the latest dev of variable and i18n. downgraded back to the latest stable, works.
Comment #61
mgiffordI'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.
Comment #62
Dave ReidBut no one has actually verified or identified a problem in Pathauto aside from other modules that conflict and cause errors, so no.
Comment #63
Perignon CreditAttribution: Perignon commentedYou 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.
Comment #64
Dave ReidSo far the problems debugged so far have been other modules doing things wrong, so that's not really interoperability.
Comment #65
mxhGod 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.
Comment #66
jhedstromI 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, 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.info
file) fixes the problem.Comment #67
attiks CreditAttribution: attiks commented@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.
Comment #68
decibel.places CreditAttribution: decibel.places commented#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!
Comment #69
jdanthinne CreditAttribution: jdanthinne commented#47 working for me too.
Comment #70
attiks CreditAttribution: attiks commented@jdanthinne (and all others) can you check your modules and theme code for the presence of php code outside of any function?
Comment #71
xcafebabe CreditAttribution: xcafebabe commented#47 working for me too. Thanks!
Comment #72
jdanthinne CreditAttribution: jdanthinne commented@attiks : Is there an easy way to do that (± 60 modules enables, so a lot of files to check…)?
Comment #73
attiks CreditAttribution: attiks commentedNot 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.
Comment #74
jdanthinne CreditAttribution: jdanthinne commentedI'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.
Comment #75
batigol CreditAttribution: batigol commentedAfter upgrading 1.0 to 1.1 all my patterns diapered.
Comment #76
mikl CreditAttribution: mikl commented#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…
Comment #77
Wolfgang Reszel CreditAttribution: Wolfgang Reszel commented#47 works for the interface, but bulk updating the Paths is not fixed by that.
Comment #78
miguered CreditAttribution: miguered commented#47 worked for me!
Thanks!!!!
Comment #79
jdeg CreditAttribution: jdeg commented#47 works perfectly!
Thanks!!!!
Comment #80
Summit CreditAttribution: Summit commentedHi, #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
Comment #81
decibel.places CreditAttribution: decibel.places commented@Summit
I don't know if you saw my post about #47 failing to solve this
Comment #82
bettisfr CreditAttribution: bettisfr commented#47 worked for me.
Before the modification, I couldn't see the collapsible tab "Content paths"... but now all is right.
Thanks
Comment #83
lstoetzel CreditAttribution: lstoetzel commented#74 temporarily fixed my problem (disable Variable Realm)
Comment #84
Summit CreditAttribution: Summit commentedHi Guys, for me working again. It was a language issue.. sorry to bother you guys.
greetings, Martijn
Comment #85
Wolfgang Reszel CreditAttribution: Wolfgang Reszel commentedHow have you solved the language issue? Have you any details?
Comment #86
duvalbruno CreditAttribution: duvalbruno commented#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.
Comment #87
Jose Reyero CreditAttribution: Jose Reyero commentedI'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:
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...
Comment #88
Jose Reyero CreditAttribution: Jose Reyero commentedSee Drupal core issue here #496170: module_implements() cache can be polluted by module_invoke_all() being called (in)directly prior to full bootstrap completion
Comment #89
Jose Reyero CreditAttribution: Jose Reyero commentedAlso 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.
Comment #90
Dave ReidIt 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.
Comment #91
ericinwisconsin CreditAttribution: ericinwisconsin commentedNumber 47 worked for me.
Comment #92
trong.nguyen.tcec CreditAttribution: trong.nguyen.tcec commentedHi, 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.
Comment #93
Jose Reyero CreditAttribution: Jose Reyero commentedLatest (dev) version of variable 2.x should fix this issue.
Comment #94
phm CreditAttribution: phm commentedI 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.
Comment #95
pyshgavak CreditAttribution: pyshgavak commented#74 worked for me. Thanks jdanthinne
Comment #96
dcoulombe CreditAttribution: dcoulombe commented#47 worked. Hacky but perfect 'till the next update.
Thanks.
Comment #97
joaomachado CreditAttribution: joaomachado commentedDisabling Variable Realm module brought the patterns page back for me...
Comment #98
joelrotelli CreditAttribution: joelrotelli commentedYeah, thanks for #47 !
Comment #99
stijntilleman CreditAttribution: stijntilleman commented#97: same for me
Comment #100
bmunslow CreditAttribution: bmunslow commentedVariable 7.x-2.1 (stable) solves this issue, no need to disable variable realm, specially if you need it.
Comment #101
fiveandfriends CreditAttribution: fiveandfriends commentedWe have found a "work a round". In the pathauto.pathauto.inc the function pathauto_pathauto() is empty. I have overridden this function by this:
and still it works fine.... hope it´s help.
Comment #102
Wolfgang Reszel CreditAttribution: Wolfgang Reszel commentedFor what is the workaround needed? The new version of Variable should fix this issue.
Comment #103
fiveandfriends CreditAttribution: fiveandfriends commentedNo the newest Version doesn´t fix this problem for us.
Comment #104
batigol CreditAttribution: batigol commentedAfter cron run and clear cache newest variable version (+ latest i18n) seems to fix this issue for me. Thx guys.
Comment #105
laevensv@gmail.com CreditAttribution: laevensv@gmail.com commentedI 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.
Comment #106
Countach CreditAttribution: Countach commentedWell, 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.
Comment #107
familymangreg CreditAttribution: familymangreg commentedAgree with #100, upgrading from variable 7.x.2.0 to 7.x.2.1 solved the problem for me.
Comment #108
mike503 CreditAttribution: mike503 commentedupgrading to variable 2.1 fixed it here. and we have a ton of modules.
Comment #109
Countach CreditAttribution: Countach commentedThis 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.
Comment #110
adiatisSame as #108: upgrading to variable 2.1 fixed it
Comment #111
maxplus CreditAttribution: maxplus commentedHi,
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.
Comment #112
decibel.places CreditAttribution: decibel.places commentedslightly 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
Comment #113
Amber Himes MatzI 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.
Comment #114
Danny EnglanderUpdating to Variable 7.x-2.1 (2 July, 2012) from 1.x dev also fixed this for me. Thanks for the suggestions above.
Comment #115
pmkanse CreditAttribution: pmkanse commentedHI 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!!!
Comment #116
jiakomo CreditAttribution: jiakomo commentedVariable 2.1 fixed this for me, too. Thanks guys.
Comment #117
SpleshkaUpdate to variable 2.1 fixed this problem, thanks.
Comment #118
ptrl CreditAttribution: ptrl commentedSame problem, Same solution as #16. Check your logs if you get any php notices or errors and try to fix them.
Comment #119
ram4nd CreditAttribution: ram4nd commented#47 worked for me. I have set up multi-site, only one site had the problem.
Comment #120
irp-socotec-nucleaire CreditAttribution: irp-socotec-nucleaire commentedFor 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.
Comment #121
mattew CreditAttribution: mattew commentedSame problem as #120. I create a bug report for this issue with Mobile Switch : http://drupal.org/node/1828094
Comment #122
sunchaser CreditAttribution: sunchaser commentedsolution #47 ftw !
Comment #123
whitingx CreditAttribution: whitingx commentedComment #124
quiptime CreditAttribution: quiptime commentedI have the same problem.
D 7.17
Token 7.x-1.4
Pathauto 7.x-1.2
I found a magic solution
Comment #125
ambientdrup CreditAttribution: ambientdrup commentedRaising the PHP memory limit solved this issue for me. Just an FYI.
-Trevor
Comment #126
tlarrieu CreditAttribution: tlarrieu commentedSame 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.
Comment #127
dabito CreditAttribution: dabito commentedHaving the same issue here, cant really go around disabling modules. Will try the php.ini solution and report back.
Comment #128
Back From 7 CreditAttribution: Back From 7 commentedMy 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.
Comment #129
hwi2 CreditAttribution: hwi2 commentedGreat hack. Yes, it's hacky, but if things do not work as expected, sometimes hacking it works.
Comment #130
josejayesh CreditAttribution: josejayesh commented#124 worked for me .
Comment #131
josejayesh CreditAttribution: josejayesh commented#124 worked for me .
Comment #132
capellicEntity 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:
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.
Comment #133
Anonymous (not verified) CreditAttribution: Anonymous commentedAs with #120, disabling Mobile Switch solved the problem.
Comment #134
Back From 7 CreditAttribution: Back From 7 commentedI 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).
Comment #135
bharathkumarkn CreditAttribution: bharathkumarkn commented"""#47""" worked for me.. Even I had same problem..
Comment #136
c4rl CreditAttribution: c4rl commented#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.
Comment #137
hanamizuki CreditAttribution: hanamizuki commentedGot the same problem and #47 works. Thank you!
But is there any better practice to solve this problem?
Comment #138
farse CreditAttribution: farse commentedI had the same problem and I updated variable to 2.1 and it works now (also updated entity api to 1.0).
Comment #139
trong.nguyen.tcec CreditAttribution: trong.nguyen.tcec commentedThis path works correctly.
Thanks to whitingx
Comment #140
alarcombe CreditAttribution: alarcombe commentedFurther 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.
Comment #141
Kaz de Groot CreditAttribution: Kaz de Groot commentedFrom 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.
Comment #142
lpeabody CreditAttribution: lpeabody commentedI solved the problem by boosting the max packet size in MySQL from 1MB to 16MB.
Comment #143
flinth CreditAttribution: flinth commentedThanks 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 !
Comment #144
carsonblack CreditAttribution: carsonblack commentedI 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.
Comment #145
kirksievers CreditAttribution: kirksievers commentedThis did not work for me :(
Comment #146
mastermindg CreditAttribution: mastermindg commentedI 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.
Comment #147
Andy Inman CreditAttribution: Andy Inman commentedI'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.
Comment #148
Andy Inman CreditAttribution: Andy Inman commentedMetatags 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.
Comment #149
Summit CreditAttribution: Summit commentedHi, #47 and therefore patch #140 worked great for me!
greetings, Martijn
Comment #150
skoehn180 CreditAttribution: skoehn180 commentedI 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.
Comment #151
KuroNeko CreditAttribution: KuroNeko commented#14 solved it for me.
Comment #152
ram4nd CreditAttribution: ram4nd commentedPatch #140 worked for me!
Comment #153
harings_rob CreditAttribution: harings_rob commented#140 confirmed for me to. Should be added to the next release.
Comment #154
JuliaKoelsch CreditAttribution: JuliaKoelsch commentedI 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.
Comment #155
kgalal CreditAttribution: kgalal commentedI 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.
Comment #156
cgdrupalkwk CreditAttribution: cgdrupalkwk commented#140 worked for me! Thanks for the fix!
Comment #157
vgalindus CreditAttribution: vgalindus commentedHi all after some digging it seems to be definetly related to max_allowed_packet size in mysql. http://dev.mysql.com/doc/refman/5.0/en/packet-too-large.html
Comment #158
Johan Groenewald CreditAttribution: Johan Groenewald commentedThis 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. :-)
Comment #159
k_ankur CreditAttribution: k_ankur commentedSame as kgalal (#155). The root cause was SimpleHTMLDom API module. Disabling Theme Developer and SimpleHTMLDom API did the trick for me.
Comment #160
hansrossel CreditAttribution: hansrossel commentedPatch #140 works for me
Comment #161
nfavrod CreditAttribution: nfavrod commentedHad same problems: solved without patches but with : https://drupal.org/project/token_tweaks
Thanks for https://drupal.org/node/1267966#comment-7321626 and https://drupal.org/node/1800562#comment-6859344 that helped me to find a way throught :-)
Comment #162
jason.fisher CreditAttribution: jason.fisher commented#140 worked here with the latest -dev.
Comment #163
ace11 CreditAttribution: ace11 commented#161 worked for me. Downloaded Token Tweaks and set limit to 2.
Comment #164
JadH CreditAttribution: JadH commented#140 worked for me
Comment #165
Road Runner CreditAttribution: Road Runner commentedImagine 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.
Comment #165.0
Road Runner CreditAttribution: Road Runner commentedBetter summary
Comment #166
FiNeX CreditAttribution: FiNeX commentedI 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?
Comment #167
FiNeX CreditAttribution: FiNeX commentedMoreover url aliases are not created even if now the pattern settings are visible.
Comment #168
mxhI 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.
Comment #169
zmove CreditAttribution: zmove commented#140 resolved the problem on the latest dev release of pathauto. It would be nice to see this commited.
Comment #170
elantion CreditAttribution: elantion commented#140 work like a charm
Comment #171
leymannxOnly 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.
Comment #172
aprice42 CreditAttribution: aprice42 commentedThe patch in #140 worked for me as well. FWIW, I didn't have entity token enabled and the problem still existed.
Comment #173
DamienMcKennaSorry, 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.
Comment #174
charlus CreditAttribution: charlus commented#150 solved it for me. Installing token_tweaks without changing settings works well.
Comment #175
jberube CreditAttribution: jberube commentedI 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.Comment #176
WillowDigit CreditAttribution: WillowDigit commentedAs 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.
Comment #177
Anonymous (not verified) CreditAttribution: Anonymous commented#140 worked for me with 7.x-1.2 version
Comment #178
MustangGB CreditAttribution: MustangGB commented#140 fixed both tabs over here.
Comment #179
Dig1 CreditAttribution: Dig1 commentedYes 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 situation...it 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.
Comment #180
darrylmabini CreditAttribution: darrylmabini commentedI think this is caused by the modules that implements hook_boot() with drupal_alter() module_invoke_all() module_invoke() inside.
Comment #181
vipzhicheng CreditAttribution: vipzhicheng commentedThe patch #140 do not actually fix the bug.
Comment #182
Alex.Gaft CreditAttribution: Alex.Gaft commentedNothing had helped me - I have the page with text, but replacement patterns don't open...
Comment #183
vipzhicheng CreditAttribution: vipzhicheng commentedAs 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.
Comment #184
mttjn CreditAttribution: mttjn commentedPatch at #140 worked for me. Version 7.x-1.2
Comment #185
Turek CreditAttribution: Turek commented#140 did the trick for me!
Thanks.
Comment #186
ProYoga.NL CreditAttribution: ProYoga.NL commented#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']"
Comment #187
Charles BelovHappening 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.
Comment #188
botanic_spark CreditAttribution: botanic_spark commentedI can confirm that #140 worked for me.
Comment #189
nvl.sateesh CreditAttribution: nvl.sateesh commentedI 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.
CAUSES PROBLEM:
FIXES PROBLEM:
Comment #190
Dave Reid@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.
Comment #191
ah_ma81 CreditAttribution: ah_ma81 commented#183 worked good for me
Comment #192
imperator_99 CreditAttribution: imperator_99 commentedI 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.
Comment #193
bacchus101 CreditAttribution: bacchus101 commentedI also took the #47 path and it worked which is good enough for the time being.
Comment #194
gianfrasoft CreditAttribution: gianfrasoft commented#161 solved my situation: I installed Token tweaks and set token limit to 2.
Thank you @nfavrod !
Comment #195
Håvard CreditAttribution: Håvard commentedToken Tweaks with tree limit set to 2 finally fixed the issue for me too :)
Comment #196
thoughtcat CreditAttribution: thoughtcat commentedToken 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.
Comment #197
Håvard CreditAttribution: Håvard commented@thoughtcat
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.
Comment #198
vipzhicheng CreditAttribution: vipzhicheng commentedWhatever please try #183's workaround.
Comment #199
flyke CreditAttribution: flyke commentedMy 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 https://www.drupal.org/sandbox/dman/2209055 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.
Comment #200
crutch CreditAttribution: crutch commentedI 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.
Comment #201
mxhWell that's the main purpose of this module: providing a UI to define URL alias patterns.
Of course there are some alternatives, for example:
Comment #202
Charles BelovComment #203
Charles BelovMy apologies, pasted into wrong issue.
Comment #204
Charles BelovCruft removed
Comment #205
klonoslinkifying a couple of things and placing the screenshot inline.
Comment #206
klonos...sorry. Stuck by #2157113: The "insert/edit image" BUeditor button still pre-fills the file url as http://drupal.org/files/
Comment #207
Chris Charlton#140 worked for me. :)
Comment #208
NanaD.Aoyagi CreditAttribution: NanaD.Aoyagi commentedPatch works!
Comment #209
Liam MorlandThis is the patch from #140 with coding standards problems fixed. No functional difference.
Comment #210
Dave ReidI 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.
Comment #211
quicksketchRan 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.
Comment #212
NitebreedI can confirm the patch in #211 works!
Comment #213
Anonymous (not verified) CreditAttribution: Anonymous commented+1 confirming the patch in #211 works. THANK YOU!!!!
Comment #214
alex.skrypnyk+1 for #211 RTBC. Please commit.
Comment #215
ladybug_3777 CreditAttribution: ladybug_3777 commentedMy 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\database.inc:2171
Stack trace:
#0 MY_DRUPAL_ROOT\includes\database\database.inc(2171): PDOStatement->execute(Array)
#1 MY_DRUPAL_ROOT\includes\database\database.inc(683): DatabaseStatementBase->execute(Array, Array)
#2 MY_DRUPAL_ROOT\includes\database\database.inc(2350): DatabaseConnection->query('SELECT expire, ...', Array, Array)
#3 MY_DRUPAL_ROOT\includes\lock.inc(167): db_query('SELECT expire, ...', Array)
#4 MY_DRUPAL_ROOT\includes\lock.inc(146): lock_may_be_available('theme_registry:...')
#5 MY_DRUPAL_ROOT\includes\theme.inc(449): lock_acquire('theme_registry:...')
#6 MY_DRUPAL_ROOT\includes\bootstrap.inc(455): ThemeRegistry->set(Array)
#7 [internal function]: DrupalCacheArray->__destruct()
#8 {main}
thrown in MY_DRUPAL_ROOT\includes\database\database.inc 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 pathauto.pathauto.inc
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?
Comment #216
leewoodman CreditAttribution: leewoodman commentedi was seeing this issue with 128M allocated in PHP.ini...changing this up to the same as my live environments 512M fixed it.
Comment #217
crutch CreditAttribution: crutch commentedIncrease 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.
Comment #218
FluxSauce CreditAttribution: FluxSauce commentedBackported #211 (thanks, Nate) to apply against pathauto 7.x-1.2.
Comment #220
FluxSauce CreditAttribution: FluxSauce commentedNot exactly, bot.
Comment #221
ladybug_3777 CreditAttribution: ladybug_3777 commentedLooks 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:
https://www.drupal.org/node/1940710#comment-9809875
Comment #222
kenorb CreditAttribution: kenorb commentedComment #223
stefanos.petrakis@gmail.comThis 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
Comment #224
webadpro CreditAttribution: webadpro commentedHello 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.
Cheers
Comment #225
AnybodyConfirming that the issue still exists. I'm currently running into this problem.
Comment #226
Anybody#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.
Comment #227
ann b CreditAttribution: ann b commented@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.
Comment #228
kurtfoster CreditAttribution: kurtfoster commentedI 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.
Comment #229
AnybodyWithout (any) related changes the patterns are now showing up on my website again. It's a bit scary ;)
Comment #230
sundersingh CreditAttribution: sundersingh commentedThe 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.
Comment #231
DamienMcKenna@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.
Comment #232
squarecandy CreditAttribution: squarecandy commentedyeah, 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.
Comment #233
AGriffin CreditAttribution: AGriffin commentedFor me turning off Clean Pagination fixed it.
Comment #234
Dave ReidHrm, this would cause a regression if I were to want to do this: $data = module_invoke('node', 'pathauto'). We need a different solution.
Comment #235
Zapa Utu CreditAttribution: Zapa Utu commentedHi 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:
** 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.
Comment #236
stefan.r CreditAttribution: stefan.r commentedThe 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.Comment #237
stefan.r CreditAttribution: stefan.r commentedOther 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.
Comment #238
stefan.r CreditAttribution: stefan.r commentedComment #239
Zapa Utu CreditAttribution: Zapa Utu commentedThanks 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. ;)
Comment #240
gomes.mr CreditAttribution: gomes.mr commented"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!
Comment #241
rbns CreditAttribution: rbns commentedHi.
"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.
Comment #242
Tregonia CreditAttribution: Tregonia as a volunteer and at Parallax Information Technology commentedThe 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
EDIT:
The patch in #238 did work for me
Comment #243
interdruper CreditAttribution: interdruper commentedAfter unsuccessful trials with Token Tweaks, finally #238 fixed the issue for me. Thx!
Comment #244
bsuttis CreditAttribution: bsuttis commentedConfirming 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?
Comment #245
cbeier CreditAttribution: cbeier commentedI 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.
Comment #246
cbeier CreditAttribution: cbeier commentedI have combined the patch from #140 and #328, because these two patches resolves the issue for me.
Comment #247
jucedogi CreditAttribution: jucedogi commented@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.
Comment #248
cbeier CreditAttribution: cbeier commented@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.
Comment #249
Dave ReidPlease give the latest 7.x-1.3 release a try. We got rid of the hook_module_implements_alter() use in Pathauto.
Comment #250
mxwright CreditAttribution: mxwright as a volunteer commented@Dave Reid the 7.x-1.3 release seems to do the trick for me. Thanks!
Comment #251
sumthief CreditAttribution: sumthief as a volunteer and at DrupalJedi commented@Dave Reid the 7.x-1.3 release works for me too. Thanks.
Comment #252
NitebreedComment #253
crutch CreditAttribution: crutch commentedI have a small tear. Works :)
Comment #254
joaomachado CreditAttribution: joaomachado commentedUSER PATHS
Browse available tokens = works
TAXONOMY TERM PATHS
Browse available tokens = works
CONTENT PATHS
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...
Comment #255
sumthief CreditAttribution: sumthief as a volunteer and at DrupalJedi commented@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.
Comment #256
joaomachado CreditAttribution: joaomachado commented@Shlyapkin Should downgrade to 7.x-1.2 and apply the patch?
Comment #257
sumthief CreditAttribution: sumthief as a volunteer and at DrupalJedi commented@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.
Comment #258
AndreyEfremov CreditAttribution: AndreyEfremov commentedDownloaded 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/demo.a-efremov.ru/docs/sites/all/modules/pathauto/pathauto.module).
7.х-1.2
works well
Comment #259
sumthief CreditAttribution: sumthief as a volunteer and at DrupalJedi commentedHi, @AndreyEfremov. Do you execute updates?
Comment #260
joaomachado CreditAttribution: joaomachado commented@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.
Joao
Comment #261
AndreyEfremov CreditAttribution: AndreyEfremov commented@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
Comment #262
AndreyEfremov CreditAttribution: AndreyEfremov commented@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.
Comment #263
joaomachado CreditAttribution: joaomachado commented@AndreyEfremov what is the table name?
Comment #264
Leeteq CreditAttribution: Leeteq commented@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"
Comment #265
joaomachado CreditAttribution: joaomachado commentedI am a little confused... I cannot find any table called "pathauto_state" using phpMyAdmin. DO I have to created manually if so how?
Comment #266
kenorb CreditAttribution: kenorb commented@joaomachado, @AndreyEfremov: Follow this issue instead: #2591453: Table 'oursite.com.pathauto_state' doesn't exist (just run your site updates). This one is different and already solved as part of the patch file.
Comment #267
Leeteq CreditAttribution: Leeteq commentedFrom 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.
Comment #268
crutch CreditAttribution: crutch commentedMy 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.
Comment #269
joaomachado CreditAttribution: joaomachado commentedOK - 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
Comment #270
cesarmiquel CreditAttribution: cesarmiquel as a volunteer and at easytechgreen commentedWe 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.
Comment #271
stefan.r CreditAttribution: stefan.r commented@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.
Comment #272
cesarmiquel CreditAttribution: cesarmiquel as a volunteer and at easytechgreen commented@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.
Comment #273
hollyfox CreditAttribution: hollyfox commentedCheck 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.
Comment #274
Dave ReidSeveral people have reported that either using the latest 7.x-1.3 release, or the latest core 7.40 resolves this. As such, I'm marking as fixed.
Comment #276
Cracu CreditAttribution: Cracu commentedFor those that are still having this issue, it seems that source for this problem is token module, which tries to generate that token tree, for patterns. For some reason that tree is huge for some sites: 24MB.
By updating pathauto to latest version you will be able to enter the page, because token tree is not loaded directly. It is visible via dialog, so most probably you will have a 500 response code when you'll try to open the list of tokens for content. (those for taxonomy are working fine)
Until maintainers of token module will provide an update, the easiest fix from my point of view is patching token module, by replacing
define('TOKEN_MAX_DEPTH', 9);
with
define('TOKEN_MAX_DEPTH', 2);
in token.module file or you could use even 1 for that constant, it is used only for that token tree generation and you'll have generic tokens even with lowest value, while the page load and pdo exception will be gone.
Alternative for patch might be the installation of some contrib modules that could help with this issue, like: "Token tweaks", currently not a supported module by security team.
Comment #277
position2 CreditAttribution: position2 commentedHi,
We are facing problem in Pathauto after we updated the core to 8.5.1. In the multilanguage site, the URL is going to the default (English) site instead of to the appropriate site. The URL taking the full path instead of relative path. Also, for the new content, it is adding the node id in the URL. Please help us to fix this.
https://de.thalesesecurity.com/about-us/newsroom
Thank you,
Perumal
Comment #278
Bahson CreditAttribution: Bahson commentedHad the same issue...on 'admin/config/search/path/patterns' [Add pathauto pattern] action link was not being rendered....uninstalling webprofiler solved that...