Regression from #3341682: #states + #required do not automatically work together, resulting in an unsubmittable AccountSettingsForm

Is anything logged? Do any contributed or custom modules modify the form?

Do you have any overrides in settings.php

I can't tell if this but report is something to do with the Configuration system, or a report that some change on the account form is not persisted when posting the form.

Sorry for the delay in replying to all. I was going back to check possible issues, per previous replies/comments.

No error messages in the Drupal logs, only info messages of cron execution.
Looked at Apache Journalctl and php logs, and no errors/warnings involving php or db for Drupal site.
No overrides in settings.php file. Only addition to settings.php file after the install was the
additon of trusted host setting.

I did notice that the module captcha keypad (Version: 8.x-1.6) was no longer working, which I un-installed and then deleted via composer. Th captcha keypad module was specifically used on the Account settings section of the Configuration area. Also deleted Honeypot and Tokens, leaving me with a pretty basic system. Th captcha keypad module worked flawlessly in version 10.1.7.

I was left with:
From core, all modules remain installed except::
Activity Tracker, Announcments, Automated Cron, Ban, Book, Content Moderation, and Workflows. (These were never installed)
No core experimental modules installed
No migration modules installed
The following non-core modules remain installed:
All Field types modules installed except Datetime Range. (datetime, file, image, link, options, telephone, and text installed)
All default multilingual modules installed (Conf Translation, Content Trans, Interface Trans, and Lang installed)
All default web services modules installed (HTTP Basic Auth, JSON;API, Restful Web Svcs and Serialization installed).

I also reverted back to the 10.2 Olivero theme along with the 10.2 Claro admin theme. Was using W3CSS theme.

After this, I cleared caches, reset permissions, restarted Apache and php8.2 servers.
Still no luck in saving config in the /admin/config/people/accounts area.

As final check, rebooted test server. Still no luck.

I am leaning toward the captcha keypad module possibly affecting the install of 10.2 and will re-install 10.1.7 files/database, un-installing the captcha keypad, honeypot, and token modules prior to installing 10.2 and see if this will allow for a clean install of 10.2

Ok,

I re-installed Drupal 10.1.7, un-installed all contributed modules, leaving only
Core modules, Web services, and default Field types. Also reverted back to the
Olivero theme and Claro admin theme. Once all of above was done, I re-tested
the /admin/config/people/accounts area to verify I could still save. It allowed
the configuration in /admin/config/people/accounts to be saved on Drupal 10.1.7

I then used composer to update from Drupal 10.1.7 to Drupal 10.2, with no errors.
I updated scripts (no errors), cleared caches, and verified all modules that were
enabled in 10.1.7 were also enabled in 10.2 (they were). I re-tested to see if I could
save changes in the /admin/config/people/accounts area. Was still not able to save
changes in this area. Verified all Account settings in Settings, Manage Fields, Manage
Form display, and Manage display tabs. Those on 10.2 matched those that were in
10.1.7.

I also re-verified that all other admin menu areas that had a Save feature, could
actually save changes (they did).

I found no errors in php, mariadb, and the only drupal log info was that cron had ran
successfully, but no errors. The settings.php file in 10.1.7 and 10.2 matched.

I am running out of settings to check, and not sure what/where the issue is.

This Accounts settings area rarely gets used, mostly when while on a test server.
Un-checking the "Contact settings" prevents a new user from trying to register
while the test system is online. Does anyone happen to know the area in the
Drupal database that the "Contact settings" can be set, which is likely a simple
boolean value?

Which specific settings do not save?

Does the form actually post to the site?

Any area can be changed within the settings tab of the admin/config/people/accounts area,
and it appears to be working all the way until pressing the Save Configuration button.

An example is the "Contact Settings", which is normally enabled (checkmark within checkbox).
I can disable the checkbox (checkmark disappears). But then when pressing the Save
Configuration button at the bottom of page, it will not save. If the webpage is refreshed, the
info reverts back to the old data.

As for the form working (posting to site), it is only utilized when a new user creates a new
account from the login screen. After the user selects "Create new account", the registration
form will appear, and the new user can begin populating the registration form. All of these
fields work, and can also be changed if necessary, with any changes saved.

I tested this with a dummy user registration, and the form does appear, and the info from
the form can be edited and does save. Once saved, the user appears in the People list.
This works on both Drupal 10.1.7 and 10.2

I have included 2 .pdf screenshots of the tabbed area that is not working,
and the tabbed areas that are working.

Does the form actually post to the site?

The form actually posts to the site. It can be accessed via the "My Account" area, is viewable,
and can be edited, and re-saved.

The form can be edited and re-saved (successfully) at any time by the user or admin.

I have been going through each field on the form, and have compared between versions
10.1.7 to 10.2.0; and may be zeroing in on the overall issue.

I have found one difference, with one field.

With 10.1.7 the following field, as follows:
Label:
Location (State/County)
Machine name:
profile_state
Field type:
List (text)
After clicking on edit in the Operations column, then Field settings, I get the following
in the "allowed values list":
Alabama|Alabama
Alaska|Alaska
American Samoa|American Samoa
Arizona|Arizona
.....the list goes on to display all possible choices of states/countries for the user.
I can re-save this field in 10.1.7

With 10.2.0, this area starts out looking exactly the same
Label:
Location (State/County)
Machine name:
profile_state
Field type:
List (text)
After clicking on edit in the Operations column, there is no option for "Field settings"
or "Allowed values list"
and I get the following instead:
Field Storage
Name:
Alabama
Machine name: Alabama
There is a remove button (Most indicate - 'Cannot be removed: option in use")
....this is repeated for all states/countries.
The machine names are also a combo of upper and lower case.
When I click on the Save settings at the bottom of screen, I am greeted
with the following error:
Error message
67 errors have been found: ValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValueValue

I believe this corresponds to the fact that something in 10.2.0 has changed these entries into machine
names instead of the text list.
Each of the 67 individual errors is listed as:
The machine-readable name must contain only lowercase letters, numbers, and underscores.
A unique machine-readable name. Can only contain lowercase letters, numbers, and underscores.

I have included a screenshot of the error for this field:
I have also included a screenshot of how this text list appears when editing in 10.1.7

I am not sure if this is why I annot be save on the admin/config/people/accounts (settings tab), but
is the only difference that I have found.

#11 looks like it's the same bug as 🐛 Regression from #2521800: using machine name element for ListStringItem breaks with existing data Fixed

I am closing this as a duplicate to increase attention on the other issue. If the connection turns out to be wrong we will reopen this bug.

Thank you for the detailed analysis on affected fields as that was crucial.

The issue with the fields is related to 🐛 Regression from #2521800: using machine name element for ListStringItem breaks with existing data Fixed But I do not immediately see why that would prevent saving the settings form itself. That issue is specifically related to list fields on entities, it shouldn't affect a config form, and I see nothing in core behind the scenes that would trigger any validation around the fields when saving just the settings form.

Un-checking the "Contact settings" prevents a new user from trying to register
while the test system is online. Does anyone happen to know the area in the
Drupal database that the "Contact settings" can be set, which is likely a simple
boolean value?

Contact settings would be stored in the 'user_default_enabled' key in the contact.settings config file, though new user registration would be the 'register' key in the user.settings config file, where a value of 'admin_only' would prevent registration. Both are simple configurations that could be exported at /admin/config/development/configuration/single/export and copied into /admin/config/development/configuration/single/import with a modification and saved

Cross post with cilefen. I didn't mean to undo his status change, though I'm still unsure how 🐛 Regression from #2521800: using machine name element for ListStringItem breaks with existing data Fixed would affect the actual settings form.

Does the patch from 🐛 Regression from #2521800: using machine name element for ListStringItem breaks with existing data Fixed , or running 10.2.x → , fix this?

All,

Thanks to all for assisting on this issue. The help is very much appreciated, and hopefully this can help any others with similar issues.
Before I get into my next steps, I wanted to wish all assisting a "Happy Upcoming New Year!".

I was able to disable potential new users from registering using 10.2.0, using the info/process provided by Mike Lutz. Thanks Mike!
If I choose to upgrade my live site to 10.2.0, I can now control this function, even though rarely needed.

Of greater importance right now, is why the Allowed values list that was working in 10.1.7 was changed into incorrect upper case machine names for the States/Country field after upgrading to 10.2.0. It appears this one is being worked on as a separate issue, of which I will follow separately.

I thought possibly that the States/Country field was the issue and copied version 10.1.7 to a test server for another test. I deleted the States/Country field from version 10.1.7, and then Verified 10.1.7 could still save in /admin/config/people/accounts (settings tab). It worked fine (could save). I created a dummy user, registered the user successfuly and the dummy user could login with authenticated user privileges. The admin could also access the new account, and make any changes to the dummy user form.

I then upgraded to 10.2.0 again via composer and the subsequent upgrade script was successful. I cleared caches, and tried to save in the /admin/config/people/accounts (settings tab) again. Still no luck. Server settings are the same with 10.1.7/10.2.0. No Apache or Drupal errors. Status report indicates all areas are working (no errors).

I will continue to see if there are any other settings that may have changed that could prevent the "Save" function from working
on the /admin/accounts (settings tab). I have a fresh install of 10.2.0 on another server, with no data. I will begin comparing
the default settings to the settings that I currently have, to see if there is anything that could be preventing the save from
occurring successfully.

Can you confirm that 🐛 Regression from #2521800: using machine name element for ListStringItem breaks with existing data Fixed fixes this bug?

The "Save" issue in /admin/config/people/accounts (setting tab) is not fixed.
Still cannot save this tab.

Which way did you test 🐛 Regression from #2521800: using machine name element for ListStringItem breaks with existing data Fixed , patching or using the core development branch?

I used 10.2.x-dev with composer. It fixed the text lists fields issue that I had in
/admin/config/people/accounts (manage fields tab) area, but I am still not able
to save in the /admin/config/people/accounts (settings tab) area.

At this stage is there a specific field whose presence prevents saving?

Ok,

Have found a solution to saving the /admin/config/people/accounts (settings tab).

Found one old function name [user:name] that was acceptable in 10.1.7, which
appears to be deprecated and has been replaced by either [user:display-name]
or [user:account-name]

Accent characters were also found in the text body of the email section of the
settings tab. The characters were: está, aún, genealogía, más, contraseña.

I used /admin/config/development/configuration/single/import to import a clean
copy of the default user.mail text from a base install of 10.2.0.

The import was successful, and now allows the save function to work. I will go
back and re-write the extra body text to the email section of the settings tab,
which will exclude the accent characters, although I am not positive that these
are allowable or not. I know you cannot save filenames with accent characters,
but not sure if accent characters are allowed in text body?

I am not sure if there should have been an error displayed when trying to save
this settings section. Possibly a check for deprecated functions or the accent
characters?, since these areas were all considered acceptable in version 10.1.7.
Possibly something to consider in future upgrades.

I consider this issue resolved, and appreciate all those who assisted.

[user:name] isn't actually deprecated as such, just discouraged, see 📌 Remove uses of the [user:name] token Needs work .

Accent characters were also found in the text body of the email section of the
settings tab. The characters were: está, aún, genealogía, más, contraseña.

This ought to be OK I would think. Were the 10.1 and 10.2 versions of the site running one exactly the same database version or in different environments? I'm wondering if you hit a table collation issue maybe?

A database character set (or perhaps, a collation) violation would be a storage driver exception but the site in question seems not to produce errors even for serious problems. 🤷

Catch,

Thanks for the info with regard to accent characters, and the deprecation
being a warning, and not mandatory.

Both websites are running on the same server and share the same IP.
The server specs are Intel(R) Xeon CPU E5-2630 @2.4Ghz, 12 cores, with 47
gigs of real memory, and a 940 GiB hard drive.

Both websites use MariaDB 11.0.4 nd both use utf8mb4 collation.
Both websites use PHP 8.2.14 (both use 2048 mb memory/mpm_event mode)

The Drupal update each time was successful, and after updating scripts, and
clearing caches, a system status check indicated no errors on 10.2.0.

I have attached both user.mail text files for reference.

One item I noticed immediately is that at the very beginning
of the 10.2.0 user.mail file has the coding:
_core:
then the default hash
then the langcode: en
then cancel_confirm

the 10.1.7 user mail file does not have the first 3, and
begins at:
cancel_confirm

After changing/modifying any setting within /admin/config/people/accounts, changes to the configuration do not save after selecting "Save configuration" box at the bottom of the page.

This is not reproducible with a fresh install of Drupal 10.2.

After importing the https://www.drupal.org/files/issues/2024-01-01/10.1.7%20user.mail%20text.yml config into user.mail, I do not get a validation error in Google Chrome, but I do get:

accounts:1 An invalid form control with name='user_mail_status_blocked_subject' is not focusable. <input data-drupal-selector=​"edit-user-mail-status-blocked-subject" type=​"text" id=​"edit-user-mail-status-blocked-subject" name=​"user_mail_status_blocked_subject" value size=​"60" maxlength=​"180" class=​"form-text required form-element form-element--type-text form-element--api-textfield" required=​"required" aria-required=​"true">​
accounts:1 An invalid form control with name='user_mail_status_canceled_subject' is not focusable. <input data-drupal-selector=​"edit-user-mail-status-canceled-subject" type=​"text" id=​"edit-user-mail-status-canceled-subject" name=​"user_mail_status_canceled_subject" value size=​"60" maxlength=​"180" class=​"form-text required form-element form-element--type-text form-element--api-textfield" required=​"required" aria-required=​"true">​

in the console upon trying to save 🤔

Investigating further 🕵️‍♀️

status_blocked:
  subject: ''
  body: ''
status_canceled:
  subject: ''
  body: ''

Technically, this is invalid config since 📌 Introduce a new #config_target Form API property to make it super simple to use validation constraints on simple config forms, and adopt it in several core config forms Fixed (commit: e1c95b2f9989a3bb0915d5a66bfe0337f228edb2).

But … this is reproducible using the commit before that, because it's a JavaScript/HTML5 error in combination with Drupal's #states API.

Found the root cause.

📌 New config schema data type: `required_label` Fixed introduced a bunch of '#required' => TRUE. But some of those were for conditionally displayed inputs.

Solution: https://drupal.stackexchange.com/a/317525.

This looks good. We don't usually bother to test individual config forms but should we add one here? I'd like to get this into 10.2.1 (i.e. by Friday), so if test coverage is tricky, we could probably do that in a follow-up.

I don't think we generally have test coverage for every use of #states? In fact, UserAccountsForm already has #states and has no test coverage either 😇

Yeah I think it's OK, testing for very specific forms like this doesn't help much.

FWIW, we have a ton of #states tests since #2702233: [backport] Add JavaScript tests for Form API #states: required, visible, invisible, expanded, checked, unchecked → and a bunch of issues since then that have expanded it. But afaik, we don’t have much, if any, other tests for #states on real core forms.

Meanwhile, I hate #states[‘required’] since it doesn’t do anything but toggle the red asterisk. 😅 I haven’t looked closely at the code, but do we want/need to add any additional validation that if the “parent” value is set correctly that the “child” field actually has a value? I’ve always added that manually in cases like this. Is there a general solution? Or does it not even matter here?

Issue credits

I agree with #38, we need to ensure this validation can't be bypassed if JS is turned off.

So my first thought is that we need a validate callback to ensure the value is set if the pre-condition is TRUE

BUT we're actively working to remove validation from forms to config-objects.

Looking at the schema for these fields, they're using type mail, which is the following:

mail:
  type: mapping
  label: 'Mail'
  mapping:
    subject:
      type: required_label
      label: 'Subject'
    body:
      type: text
      label: 'Body'

And looking at required_label that's this:

required_label:
  type: label
  label: 'Label'
  constraints:
    NotBlank: {}

And then looking at the NotBlank constraint, it doesn't support empty strings.

So I think that means we've already got this validation in the config system.

So I manually tested that, and it does work

But it really perpetuates the existing issue we have here.

Because the field with the error isn't visible because the checkbox is unticked.

So I think the best course of action is as follows:

• Commit this as is, it moves the needle
• Open a follow up to improve the error messaging when a required field is hidden by states

Agreed with #39, sounds like a good plan.

Opened 📌 Improve error messages on required fields when they're hidden by Javascript states Active

Committed to 11.x and 10.2.x

Thanks all for the investigative work

larowlan → closed merge request !6008

it doesn’t do anything but toggle the red asterisk. 😅

It also triggers HTML 5's required validation.

And … of course there is actual server-side validation too now, unlike for 99% of config forms in Drupal core 🤓 That is the whole point of 📌 New config schema data type: `required_label` Fixed + 📌 Introduce a new #config_target Form API property to make it super simple to use validation constraints on simple config forms, and adopt it in several core config forms Fixed ! 🥳 Thanks, @larowlan for proving this with manual testing + detailed explanation in #39 😄

Thanks to all for looking at and correcting the issue that I was having
with not being able to save in the /admin/config/people/accounts
(settings tab).

I upgraded from 10.1.7 to 10.2.1 today, and after a successful upgrade
via composer, I attempted to change a value in this area. A "Subject"
error was provided, which led me to place a value in the subject area
of the blocked/account cancelled mail section, even though they were
not being used. After adding the text to the subject area, I was able to
save. This error allowed me to pinpoint why I was not able to save in
this settings tab area.

Automatically closed - issue fixed for 2 weeks with no activity.