I have tested this item ✅ successfully on c844021

Testing looks good. The error presented may need converted to a more friendly response.

@alikon Is this the expected presentation of the error?

I have tested this item ✅ successfully on c844021

Tests good for the intention of this PR. if the concerns about the error message display need corrected a separate PR can be done for that.

RTC

Setting back to pending as the new lang string is neither present in the plugin strings, neither in the installation lang strings.

Note

After correcting these and if merged, TTs have to be informed (via Mig) that the installation lang files will have to be updated.

Can someone suggest/correct the text for the language string please

I am not convinced this is the correct approach. What you are doing here is to prevent the user being created by one plugin. This wouldn't prevent a user being created if a different plugin was being used. Surely the correct approach is to prevent the situation being created in the first place by preventing a site admin from even being able to configure their site in this way. If there is no way that a guest user can be a super user and no way that a guest user can be a new registered user then the ability to create that scenario should be prevented in the component. Blocking it here is shutting the gate after the horse has bolted.

To explain a bit more, the plugin is importing the options from the component. Any plugin or extension can do that as well and they do. So you need to fix the problemat the source which is the component not the plugin

I think there is an arguement for needing to do this in BOTH the plugin AND the component. As Brian says, it is the component which creates the user, or gives this option. However, there are other extensions/components which also create users, so the more robust approach would be to additionally make this change in the plugin to prevent a SuperUser being created from the front end.

The plugin imports its settings from com_users - therefore if a non core extension is using the plugin it is de facto using the options in the component.

If a non core extension imports the settings itself it is also using the options in the component

If the non core extension is creating users any other ie directly into the database then there is nothing we can do about that.

Therefore there is no need to put any code in the plugin to handle this. It wont make anything more robust - it must all be in the component.

if you disable the joomla user plugin you even are not able to login more

Not true. You are confusing this USER plugin with the AUTHENTICATION plugins

maybe
but just give me 0,01¢ of your time and check it

that is because it is handling sessions and nothing to do with authentication. It is still irrelevant to this pr. the plugin is the wrong place to achieve your aims

i don't claim that this is the better way, that's why the issue is still open #27262 (comment)

Test looks good. I am unable to register as a superuser. I do get the response below, and I am not sure if it need to be translated to a friendly version or if it is okay as is.

I have tested this item ✅ successfully on b2353b3

Please see #28011 for what I believe is the correct approach - preventing the super user being selectable in the first place

closed in favour of #28011