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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

bbinkovitz’s picture

Issue summary: View changes
halloffame’s picture

+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

Martin Mayer’s picture

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

xurizaemon’s picture

Status: Active » Needs review
FileSize
609 bytes

Try this patch with current 7.x-1.x-dev?

dfletcher’s picture

xurizaemon's patch from #4 solved this for me after changing info file and clearing cache the issue is gone.

TommyK’s picture

Status: Needs review » Reviewed & tested by the community

I can confirm the patch solves the issue after applying and clearing caches.

greg.harvey’s picture

fwiw, patch did NOT work for us. Reverted to previous version.

chris.jichen’s picture

The patch did NOT work for me neither. Anyone has a solution?

Thanks

xurizaemon’s picture

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

xurizaemon’s picture

Status: Reviewed & tested by the community » Needs work

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

kroose’s picture

It looks like it work after the cache clear. Thanks for the patch!

greatmatter’s picture

FileSize
1.14 KB

We *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...

realityloop’s picture

Status: Needs work » Reviewed & tested by the community

#12 worked for me

timodwhit’s picture

#12 worked for me as well. Was having the same issue.

geoff’s picture

#12 worked for me also

Interestingly, this manifested itself by causing the "tokens" to fail - rather than a WSOD - but exactly the same cause.

PJnes’s picture

Just 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

PJnes’s picture

FileSize
667 bytes
PJnes’s picture

FileSize
669 bytes

Another reroll to fix some coding standards.

Anonymous’s picture

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

bojanz’s picture

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

Anonymous’s picture

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

bojanz’s picture

Status: Reviewed & tested by the community » Fixed

I couldn't reproduce the crash, so I added a comment and committed the patch. Thanks, everyone.

  • bojanz committed fdc144b on 7.x-1.x authored by greatmatter
    Issue #2181001 by PJnes, xurizaemon, greatmatter: WSOD: Call to...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.