Small migration frustration

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.

7 Likes

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: ClassicPress-Migration-Plugin/test at master · ClassicPress/ClassicPress-Migration-Plugin · GitHub

  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 GitHub - ClassicPress/ClassicPress-APIs: ClassicPress API endpoints 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.

2 Likes

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.

3 Likes

The changes I discussed are here:

Code review and testing appreciated, this is a fairly complicated change so I’d rather have some more eyes on it first!

To test, you can use this version of the migration plugin on a test site: https://github.com/ClassicPress/ClassicPress-Migration-Plugin/archive/update/centralized-api.zip

WP 5.1.1 is supported and the plugin now switches to ClassicPress 1.0.1, the latest version. Other than that, there should be no change in behavior.

Hi James,
I just tested it on a localhost site and then a live site, worked fine on both, no issues. It switched WP 5.1.1 to CP 1.0.1 both times.

1 Like

Tested on 4.9 and 5.1.1 - both worked with no issues.

1 Like

Thank you both for testing. This new version of the migration plugin has been released: Release Version 1.4.1 · ClassicPress/ClassicPress-Migration-Plugin · GitHub

As discussed above, in the future we will not have to do a new release of the migration plugin when a new version of WordPress or ClassicPress becomes available. This will make it easier and quicker to update the plugin.

3 Likes

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