Small migration frustration


#1

A small request…

At the moment it seems to take a few days for the migration plugin to “catch up” with WP (and CP) version updates.

I’m thinking of a scenario where you’ve planned to migrate a site on a particular day, then the day before, WP auto-updates to a new minor version (doh!) and suddenly you’re stuck until the migration plugin is revised to include the new WP version in its range setting.

I’m reluctant to override the filter in case something about the new WP version would cause problems, so… I guess I’m asking if the migration plugin updates (and the checks that are involved) can be given a higher priority in the grand scheme of all things CP.

But I’d also like to say that I’m aware CP is volunteer-staffed and I don’t wish to appear ungrateful for all the work that is being done behind the scenes. On the contrary, having a stable 1.0.x release with all the infrastructure that requires, within a few months of starting out, is remarkable and I appreciate all the work being done.


#2

I’ve been thinking about this too. There are two main issues:

  1. Someone still has to test the new version of WP with the migration plugin.

I’d be pretty surprised if WP 5.1.1 broke anything, but then again I don’t know everything that’s in it so I can’t say for sure.

So far no one has reported “yes, WP 5.1.1 works fine”, but this would also be helpful. Anyone who can create a new test site, install the plugin, and edit the code to override the version check can test this. Also, a quick way to set up a new test site is to use the testing framework for the migration plugin. More info here: https://github.com/ClassicPress/ClassicPress-Migration-Plugin/tree/master/test

  1. Currently we (I) have to do a new release of the migration plugin for every change (ClassicPress version, WP version, etc).

There isn’t really a good reason this has to be this way. Instead, we need to make an API endpoint under https://github.com/ClassicPress/ClassicPress-APIs that stores the acceptable WordPress versions, and the metadata for the ClassicPress version to switch to. The plugin would then query this endpoint, so that basic changes don’t require a new version of the migration plugin anymore.

I’ll be addressing (2) with the next version of the migration plugin, due “soon” (hopefully this coming week). In the meantime if any other developer wants to get a head start on making these improvements then that is definitely welcome and I am happy to answer any questions here on the forums, in Slack in #core, or on GitHub.


#3

Thanks for the detailed reply James.

With a view to helping out on point 1, I’ve now done the following:

  1. Created a new WP 5.1.1 install on localhost
  2. Installed the migration plugin 1.0.0
  3. In the plugin, changed $wp_version_max to ‘5.1.1’ in lib/admin-page.php
  4. In the plugin, changed $build_version to ‘1.0.1’ in lib/update.php
  5. In the plugin, changed $build_date to ‘20190316’ in lib/update.php
  6. Ran the migration process

It worked. New CP version reported was ‘Version 1.0.1+migration.20190316’, and the site seemed to be behaving normally.

However, my error log showed this:

[Sun Mar 17 11:26:34.801495 2019] [php7:warn] [pid 64400] [client ::1:59219] PHP Warning: An unexpected error occurred. Something may be wrong with ClassicPress.net or this server’s configuration. If you continue to have problems, please try the support forums. (ClassicPress could not establish a secure connection to ClassicPress.net. Please contact your server administrator.) in /Users/Andy/Sites/_migtest/wp-admin/includes/update.php on line 115, referer: http://localhost/_migtest/wp-admin/update-core.php

[Sun Mar 17 11:26:52.398563 2019] [php7:warn] [pid 64400] [client ::1:59219] PHP Warning: An unexpected error occurred. Something may be wrong with WordPress.org or this server’s configuration. If you continue to have problems, please try the support forums. (WordPress could not establish a secure connection to WordPress.org. Please contact your server administrator.) in /Users/Andy/Sites/_migtest/wp-includes/update.php on line 533, referer: http://localhost/_migtest/wp-admin/update-core.php

But it seems neither of the above warnings stopped the process working.