New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
dnaber-de opened this Issue Apr 8, 2016 · 2 comments

Comments

Projects
None yet
2 participants
@dnaber-de

dnaber-de commented Apr 8, 2016

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

This comment has been minimized.

Show comment
Hide comment
@antecedent

antecedent Apr 8, 2016

Owner
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!

Owner

antecedent commented Apr 8, 2016

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 antecedent added this to the 1.4.3 milestone Apr 8, 2016

@antecedent antecedent self-assigned this Apr 8, 2016

@dnaber-de

This comment has been minimized.

Show comment
Hide comment
@dnaber-de

dnaber-de Apr 20, 2016

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 commented Apr 20, 2016

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment