Support

Hello Jip,

The restore points feature is very hit-and-miss. It was created back in the Joomla! 1.5 days when a few assumptions were mostly true:

• All extensions store their data in their own tables. These days extensions implementing ACLs, categories, tags or content versioning also store data in Joomla! core tables, in a way which doesn't allow us to separate this data from core data – or from third party data.
• Table names have predictable prefixes or can be provided by the extension developers. The developers who didn't follow the "prefix is the same as the extension name" norm never bothered to supply this information and Joomla!, despite initial thoughts to the contrary as can be seen in the sample XML manifest files, never forced developers to explicitly declare the naming pattern of their extension's tables.
• One installation package = one extension = one XML file. Now we have the "package" type extension with multiple extensions inside it and the file, library and language extension types without an actual extension included.
• The installation path is predictable. This was and is still true for (most) templates, components, plugins and modules. It is not true for all of the other extension types.
• All extensions are installed through the Joomla! extensions installer, using a web browser. Nowadays we have the extensions updater and, most importantly, third party services and CLI scripts doing this. There is no way to offer a unified way of taking restore point backups.
• If you replace the files of an extension with those from a previous version the extension will still work. With the advent of autoloaders and RAD frameworks this is simply no longer true.

There is no solution to most of these issues. For those which can be solved, the solution is not consistent. We cannot guarantee that SRPs will work reliably. In fact, we can only guarantee that they will most likely fail. This is despite the amount of time and effort I've put into it. Some things can simply not be done. I think the SRP feature was ahead of its time. Perhaps Joomla! 4 –whenever it's released– will include a similar feature. The last time the Joomla! project discussed the extensions updater we all agreed we need separate staging and deployment steps when installing an update. The staging step could easily be converted to a backup step using a plugin. It remains to be seen if the project will agree to implement this new updater method. Until then, SRPs are pretty much dead in the water...

It comes down to this: when a feature misbehaves and cannot be fixed to conform to our very high standards we have no other option than to remove it. Remember the Akeeba Backup Lazy Scheduling plugin? It's the same story.

You're welcome!