We upgraded from 7.x-1.1 to 7.x-1.3 and not sure of the exact steps to reproduce yet but just wanted to throw this out here for now.
Fatal error: require_once(): Failed opening required 'profiles/publisher/modules/contrib/acquia_purge/processor/' (include_path='.:/mnt/gfs/example.acceptance/livedev/library/:/usr/share/php:/usr/share/pear') in /mnt/gfs/exampleacc/livedev/docroot/profiles/publisher/modules/contrib/acquia_purge/acquia_purge.module on line 1236
When we get to line 1236 it tries to require_once $module_path . '/' . $path;.
The first time around it is profiles/publisher/modules/contrib/acquia_purge/AcquiaPurgeService.php but the second time is profiles/publisher/modules/contrib/acquia_purge/processor/. Which AcquiaPurgeService->processors() does appear to call _acquia_purge_load("processor/") with:
public function processors() {
if (is_null($this->processors)) {
_acquia_purge_load('processor/');
$this->processors = new AcquiaPurgeProcessorsService($this);
}
return $this->processors;
}So line 1236 is just defunct because of some prior changes I think. There is a processor folder but don't think require_once can load a folder.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | acquia_purge-fatal-error-2621716-5-7.x.patch | 773 bytes | elijah lynn |
Comments
Comment #2
elijah lynnComment #3
elijah lynnNow I am thinking it is because we are using the SimpleSaml library for SSO and it does a second drupal_bootstrap() to get some Drupal variables. For some reason this second bootstrap messes stuff up. I commented out the second drupal_bootstrap(), reloaded and errors went away. Then I uncommented and errors are still gone. Not sure what happened.
Comment #4
elijah lynnNow they are back but this time with a
profiles/publisher/modules/contrib/acquia_purge/AcquiaPurgeService.phpinstead of "processor/" which leads me further. Will post back when I figure it out.Comment #5
elijah lynnAhh, I see, if you try to bootstrap in your own code the relative paths are wrong.
Here is a patch that will make this more reliable.
Our SSO server is down right now so I cannot test but I think this will fix it. It is the pattern Drupal uses to include code before a full bootstrap has been done.
Comment #6
elijah lynnComment #7
elijah lynnAlso, wondering why we don't use module_load_include() instead of
require_once $module_path . '/' . $path;. I am assuming there is a reason for it since module_load_include() is used in other parts of the module. I would like to know why though and if possible put a comment with the 'why'.Thanks
Comment #8
nielsvm commentedI'm expecting that this is working now since the rewrite of
_acquia_purge_load(). I'm considering it fixed but feel free to reopen.Comment #10
retrodans commentedThis does indeed appear to still be an issue in 7.x-1.3. Was this fixed in dev, if so, when might a new version of the module be released so we do not need to apply the suggested patch (or use a dev version of the module)?
Thanks,
Dan