Recent updates breaks our sites with a fatal error. The ctools/includes/plugins.inc is trying to include a plugin file that got removed with the latest oembed update (file plugins/export_ui/oembed_preset.inc)
ctools 7.x-1.2
oembed 7.x-0.1.beta3
[Wed Sep 05 15:49:36 2012] [error] [client 152.23.170.31] PHP Fatal error: require_once(): Failed opening required '/Library/WebServer/Documents/drupal7/sites/all/modules/oembed/plugins/export_ui/oembed_preset.inc' (include_path='.:/php/includes:/usr/lib/php/Zend/library') in /Library/WebServer/Documents/drupal7/sites/all/modules/ctools/includes/plugins.inc on line 475
| Comment | File | Size | Author |
|---|---|---|---|
| #15 | ctoots_file_loading_error.txt | 12.68 MB | pwaterz |
| #3 | plugin-load-use-include-1775612-3.patch | 603 bytes | bartram |
| #2 | 1775612-calling-missing-file-2.patch | 1.26 KB | ianthomas_uk |
Comments
Comment #1
merlinofchaos commentedThis should be fixed with a cache clear.
Comment #2
ianthomas_ukA cache clear would fix this, but if you're getting a white screen of death then you may not be able to clear your cache, even using Drush.
If we throw an exception instead of letting PHP trigger a fatal error then this will be caught by the default exception handler and you'll be able to clear the cache with Drush. It also gives other modules the chance to handle this error themselves (e.g. hiding the block that the ctools plugin is used in, but showing the rest of the page).
I've attached an example patch of how this could work, as I didn't want to waste time on a complete patch if it would not be accepted. Worth noting is that this patch only catches one of at least two instances of require_once that we'd want to handle, and it uses PHP's generic Exception class rather than a more specific exception. I'd be happy to make these changes if such a patch would be accepted (any suggestions for what Exception should be thrown?).
Drupal 8 core plugins already throw exceptions, but the messages are being improved in https://drupal.org/node/1897762 and https://drupal.org/node/1846070
Comment #3
bartram commentedThis issue also occurs for me when switching between branches on other modules, where one branch has defined a plugin, and the other branch is a few commits behind. When switch back to the old branch, I get the WSOD, and I am unable to clear my cache, even with Drush.
Is there a reason for using 'require_once' instead of 'include_once'? It's not the end of the world if the file doesn't exist, but 'require_once' acts like it is. The function name ('ctools_plugin_load_includes') suggests that the module should use 'include_once'.
Here's a patch. If the file goes missing, I can still clear my cache, and ignore any errors that show up.
Comment #4
john bickar commentedI ran into this when moving module files around (from a subdirectory in "profiles" into sites/all/modules).
Truncating the cache table manually allowed me to clear the cache with drush:
Comment #5
damienmckennaComment #7
pwiniacki commentedgot this when updating commerce _shipping module from version x.1 to version x.2:
So just clearing cache fix this issue?
EDIT: related - https://www.drupal.org/node/1332476
Comment #8
damienmckenna@pwiniacki: Please heck with the commerce_shipping module, there should be some documentation on how to update from one version to another.
Comment #9
pwiniacki commented@DamienMcKenna thanks, I already did before making any post here. On my localhost everything is fine, on live I get error above.
EDIT: I did try to update my live site again - no error this time. But error appear on my localhost test page :) So I guess this will be very hard to target - random error :P
Comment #10
damienmckenna@pwiniacki: I mention that because your issue has nothing to do with this issue in CTools, you really should open a new "support request" issue for Commerce Shipping.
Comment #11
pwiniacki commented@DamienMcKenna ok got it, thanks for you support, every help is appreciated.
Anyway If somebody got similar problem - when you disable rule Commerce Shipping Example plugin
Machine name: commerce_shipping_example_plugin
your chance to upgrade without error are higher but this error can still randomly appear.
Comment #12
pwaterz commentedI have ran into the same issue multiple times when deploying code updates. We use Capistrano for deploying code and it change the directory structure on every deploy. I run into a php error every time when it tries to load the plugins. Also running drush cc all does not fix it for me. I have to manually clear the cache table independently to get this to go away. It seems as if there is a race condition happening when a cache clear happens and when ctools loads plugins.
Comment #13
pwaterz commentedHere is a backtrace I get when trying to clear the cache via drush
Comment #14
damienmckenna@pwaterz: if you could include the arguments from the first few items we might be able to get an idea of what plugin is misbehaving.
Comment #15
pwaterz commentedFull backtrace
Comment #16
pwaterz commentedThis looks like it's actually a bug with view. Cache clear is calling menu rebuild, which then view is altering the menu callbacks and loading plugins. When really the plugin cache should have been cleared before views tried to load the plugins.
Comment #17
pwaterz commentedI should note this is happening even when I try to run
drush php-eval 'cache_clear_all("*", "cache", TRUE)'I think is happening because the menu cache got cleared and now during boostrap it is attempting to rebuild the menu cache, but it can't because views is accessing a stale ctools plugin cache.
Comment #18
pwaterz commentedI think patch #3 is the way to go
Comment #19
extraextraspezial commentedpatch #3 solved it for me too!
Comment #20
dysrama commented+1 for patch in #3, this has been giving me issues forever on different test sites when switching between branches.
Comment #21
renrhaf+1 for patch in #3
While deploying code with a lots of module move from /sites/all to /profiles I had an issue where I couldn't clear cache anymore. With this patch, I could clear caches without being struck with a :
drush php-eval 'cache_clear_all("*", "cache", TRUE)'
Then all other commands were working again.
Comment #22
renrhafComment #23
nicoloye commentedSame here, I confirm that patch #3 does the work !
Comment #24
nplowman commentedIf you do not want to patch the file, you can also resolve the issue by following these steps:
1) Run this command against the database (assuming you are using mysql):
delete from cache where cid like 'ctools_plugin_files%';2) Clear the cache using drush
drush cc allComment #25
jimmyko commentedI confirm the patch #3 does the work too. Clear cache can't fix my issue, the plugins files data is still cached after that.
Comment #26
a.milkovsky+100 for the #3. I am so happy that this annoying issue could be resolved :)
Comment #28
japerryCommitted.
Comment #30
anthonyroundtree commentedDid this patch ever make it into the latest version of ctools? I was using the 1.12 version of this and plugins.inc did not have this on line 477.
Comment #31
mayurjadhav commentedpatch #3 solved it for me. And It's there in the latest version of the module.