search

trilbymedia / grav-plugin-git-sync

Collaboratively Synchronize your Grav `user` folder hosted on GitHub, BitBucket or GitLab
Apache License 2.0
239 stars 57 forks source link

When upgrading to PHP 8.0, git-sync throws PHP Fatal error: Invalid opcode 117/2/0 #187

Closed GwynethLlewelyn closed 3 years ago

GwynethLlewelyn commented 3 years ago

Hi all!

I've been busily upgrading many of my sites to PHP 8.0, and, having learned that Grav 1.7 fully supports PHP 8.0, I did the upgrade without thinking twice.

It seems, however, that git-sync has some trouble:

PHP Fatal error:  Invalid opcode 117/2/0. in <GRAV_PATH>/user/plugins/git-sync/vendor/defuse/php-encryption/src/Core.php on line 412" while reading response header from upstream, client: <some IP address here>, server: <my server address here>, request: "POST /admin/plugins/git-sync HTTP/2.0",

Now, as far as I could search on Google or Bing about this particular issue, it seems to be common when upgrading PHP versions — especially when one's configuration uses opcache, APC/APCu, Memcached, or whatever fancy caching methods. I use them all, and even run nginx with Google's pagespeed library on top of everything — and, well, Cloudflare...

In other words: because the compiled PHP scripts may be slightly different between PHP versions (especially major versions) — some opcodes having been made obsolete and dropped, others added, etc. — it is often likely for those levels of caching still contain some 'old' opcodes, thus the error. Strangely enough, in my case, they seem to persist not only when restarting nginx and php8.0-fpm (the latter accessed via a Unix socket), but even after a reboot — so something is maintaining persistence (I haven't tracked it down) at some point.

Note that this is not a 'bug' or 'error' of git-sync per se. I have used the grav CLI to manually delete whatever caches grav is using (including the so-called 'compiled' directory); but I'm afraid that this will not store low-level opcodes, and, thus, these won't be cached.

This issue naturally affects other platforms as well. Here are some suggestions on how to force the opcode cache to be cleared in WordPress under Apache. Naturally enough, such deep-level cache flushing techniques ought to get rid of whatever is persisting the cache.

I wonder if anyone has come across this issue and has tweaked something in git-sync so that it flushes all opcode caches whenever something gets upgraded.

Thanks in advance!

w00fz commented 3 years ago

Hi @GwynethLlewelyn, i haven’t tested php8.0 with gitsync yet but I’m glad to see someone is!

Usually that’s what I do myself, restart php/apache or nginx and that takes care of caches holding on too tightly.

One thing you could try is to go in <GRAV_PATH>/user/plugins/git-sync, remove (backup) the vendor folder and then run a composer install —no-dev. See if that helps.

GwynethLlewelyn commented 3 years ago

Whoops I'm so sorry; I had totally forgotten that I had opened this issue...!

Aye, it 'fixed by itself' — I don't remember doing anything, but there were Grav upgrades, OS upgrades, PHP upgrades, a few reboots... one of those must have fixed whatever the issue was, since I haven't seen it showing up ever again!

w00fz commented 3 years ago

No worries I figured as much, I was just doing some house cleaning with the new release out :)

Thanks for the update and glad it is sorted. 👍