Hi,
After an upgrade to PHP5.3 on Omega8 I got the following error on a live website:
Fatal error: Call to undefined function list_themes() in /data/disk/o4843680964/static/heritage-1.0/sites/all/modules/contrib/xautoload/lib/DrupalExtensionSystem.php on line 10
I solved the issue by manually loading theme.inc at the top of xautoload.module:
require_once DRUPAL_ROOT . '/includes/theme.inc';
Does this seems a reliable solution to you? Is it possible to include this in the module?
cheers,
Thomas
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | xautoload-7.x-2.x-check-function_exists-on-list_themes-1838194-3.patch | 443 bytes | donquixote |
Comments
Comment #1
donquixote commentedInteresting.
XAutoload tries to be clever when deciding what to do at which time.
E.g. it tries to have the boot modules already available, even while the other modules are still loading.
In case of themes, this apparently is not implemented correctly. I should add a function_exists(), or some other way to make sure that themes are available when I call list_themes().
Which module was it that tries to load a class at this time?
If we figure this out quickly, I might produce a hotfix in the next days.
Comment #2
donquixote commentedAlso, consider the following situation:
1. Bootrap phase, no themes available, class_exists() returns false.
2. xautoload remembers that the class does not exist, or even that a theme with this name does not exist.
3. Themes are loaded.
4. Another time you try class_exists(), and this time the class should exist, but xautoload still remembers that it originally failed.
So...
- whenever new namespaces are added, xautoload cache needs to "forget" any previous lookups within those namespaces.
- whenever the state of drupal changes, so that new modules or themes become available, xautoload needs to forget previous lookups on those modules and themes.
This is all possible, but I need to think more about it.
Comment #3
donquixote commentedHere is a minimal patch.
In the only case where the patch makes a difference, it would crash otherwise.
So it should not have any side effects.
Can you test?
We probably need to do more thinking here, but as a hotfix this seems reasonable.
(hotfix = to make a new stable with this fix included within the next days)
Comment #4
Anonymous (not verified) commentedHi donquixote,
Thank you for your amazingly quick reply. I'll check it today and let you know.
Comment #5
Anonymous (not verified) commentedHi donquixote,
Your patch seems to work. You can check the working site at http://dev.xautoload.o4843680964.v242a.ams.host8.biz/
cheers,
Thomas
Comment #6
donquixote commentedThanks for testing! And nice website :)
What do you use xautoload for? Module dependencies? External libraries?
What is it that wants to load a class before themes are set up?
The more information I have about use cases, the better I can make this module :)
Comment #7
donquixote commentedHotfix release 7.x-2.7 is out!
http://drupal.org/node/1839398
http://drupalcode.org/project/xautoload.git/commitdiff/c89e7684c641f5a66...
Follow-up work: #1839420: Timing on bootstrap
Comment #8
Anonymous (not verified) commentedThanks for the hotfix!
We currently use X Autoload for the module Menupoly. It integrates very well with Crumbs :-)
I'm not very sure what wants to load classes before the themes. Perhaps it's a caching algorythm at Omega8 that makes this happen, but I'm just guessing in the dark. They use PHP-FPM 5.3.17 with APC, Memcached, UploadProgress, ImageMagick, Suhosin and ionCube, combined with Nginx. Could that be the cause?
EDIT: Btw, the fatal error didn't occur on our development server. To compare, we use Apache 2.2 + PHP-FPM 5.3.10-1ubuntu3.4 with Suhosin-Patch over FastCGI, combined with some APC and Memcached.