I think this is something that has been reported in the past, from what I recall I had a similar experience but I believe it was a caching issue. But, I don’t know where that discussion was now.
Edit: I guess that was reported above, clearly I am tired
OK wanted only to feedback that it still seems to be the case. If it helps I had not caching enabled.
I am not familiar with bug tracking in github so posted it here.
This could be a similar issue (depending on server configuration you may get a white screen when an error occurs), however it’s hard to say without more info.
Thanks for reporting this issue @trying. If you can send any relevant entries from your site’s PHP error log, or a screenshot of the error (for future issues) that will help us narrow things down.
Makes sense, I guess I kept looking at issues on ClassicPress/ClassicPress-Migration-Plugin - I can do some test on Laravel Forge again to see if I am still having the issue as well.
Hi James, I didn’t have a screenshot but I think it had already upgraded at that point as I saw the status lines flash past quickly before it went blank - it was trying to display the post-upgrade page URL (it just appeared blank but I did not check page source.)
Maybe I can go back to a previous backup and try it again if it would help and try to check log.
One of the quick (temporary) solution can be just write a warning, that “during migration your screen can be Black/White/BeerAd, don’t panic, this is the caching (or, whatever it can be) consequence, migration still in progress, reload after a few beer.” This will reduce stress significantly.
I’ve been able to reproduce (but not isolate) this.
The following after restoring the ClassicPress site to WordPress v5.3.2 and restoring all user content.
( it’s not a 100% image as I can’t justify rolling back that server.)
Run Switch to ClassicPress
URL appears: /wp-admin/about.php?updated
(blank page, no content in source )
Loading the public-facing site in another browser, loads OK
On admin screen, nothing has changed, so reload, then prompted to upgrade database
URL appears /wp-admin/about.php
(no ‘?updated’ suffix)
‘Welcome to ClassicPress!’ displays with prompt to update to v1.1.2
update this (twice) then all OK.
LOGS
I saw nothing relating to this site in the PHP or Apache logs.
ALSO TRIED
Repeated with less plugins (notably no WordFence) but had the same result.
On some occasions the user facing site was a blank page briefly so I deduce it’s maintenance mode…?
A DIFFERENT WP SITE ON THE SAME SERVER FUNCTIONED AS EXPECTED
On a different site on the same server with less content and plugins, I used the same tool to switch from WordPress v5.3.2 and it worked perfectly as expected.
It looks like your web server is loading old versions of some files (something that requires sodium_compat, and something from the fatal error handler, neither of which we include in ClassicPress). This does not represent the order in which things actually happen during the update process: by the time about.php?updated loads, the updated versions of all core files have been written to disk.
This makes me think you are indeed seeing an issue with some caching layer (probably not a WP plugin, probably something lower in the stack). However I don’t know what it would be.
cc @invisnet, any idea what layer might be causing the webserver to read old versions of PHP files for a few seconds after a migration (or presumably any other major upgrade) completes?
Finally one thing we definitely can fix from the above is the fact that the migration plugin still switches to ClassicPress 1.1.1. However this requires us to complete some infrastructure tasks first (re-establish the nightly build). This is being tracked here: https://github.com/ClassicPress/ClassicPress-Migration-Plugin/issues/68
Could be. I’m not very familiar with the PHP opcache, but if that’s what it is then the fix should be as simple as calling opcache_reset after an upgrade completes:
if ( function_exists( 'opcache_reset' ) ) {
opcache_reset();
}
That was mostly Wade actually. For future reference you can make readable code blocks for code or log output by surrounding them in three backticks, like this:
```
code here
```
I don’t know off-hand, I’d have to take a closer look at it also. The key is to make sure this runs after the upgrade has completed, immediately before you get redirected to the About page again.
Testing changes that involve upgrades can also be tricky.