Really loving your product, i am using it across a huge range of clients already, and everything is running much smoother than many projects that arent open source.
A feature i am really missing though, is an automatic CMS-update feature. My heart is racing and i am half way to fear for my life each time i have to update the CMS. I know it is not often, but it’s the most stressing process ever. So an update-feature (like in Wordpress) where it will take an automatic backup, maybe from a range of settings? And then update the system, would save me so much headache.
We used to have it but the automatic database backup is actually really hard to do well. I don’t think Wordpress actually takes a backup by the way - it tells you to do it as we do. People felt that as we took a backup there was no need for them to. And then if the upgrade failed, and there was a problem with the backup we took then fingers start pointing and blame starts flying.
I don’t think it’s the project’s place to engineer a reliable way to backup your database. Only you can do that because only you know exactly what you’ve configured.
If you want a one-click supported upgrade, Xibo in the Cloud already offers that so may be worth your consideration.
There’s loads of backup scripts you can run if you have access to the command line on your server. AutoMySQLBackup is a good choice. But that’s very different from getting PHP to do the same job without having access to run shell commands (as Xibo would need to in most shared hosting environments). You really do need to take your own backups directly before you do an upgrade.
Akeeba has been a staple of the Joomla world for years. It harnesses PHP to backup the files and the database into an easily installable zip file. It works for backup, and for portability. If you develop on a dev server and have to restore to production, this can help
I’ll be buying it to backup my vTiger CRM, Mautic system, and for Xibo systems.
I have no affiliation with Akeeba. It’s just been a great product and will pay for itself right away. The alternative on a Linux system is to manually tar zip the file system and dump the SQL. Then FTP them for storage. FTP them back for restore, untar the files. manually restore the backup. and then fiddle with the configuration. Do this for more than one system and it becomes a lot of work.
Oh, did I mention that you should test your backups. And probably a good idea to document the restore procedure.