Fatal error: Call to undefined function patchwork\callrerouting\deployqueue()

[dnaber-de]

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?

[antecedent]

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!

[antecedent]

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!

[dnaber-de]

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!

[dnaber-de]

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!