Blank screen when using the migration plugin

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.

1 Like

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.)

  1. Run Switch to ClassicPress

URL appears: /wp-admin/about.php?updated

(blank page, no content in source )

  1. Loading the public-facing site in another browser, loads OK

  2. 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.


I saw nothing relating to this site in the PHP or Apache logs.


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…?


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.

1 Like

That may help, for now.

1 Like

This sounds similar to a problem I had. It varied, but mostly was stalling and leaving me stuck in maintenance mode. It was hosting-related.

1 Like

Got some error messages with WP_DEBUG true. Hope it helps. ( @james ? )

Switching from WordPress v5.3.2 to ClassicPress

  • https://URL_REDACTED/wp-admin/about.php?updated
Fatal error: Uncaught Error: Class 'ParagonIE_Sodium_Compat' not found in
/path_redacted/htdocs/wp-includes/sodium_compat/lib/constants.php:8 Stack
trace: #0
require_once() #1
require_once('/path_to_WordPress...') #2
require('/path_to_WordPress...') #3
require('/path_to_WordPress...') #4
require_once('/path_to_WordPress...') #5
require_once('/path_to_WordPress...') #6
require_once('/path_to_WordPress...') #7
require_once('/path_to_WordPress...') #8 {main} thrown in
/path_redacted/htdocs/wp-includes/sodium_compat/lib/constants.php on line 8
Fatal error: Uncaught Error: Call to undefined function esc_url() in
Stack trace: #0
WP_Fatal_Error_Handler->display_default_error_template(Array, false) #1
WP_Fatal_Error_Handler->display_error_template(Array, false) #2 [internal
function]: WP_Fatal_Error_Handler->handle() #3 {main} thrown in
/path_redacted/htdocs/wp-includes/class-wp-fatal-error-handler.php on line
  • Try live site OK
  • Reload https://URL_REDACTED/wp-admin/about.php?updated
  • DB update required
  • OK
  • ‘Welcome to ClassicPress’
  • 1.1.1 now update to 1.1.2
  • 1.1.2 migration
  • update to 1.1.2
  • OK

Thanks for the additional info.

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.

This does look like a similar issue to mentioned above. However, the fix suggested on that issue would not work for this case because the actual error is different. At least things normalize after a few seconds, the same as Wade had previously reported there.

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:


Could this be an issue with OPcache?

Just searching around, here are a couple of threads I came across:


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' ) ) {
1 Like

WordFence was previously on that site and I found this:

I thought so.

I think there was aggressive caching set up on the server.

@james Thank you for formatting the code and bullet-points in my post to make it readable :grin:

Yes, I thought I was not paying attention previously, this made me check.

1 Like

If you let me know which file to edit, I should be able to try this.

1 Like

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.


I was off testing this actually - though I think this is a morning thing because I was making silly mistakes while trying to test it :slight_smile:


Thanks @wadestriebel !!

Good to know, thank you.


1 Like

It could very well be the opcache. It’s easy enough to find out:


If you can run that on the same server it’ll tell you how the host has configured the opcache. opcache.revalidate_freq is the most obvious thing to look for.


Thanks @wadestriebel @invisnet @james

First I’ll say that configuring opcache is new to me, but I have invested some time reading and experimenting.

Value in seconds.

Obviously in a custom development environment it’s probably at 0 and all is good.

Default vs commonly set values appear to range:

Shared hosting environments will presumably vary.

I used a replica and tried a limited number of runs at 2, 5, 10, 15, 60. Based on limited number of runs:

  • 60 was always problematic

  • It worked once at 15 but failed once at 10, so obviously timing dependent.

  • 2 was OK (but again limited runs)

Unfortunately it appears this could cause server load issues and upset hosts:

After some experimenting I could reduce the problem of the loads to just this: opcache_reset()

Once I perform this call (independently of any prior or later deployment steps, this happens also in isolation when I just call this endpoint) there’s a chance the the system load suddenly spikes.

If that happens and the load is “too high” (I would say from experience > 200 or so), the system becomes unresponsive until for seconds or minutes, depending

Based upon my crash-course, this may be a better solution (but need more coding):

and there could still be other issues.

How do other installers, etc. handle it? (noting that installing new files is less problematic than file changes/ overwrites)

IIRC when I upgraded a plugin it updates instantly but it is seconds later before it says plugin ‘reactivated’.


Interesting, I definitely see how this could be a problem for high-traffic servers running large applications.

We could use opcache_invalidate instead, but this needs to be called for every single file that is changed, which in the case of a migration is really just about every file.

We would also probably want to make the ClassicPress upgrade process only replace and invalidate files that are actually changed, right now it just replaces everything.

Can you post all of the opcache configuration settings in your server config please? In particular, opcache.validate_timestamps, since it looks like if that is disabled it would cause this problem, according to the accepted answer at your link.

In any case this is pretty convincing evidence of the opcache being responsible for this issue. Thanks for investigating further!


Wouldn’t the same issue show up for a WP update or a CP update?