What are those critical errors? It kind of helps to know the details.
Thread Starter
fob
(@fob)
There was a problem with the reactivation process.
In PHP 8.3.28 the plugin could not be properly reinstalled after being updated from a Plesk Toolkit. Plesk activates the plugin, even if something does not work. Then the affected websites go down. If you deactivate the plugin that caused issues, they run fine again.
If you tried to reactivate the plugn from the backend, to see what happens and track errors messages, it simply failed. (Activation not possible.)
So I tested it again with PHP 7.4 – works. Switched to PHP 8.3.x again – works.
As it stands, I have to downgrade the PHP versions everywhere, activate the update, and then switch back to the desired PHP environment. This way it seems to work fine. 🙂
That sounds very odd! You say the update happens in Plesk itself, not WordPress?
If you have access to the PHP error logs and can find the relevant messages than I might be able to see what is going on.
Thread Starter
fob
(@fob)
It appears that in PHP 8.3, activating the updated plugin triggers an endless redirect loop, which is terminated on the server side and acknowledged with Error 500. In PHP 7.4 environments, however, the plugin could be updated without any problems and without the error:
“Core Error / AH00124: Request exceeded the limit of XXX internal redirects due to probable configuration error. Use “LimitInternalRecursion” to increase the limit if necessary. Use “LogLevel debug” to get a backtrace.”
I haven’t looked at the code to see if it might be related to one of those annoying minor PHP updates or an ill-timed (perhaps complexer) activation loop?
https://wordpress.stackexchange.com/questions/25910/uninstall-activate-deactivate-a-plugin-typical-features-how-to/25979#25979
https://developer.ww.wp.xz.cn/reference/functions/register_activation_hook/
-
This reply was modified 4 months, 3 weeks ago by
fob.
Thread Starter
fob
(@fob)
I still had one attempt left in a test environment. It appears to be a more general caching issue in a PHP-FPM environment with an upstream NGINX cache that was not updated promptly enough during the update.
It seems to be sufficient to update the plugin (with page failure error) and simply restart PHP 8.3.x once immediately after the update.
I suspect that moving the file ‘redirection-version.php’, which is included via ‘require_once’, to a subdirectory led to the incorrect search for this file.
PHP message: PHP Warning: require_once(/…/wp-content/plugins/redirection/redirection-version.php): Failed to open stream: No such file or directory in /…/wp-content/plugins/redirection/redirection.php on line 45
PHP Fatal error: Uncaught Error: Failed opening required “/../wp-content/plugins/redirection/redirection-version.php”
Do you think it might help to first define the paths and dependencies that need to be changed during plugin updates and then query and integrate them conditionally? Something like this?
// Define the path to the file
$version_file = plugin_dir_path(FILE) . “new_subdirectory/redirection-version.php”;
// Check whether the file exists before integrating it
if (file_exists($version_file)) {
require_once($version_file);
} else {
// Optional: Error handling or fallback
}
Could something like this perhaps help a little to feed modern nested caching systems with fresh data in good time before they cause unexpected errors?
Do you think it might help to first define the paths and dependencies that need to be changed during plugin updates and then query and integrate them conditionally? Something like this?
I think it would be a very error prone process that would likely create its own set of problems, and is not a problem unique to Redirection.
Typically this kind of setup is not needed as WordPress does not do an in-place update, and fully downloads the plugin, before swapping it out as a whole. If this was a general issue then it would affect many people across many plugins and WordPress updates.
You mention using Plesk to do the update, and I have no knowledge of how that works. If it does do in-place updates then I would advise switching to WordPress updates. You mention having to restart PHP, and that itself seems an unusual thing to have to do for an error – most sites do not need a server restart to fix a momentary PHP issue.
There have been over 750k updates of the plugin over the last week, and including your report, there are a reported total of two issues. I’d love to understand exactly what caused those two, but the volume doesn’t indicate a fundamental issue.
Thread Starter
fob
(@fob)
Unfortunately, it seems that PHP-FPM + OPcache retain paths in memory, which occasionally causes problems with updates these days (even if the code otherwise works flawlessly).
In plugins, the best way to address this issue may be to add a small piece of extra code like this:
/*
if (function_exists(“opcache_reset”)) { opcache_reset(); }
*/
On the server side, you can slightly adjust the PHP.ini on performance-optimized servers to have links in the server cache automatically checked the next time they are accessed:
/*
opcache.validate_timestamps=1
opcache.revalidate_freq=1
realpath_cache_ttl=10
*/
Because this can probably only cover about 90% of such caching errors, I now run a bash script outside of business hours that checks where updates have taken place in order to automatically restart PHP there, which reliably refreshes all caches. 🙂
All the required files do exist in the plugin. Your error seems different to the other ones here, so you may want to check if the plugin did install correctly.
I don’t believe I said anything about not addressing it, and did give a suggestion for what to try. Things sometimes cannot be addressed in one message.
The file in question does exist in the plugin, and you can see for yourself here:
https://plugins.svn.ww.wp.xz.cn/redirection/trunk/build/
Have you checked your installation to see if that exists?
I’ve released 5.6.1 which contains a few checks and some old files to try and help prevent this opcache situation. These checks and files will be removed in a future version.
This seems to be something that the systems performing the caching handles, rather than making it a burden of every plugin. I think there is an outstanding core WP issue to help with this, as well as other plugins.
I will mark this thread as resolved as I think everyone has got things working, and the new checks should help with immediate upgrades. If there are other cases then it makes sense to start a new thread with specific details.
