Add "Restore WordPress" feature

[glagonikas]

As discussed on Slack, it would be nice if this plugin would allow users to undo the migration and revert back to their old files.

Ideally, this should be done without having to manually restore a backup and we shouldn't assume everyone has saved one!

I believe we've previously discussed a few approaches

1. Revert to the previous WP version
To do this, we probably need to record their WP version at the time of the migration.
The plugin would then restore the core files to that version from the official WP respository.
Following this approach, means any customisations made to core files will be lost forever

2. Revert to their old files
During the migration process, the system will create a copy of their existing code on new folders in the same directories.
This solution would require double the storage space on the server and the migration could fail if the server reaches their allocated disk space.
This solution can be achieved using https://codex.wordpress.org/Filesystem_API
This solution is not necessary if users haven't modified any core files. A check is introduced on #26

3. Revert to the previous WP version and restore custom code
This is a hybrid of 1 and 2. When the migration starts, the code checks if any core files have been modified.
If all files are not modified, the previous WP version is recorded and the migration plugin reverts to that from the official WP repository.
If some files have been modified, the code records the WP version and creates backups of those files on a new folder, while retaining the folder structure. To restore, the plugin first restores the code from the WP repo and then overwrites any custom files.

[nylen]

I don't think we should try to preserve modified core files. We can show a warning or an error for this instead, like how the other pre-flight checks work.

This means we can go with option 1, at least at first, which should be much simpler.

There is already an open issue for checking for modifications: #12

[CPLouis]

If the process goes to the extent of comparing core files to see if there are any modified, why can't the process just stop when modified file(s) have been found, post WARNING!!! , require user to do a backup and/or check to indicate they wish to continue & only after the check to confirm does the plugin proceed?

That does away with the problem of considering saving modified files.

Anyone doing a migration should know to do a backup prior to initiating changes. If they don't, they really should be encouraged to do so.

[nylen]

why can't the process just stop when modified file(s) have been found, post WARNING!!!

This is basically what's already implemented, see screenshots here: #26 (comment)

Anyone doing a migration should know to do a backup prior to initiating changes. If they don't, they really should be encouraged to do so.

I agree. We mention the need to do a backup in multiple places, and allowing a restore back to WordPress would be for additional peace of mind beyond that.

[CPLouis]

Yes, you do that for upgrading to ClassicPress from WordPress. But downgrading back to WordPress, was what I was referring to. Maybe I got confused reading the OP description. Thanks

[nylen]

Ah, ok.

If someone has made modifications to WP files, those modifications are lost during the migration.

I hadn't even thought about what happens if someone has modified ClassicPress files and then restores to WP. At this moment we don't have a way to check for that.

[dyrer]

Why should can revert back to WordPress? You can add two warnings about conversion and then bam, if you return back to WP then restore from backup.
Or better warning should suggest take backup before proceeding

[ginsterbusch]

As CP does not change much, we could do it like this:

• option in the migration dialogue to clone the WP directories (wp-includes and wp-admin) for later switching back to WP
• copies said directories to eg. .wp-admin.bak and .wp-includes.bak
• when the migration process is done, and the user returns to the migration screen at some point, a message is shown, that the original WP install is still available, snd switching back is possible
• upon ticking a checkbox (eg. "yes, I definitely want to switch back"), and clicking a resp
  button (eg. "Undo changes"), the updated directories are renamed to eg. .cp_wp-admin and .cp_wp-includes
• next on, the original WP directories are renamed to their original state, ie. wp-admin and wp-includes
• tadaaa!

cu, w0lf.

[glagonikas]

Need to remember that users might not revert to WP immediatelly and might have to do so few weeks or months down the line.

In theory, the majority of users should not experience any issues after they switch between WPv4.9.x and CPv1.0.0 as there are no database changes, but as soon as WPv5 or CPv2.0.0 are released, this might not be the case.

the suggestion from @ginsterbusch is probably the simplest one, but since those two folders are quite large, people on restrictive hosting might run out space which could result in all sorts of issues (loss of space, additional fees etc).

CP should account for edge case scenarios, no matter how unlikely, as those could result in negative publicity.

[scottybo]

Seems the easiest approach.

I'd suggest one thing though: generating a randomly named zip file otherwise people could just download everyone's backed up directories.

Agreed on the edge case scenarios

[ginsterbusch]

the suggestion from @ginsterbusch is probably the simplest one, but since those two folders are quite large, people on restrictive hosting might run out space which could result in all sorts of issues (loss of space, additional fees etc).

No, they are NOT quite large; the big stuff is usually sitting in the wp-content directory, which shouln't require any changes - or maybe you are misjudging the regular web space one is getting with shared hosts ..

For comparison, sizes of both directories in WP 4.9.8:

• wp-admin: 6,8 MB
• wp-includes: 15,2 MB

@scottybo Yeah, I agree. Random naming + zip archive is probably the better option. My other idea was chmodding the directories to something else, but then one might not be able to de-chmod it later on, eg. when owner changes, group etc. (eg. if Plesk is not properly configured, you might run into those issues).

cu, w0lf.

[scottybo]

Thoughts @nylen ?

[nylen]

I think trying to backup & copy the WP directories is not worth it. Much more complicated code, and introduces a lot of edge cases that we are not ready to test & solve, some of which are hinted at above.

It would have been good to read the initial comments on this issue before proposing that again:

1. Revert to the previous WP version
To do this, we probably need to record their WP version at the time of the migration.
The plugin would then restore the core files to that version from the official WP respository.
Following this approach, means any customisations made to core files will be lost forever

I don't think we should try to preserve modified core files. We can show a warning or an error for this instead, like how the other pre-flight checks work.

This means we can go with option 1, at least at first, which should be much simpler.

[ginsterbusch]

It would have been good to read the initial comments on this issue before proposing that again:

1. Revert to the previous WP version
To do this, we probably need to record their WP version at the time of the migration.
The plugin would then restore the core files to that version from the official WP respository.

Store data in a JSON file? Or maybe a separate option value? Just a simple list, plus meta data like original WP version, upgrade timestamp and so on.

Following this approach, means any customisations made to core files will be lost forever

Whyever one would make customizations to core and THEN upgrade to CP. Except maybe to stay on WP < 5.0 at a much later date (like 6 months after release of WP 5.0) and avoid security issues.

From whatever angle I'm trying to look at this "core customizations", there never is a reason, at least not since WP 4.0, to do THAT. Should all be solvable by creating a plugin, bootstrapping WP core in a separate script and similar approaches.

cu, w0lf.

[nylen]

I think all that's needed is a single option value like cp_restore_wp_version.

From whatever angle I'm trying to look at this "core customizations", there never is a reason

I agree, but people still do it, usually from not knowing better.

[nylen]

An update on this issue:

• Since commit 4c0b463, and the 0.3.0 release in late November of last year, the migration plugin saves the previous WP version in an option named classicpress_restore_wp_version.
• PR #52 adds code to migrate/restore a site to any version of WordPress or ClassicPress. This needs review and extensive testing, and we also need to build an easier/nicer UI around it.