New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add "Restore WordPress" feature #27

Open
glagonikas opened this Issue Oct 24, 2018 · 14 comments

Comments

Projects
None yet
6 participants
@glagonikas
Contributor

glagonikas commented Oct 24, 2018

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

This comment has been minimized.

Member

nylen commented Oct 24, 2018

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

This comment has been minimized.

CPLouis commented Nov 15, 2018

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

This comment has been minimized.

Member

nylen commented Nov 15, 2018

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

This comment has been minimized.

CPLouis commented Nov 15, 2018

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

This comment has been minimized.

Member

nylen commented Nov 15, 2018

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

This comment has been minimized.

dyrer commented Nov 16, 2018

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

This comment has been minimized.

Contributor

ginsterbusch commented Nov 16, 2018

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

This comment has been minimized.

Contributor

glagonikas commented Nov 16, 2018

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

This comment has been minimized.

Member

scottybo commented Nov 16, 2018

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

This comment has been minimized.

Contributor

ginsterbusch commented Nov 16, 2018

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

This comment has been minimized.

Member

scottybo commented Nov 16, 2018

Thoughts @nylen ?

@nylen

This comment has been minimized.

Member

nylen commented Nov 16, 2018

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

This comment has been minimized.

Contributor

ginsterbusch commented Nov 16, 2018

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

This comment has been minimized.

Member

nylen commented Nov 16, 2018

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 added a commit that referenced this issue Nov 27, 2018

Save the WP version for possible later restoration
Adding the ability to restore to the previous WP version (if it is a
recognized version) is planned for a future version of this plugin.

See #27.

nylen added a commit that referenced this issue Nov 27, 2018

Remove the "Switch" link when running ClassicPress
Closes #43.

We can consider putting this back (and having it say "Restore WP") when
issue #27 is implemented.

The plugin admin page will stay around, it will also be used for #27.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment