I updated from a version of addressfield that did not contain addressfield_module_implements_alter(). It was working fine.
After updating, on a clean install of my site (which uses panopoly with a custom install profile, fwiw), I get a WSOD everywhere but the admin pages. The full error is:
PHP Fatal error: Call to undefined function addressfield_token_info_alter() in /Users/me/projects/mysite/www/includes/module.inc on line 1101.
When I comment out lines 45-47 of addressfield.module (which is the contents of addressfield_module_implements_alter, described as "Moves the hook_token_info_alter() implementation to the bottom so it is invoked after all modules implementing the same hook." in the comments), then the WSOD resolves and I can use my site again.
Comment | File | Size | Author |
---|---|---|---|
#18 | addressfield-2181001-18.patch | 669 bytes | PJnes |
#17 | addressfield-2181001-16.patch | 667 bytes | PJnes |
#12 | addressfield.module.patch | 1.14 KB | greatmatter |
#4 | addressfield-2181001-4.patch | 609 bytes | xurizaemon |
Comments
Comment #1
bbinkovitz CreditAttribution: bbinkovitz commentedComment #2
halloffame CreditAttribution: halloffame commented+1 to this. Only happening on my live prod server with php 5.3.X but not on my local dev at 5.2.X
Comment #3
Martin Mayer CreditAttribution: Martin Mayer commentedI updated from 7.x-1.0-beta4+5-dev (2013-Jul-11) to beta5. Now I also receive the WSOD, but only after saving a user profile or completing the checkout in the commerce store. Address field is used in the store and in the user profile. I the error log I find the following message:
Undefined index: addressfield in addressfield_module_implements_alter() (line 45 of /path_to_my_installation/sites/all/modules/addressfield/addressfield.module)
I assume this is the same problem as described in this issue, as the message also relates to line 45 of the new module version.
Undoing the module update resolves the problem.
Comment #4
xurizaemonTry this patch with current 7.x-1.x-dev?
Comment #5
dfletcher CreditAttribution: dfletcher commentedxurizaemon's patch from #4 solved this for me after changing info file and clearing cache the issue is gone.
Comment #6
TommyK CreditAttribution: TommyK commentedI can confirm the patch solves the issue after applying and clearing caches.
Comment #7
greg.harveyfwiw, patch did NOT work for us. Reverted to previous version.
Comment #8
chris.jichen CreditAttribution: chris.jichen commentedThe patch did NOT work for me neither. Anyone has a solution?
Thanks
Comment #9
xurizaemonIf the minor patch from #4 doesn't work for you, you'll need to do a bit more work to debug it. The patch is super trivial. Steps to use are -
- Apply patch
- Clear caches
If clearing cache makes it work, then you might like to update the patch to add a hook_update_N with cache_clear_all to fix that.
If clearing cache doesn't work then let us know and/or debug further (first check debug info from php logs).
Comment #10
xurizaemonActually ... since that file only contains functions, maybe we need to include the file rather than just add it to the code registry. Might want to try that instead (module_load_include from ~= line 45 of the .module).
Please update status when providing further feedback.
Comment #11
kroose CreditAttribution: kroose commentedIt looks like it work after the cache clear. Thanks for the patch!
Comment #12
greatmatter CreditAttribution: greatmatter commentedWe *suddenly* had the same problem without provocation. The patch in #4 worked after a cache-clear, however, the issue came back almost immediately (within a minute). We noticed that the WSOD error was being accompanied by a warning:
Notice: Undefined index: addressfield in addressfield_module_implements_alter() (line 45 of [...]/sites/all/modules/contrib/addressfield/addressfield.module).
Being as that we're in a time crunch, I added an isset() to the function to prevent the error--and sure enough, it did the trick. I've attached a patch.
EDIT: Sorry that this patch isn't in the actual module--I'm in a hurry...
Comment #13
realityloop#12 worked for me
Comment #14
timodwhit CreditAttribution: timodwhit commented#12 worked for me as well. Was having the same issue.
Comment #15
geoff CreditAttribution: geoff commented#12 worked for me also
Interestingly, this manifested itself by causing the "tokens" to fail - rather than a WSOD - but exactly the same cause.
Comment #16
PJnes CreditAttribution: PJnes commentedJust a reroll of the patch in #12 to apply to the module folder directly rather than the Drupal root, in case you have the module somewhere that isn't sites/all/modules/contrib
Comment #17
PJnes CreditAttribution: PJnes commentedComment #18
PJnes CreditAttribution: PJnes commentedAnother reroll to fix some coding standards.
Comment #19
Anonymous (not verified) CreditAttribution: Anonymous commentedHad this WSOD problem this morning with my site, http://TrainingCity.com. Fortunately the patch in #18 seems to be working and site is back up and running. Thanks for your hard work, PJnes!
Comment #20
bojanz CreditAttribution: bojanz commentedBefore committing this patch I'd love to understand why the issue actually appears. I've looked at 10 other modules implementing this hook (including Commerce and Entity API), and none of them have or need the isset() check.
Comment #21
Anonymous (not verified) CreditAttribution: Anonymous commentedHi bojanz: Only request is please do not release a new dev without the patch or equivalent as it definitely solved the problem (not sure why) for me.
Comment #22
bojanz CreditAttribution: bojanz commentedI couldn't reproduce the crash, so I added a comment and committed the patch. Thanks, everyone.