XT-CMS Dev Blog - CMS Backup & Restore
The next upcoming version of XT-CMS will include an overhaul to how processes are run. Two of the most important processes that the CMS uses are the backup and restore processes, and in this blog post we will talk a bit how these have worked in the past and the new implementation coming soon. Note: technical dev blog ahead.
PHP Function Compatiblity
The backup and restore feature on the CMS has always been a challenge. At first, many versions ago, the PHP function shell_exec() was used with tar and gzip to package up and compress the CMS data into one tidy file for download. This worked really well except that some server configurations would have the shell_exec() PHP function disabled. So to cover this situation and make it easy for everyone to just backup and restore data without having to configure server settings we added an alternative backup method using PHP Phar commands. This worked great too and although the Phar commands require PHP5.3 or higher the CMS now had two backup/restore methods to cover most server setups.
Background Processing
Then the problem of big data and large backups raised its head. Some web developers had installations of the CMS with thousands of products to backup along with all the other data for categories, users, orders etc. This could cause the backup page in the admin area to time out. This wasn’t the best user experience so the backup and restore processes were updated to run in the background, once again using shell_exec() this time with the PHP nohup command. But this background processing would only be available to those with shell_exec() function enabled and others would have to use the existing on page load method. Even so, it was nice to have this option for those that could use it and who also had large backups.
PHP Version Compatiblity
Recently a new problem was encountered when testing on another server. For some reason the background processing was not working. After much digging and debugging finally the problem was realised. It turned out the website was set to run PHP version 7.2 however the default version of PHP running on the server was PHP5.3. This meant when the background processes were called through shell_exec() they were being run with PHP5.3 and the CMS installation was encoded to run on PHP7.2. Boom! Another incompatibility issue discovered and back to the drawing board again.
New & Improved
And so here we are now with a new and improved backup and restore process implemented to avoid all of these problems or at least mitigate as many as possible. The new method will now always run in the background for everyone without the need for the shell_exec() function. It uses the PHP function file_get_contents() to call the backup and restore process scripts in the background remotely thus ensuring the same PHP version the website is using is always used. The backup method will default to the Phar method for those on PHP5.3 or higher but will fall back automatically to the shell_exec tar with gzip method. In scripts/config.php the backup method can be overrridden to use the shell_exec method if preferred.
The restore process will automatically use the appropriate method based on the backup filename eg. mybackup_phar.tar or mybackup.tar.gz - And a new securtiy token system has been added to ensure these background process scripts can only be run remotely from within the CMS.
And there you have it, the trials and tribulations of creating a backup and restore system that runs in the background, can accommodate large amounts of data and is compatible on various servers and PHP configurations. No doubt there will always be edge cases that introduce imcompatibilities but this new method should be a well rounded improvement going forward.
