Not really any different to authentication plugins

Authentication plugins are designed to be enabled or disabled at the will of the site admin. They are optional plugins.

This Namespace Updater plugin, by its own admission, is designed never to be disabled.

@wilsonge Is it true? Has this plugin to be always enabled? If so, I can make a PR to fix the "protected" value for that plugin. Or is just that text wrong and in fact it CAN be disabled when only using namespaced extensions?

Is it true? Has this plugin to be always enabled? If so, I can make a PR to fix the "protected" value for that plugin. Or is just that text wrong and in fact it CAN be disabled when only using namespaced extensions?

I would say go with the protected step for now as this seems to be required even for namespaced extensions.

Sorry to clarify - with the authentication plugins there is a similar message warning you that you must have one authentication plugin enabled. I assumed that it would be the same here that a user might want/need to use a different namespace plugin

I would say go with the protected step for now as this seems to be required even for namespaced extensions.

Really? My quick test doesnt have any problem with it disabled

Really? My quick test doesnt have any problem with it disabled

Have you installed an extension that uses its own namespaces?

Sorry to clarify - with the authentication plugins there is a similar message warning you that you must have one authentication plugin enabled. I assumed that it would be the same here that a user might want/need to use a different namespace plugin

hmm I hardly see anyone using a different namespace update plugin.

Sorry to clarify - with the authentication plugins there is a similar message warning you that you must have one authentication plugin enabled.

A "one of n" rule for "enabled" we can't force with the "protected" column of the extensions table in database.

My knowledge on namespace mapping is too little, so I wait for instructions. I am the database guy who can make the necessary SQL. But I'd prefer to have feedback from @wilsonge .

Daft question perhaps but if this has no options and it must always be enabled why is it even a plugin

I agree seems @yvesh had the same idea in the intial version too:

As when the plugin is not enabled this can break the entire site, we should reevaluate protecting plugins / extensions OR move it to the installer etc.

#16403

I did consider just hard adding this into the events system to be honest. But generally most people prefer an approach of having customisation.

As mentioned this plugin is basically responsible for regenerating the namespace map files when extensions using namespaces (there will only be a few to start with I assume) are installed/updated. If extensions rely on autoupdating then this plugin needs to exist.

The plugin can still be disabled today, however, even when disabled, if the autoload_psr4.php is deleted, Joomla will still regenerate it on first page load - and not crash the site as it used to.

The ability then to disable the plugin is correct - and a configurable part of Joomla - that allows an admin to control if the mapping is updated on install/uninstall of extensions.

Of course you would be mad to disable it - but the option is there - what has been fixed since this issue was open, was the complete crashing of the site if autoload_psr4.php was not available, now, Joomla silently recreates it on first page load.