Support

We had but removed this feature about 9 years ago since it would not work reliably with Joomla 1.6 and later and even before that it still had some problems because Joomla knows far less about an extension than you think it does.

As we had explained back then, Joomla rates records in the #__assets table for all extensions. That's the same table where records are created for any core or third party asset which needs access control such as categories, articles, tags, fields, banners etc. As a result, excluding the extension creates a "hole" in that table (it's a tree which database-wise is implemented as a double linked list of records) which can have serious adverse effects on you site.

Furthermore, Joomla does not have any hard requirement for extensions to use specific table names, nor does it record or even has a way for extensions to communicate which tables they are using. In fact, it only provide a facility for developer to run arbitrary SQL scripts and a post- and pre-installation hook so they can run whatever code they please, including their own database table installation / uninstallation code. The former is what most extensions use for installation, updates and uninstallation. Joomla itself uses that for updates. The latter is what we use in our own software, with our own database table installer / uninstaller.

While in most cases we can rely on developers' unspoken convention of using the same prefix as their component name (i.e. com_example will use tables with the #__example_ prefix in most cases) it's not a guaranteed success. Even Akeeba Backup uses the prefix #__ak_ instead of #__akeeba_ except for one table, but that table is shared across all of our extensions. Shared tables is the other reason extension exclusion didn't work. It becomes even worse with anything other than components since in that case there's no convention to begin with.

On the filesystem side, Joomla only has a hard requirement for the location of executable files and translation (language) files. These are easily predictable locations and there's no problem. However, when you go to simple things like static media it's anybody's guess. There's a convention Joomla recommends but does not enforce, about files in the media folder. It's also perfectly possible for developers to use a different convention or folder without communicating it in any way to Joomla. Further to that, several extensions will use folders outside of the ones predetermined by Joomla, typically user-configurable folders. For example, Akeeba Backup lets you define an output directory anywhere on your site, or outside of it. Same goes for download managers, e-commerce extensions, third party caching extensions or extensions implementing their own caching etc. Speaking of caching, Joomla does have a set of cache folders but developers are not mandated to use them and nothing else for caching. We've seen... things.

When you start putting all of these together it becomes pretty clear that the solution to these problems looks exactly like the database and file and directories exclusion rules we already have. So why try to reinvent the same wheel?

Regarding your use case, you don't need to exclude the plugin. Upon restoration you can rename the .php file of the plugin. For example, if the plugin is system/example then you need to rename system/example/example.php to system/example/example.php.bak. Joomla can no longer find and load it. You can then unpublish and / or uninstall it from the backend of your site. If you know you definitely don't want this plugin to load on a restored site you can simply exclude this folder.

In the past I've toyed with the idea of letting you select which extensions to disable (but NOT uninstall them) upon restoration. I've not seen a compelling use case for that (as in: there's no alternative) and an extensions picker could only really work when setting up the backup, NOT when restoring the site. The reason for the latter restriction is that Joomla doesn't store the human readable extension name in the database, just the translation string to use. We'd have to replicate the entire language file loading detection and loading logic of Joomla in our installer to do that but this is problematic for many reasons, one of which is that excluding a language file from the backup would make this feature break. While I could find a solution I didn't bother because, as I said, I couldn't find a good use case where deleting a file post-restoration wasn't adequate to address it and even this use case seems to be very rare to begin with.