The parts I have tested (global config db password and user password) work correctly

I do not understand why the lock/modify button is present

There must be a clear feedback that the button has been clicked and the input is now disabled. The subtle background change on the input is not sufficient

Locked

Unlocked

Don't know how to make it more clear because that's how a disabled field looks like

Don't know how to make it more clear because that's how a disabled field looks like

By changing the button.

Look at the password login field where it changes from an open to a closed eye - although in this case I would try something like using a padlock in open and closed state and then also toggle the text between "protected" and "modify" or something like that

I assume that you realise that as soon as you change the database you will be immediately logged out as the default sessionhandler is database

I assume that you realise that as soon as you change the database you will be immediately logged out as the default sessionhandler is database

Yes but that's true for all database settings.

Was just checking. Personally that's a great reason for all of these database fields to be readonly as I cant think of a real world scenario where I have a working site that I will ever want to change the database of. In the extremely rare scenario that someone might come up with you can always edit the configuration.php.

I use them regularly while doing joomla updates and I see no problem doing this also because we have a protection against miss configuration.

On the other side you can can break your site with many other settings in the global configuration. But at the moment I want to fix the unset problem so I can build the rc....

I think this works well for the database field.

My only comment would be that I think the fields that are hidden by showon (e.g. ftp/proxy) need to be in edit mode by default when first enabled somehow :/ Because otherwise they look like they contain values when they are actually empty and will probably confuse our users. Example field with no value

Especially as we're using the string modify which kinda implies something already exists.

My only comment would be that I think the fields that are hidden by showon (e.g. ftp/proxy) need to be in edit mode by default when first enabled somehow :/ Because otherwise they look like they contain values when they are actually empty and will probably confuse our users. Example field with no value

Especially as we're using the string modify which kinda implies something already exists.

I would remove the hint completely

Also I think if you enter a default value for the password field then currently the value is set into the session and hitting save subsequently as the password field is disabled constantly uses the value from the session until you either hit cancel or remodify it. However it's not clear from the UI (obviously) that you're using the session value as opposed to the original value of the field because the field switches back to the disabled mode on the page reload (maybe some value in session storage or something?)

Now it looks like this in protected mode

and like this in unprotected mode

as alternative a one-way "modify" button without return is possible too

as alternative a one-way "modify" button without return is possible too

I think this would make more sense to me - although no sure if the absence of the button would constitute valid a11y - @brianteeman any feedback on that? Combined with automatic unlock if the field has been submitted with an invalid value preventing save (i.e. the password value is stuck in the session as opposed to the configuration.php value)

Sorry I'm not commenting on accessibility. Ask @carcam and the accessibility team. It's a big enough team that I'm sure one of them could find the time to respond.

I would remove the hint completely

Can't we add the hint conditionally? If a non-empty value is set, add the hint; if the value is empty, leave the field blank. That way we have a clear indicator for the user.

@wilsonge

as alternative a one-way "modify" button without return is possible too

I think this would make more sense to me - although no sure if the absence of the button would constitute valid a11y - brianteeman any feedback on that? Combined with automatic unlock if the field has been submitted with an invalid value preventing save (i.e. the password value is stuck in the session as opposed to the configuration.php value)

I see no clean way to address this, yes the password is saved in the session but will not be set in the field again because it's replaced by an empty string.

@SniperSister

I would remove the hint completely

Can't we add the hint conditionally? If a non-empty value is set, add the hint; if the value is empty, leave the field blank. That way we have a clear indicator for the user.

I renamed the button to "Previous" after pressing "Modify" and added the hint back with the count of characters of the original password. Also if you press "Previous" the password field is set to an empty string again and the hint (placeholder) is shown again.

I have tested the functions and it works well.

my2cent for the buttons: I suggest "edit" (if it is disabled) and "protect" (when enabled) instead of "modify" and "protected".

For a11y the button could have a title-attribute "open the input field for edit" and "protect the input field" for example.

my2cent for the buttons: I suggest "edit" (if it is disabled) and "protect" (when enabled) instead of "modify" and "protected".

"edit" is fine for me, I changed "protected" to "Previous" could be "cancel" too

For a11y the button could have a title-attribute "open the input field for edit" and "protect the input field" for example.

This is a title correct? So a description like "Allow to change the password" and "Cancel the password change" or so is too much?

I have tested this item ✅ successfully on d3698cd

I think this is good enough to ship. Definitely can improve it further. But fixes the "regression" in functionality for the next release. I'd consider at least being able to change SMTP credentials between local dev and prod sites essential (when I'm restoring via akeeba or whatever).

I have tested this item ✅ successfully on d3698cd

I tested password fields (FTP, SMTP and DB in global configuration - could not find others) to set a new one, change it and empty it.
I tested also the normal user registration in frontend and creating a user in the backend.
I changed passwords successfully in user management and in account details.

Ping. you might want to fix this bug... #31716

I already see you report and try to reproduce it and of course I will fix it