Blank screen when using the migration plugin

From WP v5.3.2 used Switch to ClassicPress - it wasn’t sure about something but said it was ready to go.

Progress was displayed quickly, then the blank screen appeared.

Later the site was on ClassicPress.

Seems to be stable after that, but not a reassuring first experience.


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 :slight_smile:

1 Like

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.


That was from a while ago.

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.

1 Like

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