CP Migration plugin needs some TLC

I thought I’d make a post here to increase visibility of an Issue that has been raised bout the CP Migration plugin.

The plugin is in need of some testing on more recent version of WordPress. WP 5.8 is due soon and as it currently stands the migration plugin only officially supports migrating from version 4.9.0 to 5.5.3.

The Issue linked above is actually, as far as I can tell, more about WordPress themes, rather than the core itself.

Specifically from that ticket the wp_get_script_polyfill() function is used to enqueue JavaScript for IE11, I think for the Block Editor, the wp_body_open() has been wrapped in checks to ensure it exists in previous core WP themes (2010 to 2020) and the same applies to the wp_unique_id() function (in 2017 and 2020).

So, the issue seems to be linked more to the Twenty Twenty One theme.

As a way forward should we consider checking for themes in the migration plugin that have known issues and encouraging a theme switch before migration, or do we back-port these functions - bearing in mind that the latter approach is likely to get more heavily linked to the Block Editor with time.

Thought please…

4 Likes

I prefer this over trying to backport those functions which will only become more annoying to integrate overtime.

This does raise a question of when we have moved too far from WP to be able to support a clean migration back and forth.

4 Likes

It would be beneficial to the project to maintain this as long as possible to help people transition over.

Is there a way we can support migration while flagging issues which the user needs to fix manually as part of the migration?

2 Likes

I’ve already pulled the migration plugin code and started having a play, with a few minor changes I can display an error message if using an incompatible theme, block migration and propose a fix.

There are a lot of open issues on the plugin too, like incompatible plugins being handled in this way too. I’ll get some focus on it in the next week and create one PRs. I’ve not got commit permissions for the migration plugin - not sure whow has at the moment either.

3 Likes

I’ll get you same access as core, thanks for taking a look :+1:

Edit: should have access now :slight_smile:

2 Likes

Just a thought. Wouldn’t it be a good idea to have a list of incompatible themes and plugins as files (text/JSON) maybe hosted in GitHub or CP.net that the plugin can check? This would allow us to update lists without modifying the plugin every time.

1 Like

@viktor

Got idea and one that had occurred to me.

I supposed it’s the trade off between maintaining just the plugin code in one place, or maybe fewer updates to the plugins and server side list of incompatible themes and plugins.

One disadvantage to server side is aiming to minimise the number of API calls in the code, but I suppose we can return the required data in one call to the API here:
https://api-v1.classicpress.net/migration/

To include data on themes and plugins.

2 Likes

API is a good option, just requires additional work to set up the endpoint. I think the lists themselves should be maintained on GitHub, and entries would require a PR. This way we can track everything.

For reference, this is how Matomo (Piwik) maintains referrer blacklist: https://github.com/matomo-org/referrer-spam-list

1 Like

I’ve got a commit ready to add to the migration API that adds conflicting themes and plugins.
It also enables migrations all the way to WordPress 5.7.2, in my testing it all works fine.

But before it’s worth landing that there will need to be a concurrent update to the Migration plugin and the nightly and migration builds need to be working again, at the moment migration is messy via 1.1.1 with lots of error messages on screen in Debug mode.

At the moment this is where I am stuck. :frowning:

2 Likes

I will see if I can figure out the nightly builds today :+1:

1 Like

I may have finally got a GitHub script at least syntactically correct:

See what you think and maybe flatten it and backport to the main repo.

1 Like

Nice! I think the only thing is we need a way to pass the API Token:

Then it looks like it calls the update script in the api repo to generate the json data:

Which is here:

Given we are in the same repo I was under the impression it would available via GitHub action secrets so I’ve included ${{ secrets.GITHUB_TOKEN }} - of course it may need adding elsewhere in the script.

1 Like

:+1: Same here.

1 Like