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?
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:
WordPress 5 is a moving target - they were still adding features in beta 5
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
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
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 ā¦
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
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.ā
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
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.