Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Fatal error: require_once() [function.require]: Failed opening required ' ' (include_path='.:/usr/share/php:/usr/share/pear') in sites/all/modules/ctools/includes/plugins.inc on line 469
Comments
Comment #1
merlinofchaos CreditAttribution: merlinofchaos commentedAn error with no context is of no value. In general, module maintainers are inclined to put in as much effort solving an issue as the submitter is in describing the issue.
Please read the guidelines on how to post good issues.
Comment #2
Prague man CreditAttribution: Prague man commentedProblem is here:
require_once DRUPAL_ROOT . '/' . $file->uri;
solution for me:
Comment #3
merlinofchaos CreditAttribution: merlinofchaos commentedThat is hardly a solution.
And you still didn't give any context. What were you doing? What modules? What plugins?
That particular line of code is including a plugin file. It could be anything.
Comment #4
esmerel CreditAttribution: esmerel commentedComment #5
glekli CreditAttribution: glekli commentedI am facing a similar issue. The actual error message is as follows.
PHP Fatal error: require_once(): Failed opening required '/var/local/www/test.com/' (include_path='.:/usr/share/pear:/usr/share/php') in /var/local/www/test.com/sites/all/modules/contrib/ctools/includes/plugins.inc on line 475
Note that there is no file name at the end of the path that it was trying to include. It seems like $file->uri is empty in that line. A clear caches solves the issue (not on the UI, of course, because no pages load after this occurs), which could mean that incorrect file data gets cached. However, it reoccurs after a while.
I cannot reproduce it on purpose, it just happens randomly, but still it might be worthwhile to check under what conditions could $file->uri be empty. I'll be happy to post more info if you tell me what I should check.
Drupal 7.20
Ctools 7.x-1.2
Comment #6
ianthomas_ukGergely Lekli: Are you still having this problem? Have you been able to reliably reproduce it? A similar issue has been seen when using maintenance mode at https://drupal.org/node/1949400 so this may be a duplicate of that. I'm about to post a fix to the 'not on the UI' part at https://drupal.org/node/1775612
I'll mark as postponed until we know how to reproduce this.
Comment #7
JKingsnorth CreditAttribution: JKingsnorth commentedNo further information posted for a long time. Please reopen against the latest version if it is still a problem.
Comment #8
karolus CreditAttribution: karolus commentedI came across this issue today after doing module updates to a site. To get around it, I used Prague Man's (#2) solution to the file, then cleared the caches, and reverted the file back to the original. So far, no more issues, but will check on this.
It seems to be an intermittent issue, since I upgraded another site earlier today with no issues.
If it's any help, both of the sites are running Drupal 7.36
Comment #9
pwiniacki CreditAttribution: pwiniacki commentedrelated: https://www.drupal.org/node/1775612
Comment #10
Rhane CreditAttribution: Rhane commentedI'm just going to mention here some recent problems I had with sites that were hosted on my server. I kept getting all sorts of ctools issues with two sites suddenly, one drupal 6 and the other a drupal 7 site. It turned out to be due to memcache being enabled on both sites - and I hadn't fully read the README section in the memcache module about prefixing. In case some people are dealing with ctools_plugins_load_includes errors - that might be another box to check off in troubleshooting. It caused very similar issues as I've seen people posting on this niche issue -- $file->url being undefined, etc. Lost days on it, but finally resolved it.
TL;DR: If multiple Drupal installs are on a single memcache instance, view the prefixing section within the module memcache/README.txt -- it caused me very similar ctools issues as others have posted.