Add "Restore WordPress" feature #27
Comments
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 |
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. |
This is basically what's already implemented, see screenshots here: #26 (comment)
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. |
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 |
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. |
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. |
As CP does not change much, we could do it like this:
cu, w0lf. |
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. |
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 |
No, they are NOT quite large; the big stuff is usually sitting in the For comparison, sizes of both directories in WP 4.9.8:
@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. |
Thoughts @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:
|
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.
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. |
I think all that's needed is a single option value like
I agree, but people still do it, usually from not knowing better. |
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.
An update on this issue:
|
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.
The text was updated successfully, but these errors were encountered: