Plugin unable to migrate from WP 5

This plugin supports WordPress versions 4.9.0 to 4.9.8 (and some newer development versions).
You are running WordPress version 5.0-RC1-43944 .

Why not?

Two reasons:

  1. WordPress 5 is a moving target - they were still adding features in beta 5

  2. Time. RC1 has been out all of a couple of days over the Thanksgiving weekend

We will support migrating from WordPress 5, but not until we’ve properly tested the process.


I guess I don’t get it. I can do it manually by simply replacing the non wp-content files. I don’t care what version I’m replacing as I’m deleting it anyway. I assumed the plugin just did that also.

The plugin has to ensure a safe and smooth migration. To do so, and ensure that we aren’t going to break someones site, we need to test it before we support it :slight_smile:


Yes I was trying to test it …

My guess is, if the Classic Editor plugin is activated, a migration is still good to go.

Although I have to admit that more than often a combination of WP nightly + Classic Editor + Gutenberg plugin has turned sour, ie. suddenly no editing was possible anymore, half the admin interface was just not working (one could click on “edit” this or that page, but no matter where you were, front or backend, the editor either didnt work or the “edit” links as such broke / threw fatal errors).

cu, w0lf.

No if it fails the preflight it aborts the process.

You would have to manually add support for it in the code:

Then you should be all good to proceed, we don’t guarantee it will work or won’t break anything though :slight_smile:


Hm … if we added filter hooks to this, ie.

$wp_version_min = apply_filters( 'cp_migration_plugin_min_version', '4.9.0' );
$wp_version_max = apply_filters( 'cp_migration_plugin_max_version', '4.9.8' );

Then one could do this by themselves, eg. by creating an additional, ultra-simple plugin, eg. “WP 5.0 to CP migration add-on (EXPERIMENTAL)” … which just would consist of the plugin comment block, and one class, which would hook eg into ‘plugins_loaded’, and then add a filter to increase the max version.

cu, w0lf.

ps: yes, functions.php might work, too, but is probably not the safest and most reliable way … :slight_smile:


Ok changed max version to 6.9.8 and it passed. I see that the plugin does not remove the orphaned files though. I think this is true when doing a WP update as well.

I’ve used this plugin in the past.

Perhaps it could be incorporated into a future release.

Otherwise everything went smoothly on your WP release?

If so, that is good news :slight_smile:

Yes nothing broke that I’ve found. WordFence had a hissy fit over file changes and that led me to see that the new WP 5 wp-includes/block.php file was still there. It would have been the same result with the WP 5 install so nothing to do there. Frankly I never put much value in WordFence’s file scan of core files as the biggest vulnerability has always been plugins.

So I’d like to suggest that the migration plugin warns users of a preflight error but allows them to continue anyway. You know the drill …“undesirable outcomes might ensue but if you still want to try it type ‘Upgrade’ in the text box.” :slight_smile:

This is a known issue you can read more about WordFence here.

Otherwise, we will look into allowing it anyways. Although that is probably a question for @james :slight_smile:

Thanks for testing with that though!

Migrating from WP 5.0 to ClassicPress is definitely something we plan to support. We are tracking this issue here:

Please make sure let Wordfence know you want them to support ClassicPress - either via their premium support if you’re a customer, or their WordPress support forum if you’re on the free version


This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.