calmPress / calmpress

A modern CMS based on WordPress
https://calmpress.org/
22 stars 1 forks source link

Backup functionality which is part of core #44

Open markkap opened 6 years ago

markkap commented 6 years ago

Need to do research into which plugins can be serve as base for this. Most important aspect is ability to perform a lightweight backup before installing and reverting in case of any failure.

User triggered backup/restore can wait for later phase of development.

mikeschinkel commented 5 years ago

What would be good would be to add a backup API and then a simple backup implementation thus allowing more robust backups to be created by 3rd parties.

markkap commented 3 years ago

Minimal option for backup with the main goal of being able to recover the site after bad core/theme/plugin upgrade or install.

Backup should create backups of code files and options (options table). The idea is that if any content was created in time time between backup and restore it will not get lost, and same goes for user related settings. Potential problem might be users which were added in between and might lack the appropriate role, probably will need some audit of users after restore, or some smartness in the code.

It should be possible to trigger backup manually and perform automatically before upgrades (should it be a setting?).

Backups should be created in uploads/.protected/backups directory where the filename has the form of backup-{time}. In addition a "meta" file will be created as well under the name of meta-{time} and will include some meta infromation for the backup like version of calmPress, trigger etc. (separate file and not in the backup itself to make it faster to read the information).

Backups should be removed when they become older than 30 days and there are more than 30 in the directory. Probably should be configurable.

What is backuped should be extendable. Core of code files and options should always exist for a restore from safe mode, but plugins should be able to add whatever to it. Also trigger action when a backup was finished to be able to move the backups (but not remove) to external storage.

An action in the end of restore process should enable pluggins to trigger their own part of the restore. An action before the restore starts might enable plugins to "download" backups from external storage to present more restore options to the user.

markkap commented 2 years ago

UT passes, but UX is not there :( close was very premature