Fatal error: Call to undefined function patchwork\callrerouting\deployqueue()
Opened this issue · 2 comments
Hi,
I'm using patchwork for mocking functions in unit tests via https://packagist.org/packages/brain/monkey . The package I'm working on is a wordpress-plugin
. My developer system is a Ubuntu 14.04 with Apache 2.4 and PHP 5.5 with mod-php.
The composer.json define these requirements:
"require": {
"php": ">=5.3.0"
},
"autoload": {
"psr-4": {
"ShortcodeReplace\\": "src/"
}
},
"autoload-dev": {
"psr-4": {
"ShortcodeReplace\\Test\\Helper\\": "tests/Helper/"
}
},
"require-dev": {
"brain/monkey": "~1.2"
}
The PHPUnit test runner uses vendor/autoload.php
as bootstrap file.
The actuall installed versions are
- patchwork 1.4.0
- brain/monkey 1.2.1
- hamcrest-php 1.2.2
- mockery 0.9.4
I don't use any patchwork.json
.
All tests run without problems as expected in the PHPUnit CLI runner. Now when I'm starting my »application« by just making a HTTP request to the Web-Frontend (http://my-project.dev/wp-admin
) I sometimes see this error message:
Fatal error: Call to undefined function patchwork\callrerouting\deployqueue() in /var/www/…/wp-admin/admin-header.php on line 2
For what I see, this comes as both processes (test and web frontend) share the same composer autoloader. Composers autoload_files.php
looks like this at this moment:
return array(
$vendorDir . '/hamcrest/hamcrest-php/hamcrest/Hamcrest.php',
$vendorDir . '/antecedent/patchwork/src/QuietBootstrap.php',
);
So to overcome this issue, I just deleted the complete vendor/
directory and run composer with the --no-dev
option:
$ composer install --no-dev
At this moment there were no patchwork sources at all. But the error still occurred. Only after I restarted apache, the error was gone.
I know, that patchwork is not meant to use in production and therefore I have to make sure, it never goes into the autoloader on any production system. But I want to understand what exactly goes on here. Is it the PHP OPcache, that caches the streams of patchwork? How can I make sure that I can switch between testing-processes and web frontend-processes on a developing system without running into these caching issues?
register_shutdown_function('opcache_reset');
This should help you test the cache hypothesis, which I think is very likely to be true. I also think it would have taken me quite a while to arrive at such hypothesis. I can only say I applaud your reasoning!
register_shutdown_function('opcache_reset');
This should help you test the cache hypothesis, which I think is very likely to be true. I also think it would have taken me quite a while to arrive at such hypothesis. I can only say I applaud your reasoning!
I'll keep that in mind. I still didn't found a way to reproduce it. But nice to see, the hypothesis is addressed in these commits. Thanks!