CP Migration plugin needs some TLC

MattyRob · July 7, 2021, 6:57pm

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…

wadestriebel · July 7, 2021, 10:21pm

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.

azurecurve · July 9, 2021, 8:12pm

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?

MattyRob · July 10, 2021, 8:14am

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.

wadestriebel · July 10, 2021, 11:50am

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

Edit: should have access now

viktor · July 10, 2021, 2:23pm

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.

MattyRob · July 10, 2021, 3:14pm

@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.

viktor · July 10, 2021, 6:18pm

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: GitHub - matomo-org/referrer-spam-list: Community-contributed list of referrer spammers. Comment +1 in any issue or Pull request and the spammer will be added to the list!

MattyRob · July 11, 2021, 11:56am

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.

wadestriebel · July 11, 2021, 3:34pm

I will see if I can figure out the nightly builds today

MattyRob · July 11, 2021, 3:57pm

I may have finally got a GitHub script at least syntactically correct:
https://github.com/mattyrob/ClassicPress-nightly/blob/93f64df7ffbce306d2a7a2150d8402399e0fc387/.github/workflows/nightly-builder.yml

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

wadestriebel · July 11, 2021, 4:02pm

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

github.com

ClassicPress/nightly-builder/blob/177f468d4efbc7a35158b453a43df056788e3ea5/example-config.sh#L3


      
          #!/usr/bin/env bash
          
          
GITHUB_API_TOKEN="token" # needs 'repo' scope
          UPGRADE_API_SCRIPT="/path/to/api/v1-upgrade-generator/update.sh"

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

github.com

ClassicPress/nightly-builder/blob/177f468d4efbc7a35158b453a43df056788e3ea5/build-and-log.sh#L12


      
          
          
(
          	"$(dirname "$0")/build.sh" "$@"
          	code=$?
          	echo
          	echo "Exit code: $code"
          
          
	if [ $code -eq 0 ]; then
          		echo
          		. "$(dirname "$0")/config.sh"
          		if [ -x "$UPGRADE_API_SCRIPT" ]; then
          			echo "Running upgrade API script:"
          			echo
          			"$UPGRADE_API_SCRIPT"
          			code=$?
          			echo
          			echo "Exit code: $code"
          		else
          			echo "Upgrade API script not found:"
          			echo "'$UPGRADE_API_SCRIPT'"
          		fi

Which is here:

MattyRob · July 11, 2021, 5:22pm

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.

omukiguy · July 28, 2021, 5:05pm

Same here.