The dev version was installed, and as you stated, corrected the problem. Thanks for the prompt reply and fix.
lee56 → created an issue.
Thanks, I will definitely give it a look. Thanks for recommendation.
That is quite ok. I learned much about this process by your instructions. I am just glad that the issue is being resolved. It appears that the forum.info.yml file is where the info needed to be revised. I look forward to the revision, and seeing the forum listed out of the core area.
It has been a steep learning curve for me, learning the basics of Drupal a few years ago with no admin or php experience. In 2022 I volunteered to rescue an old Drupal 6 site built in 2008 that was no longer operative. I am retired, and figured I had the time to learn the admin portion. The Drupal 6 site was brought back online and then converted to Drupal 9, and then updated to Drupal 10.
I hope to take a breath and learn more about the coding at some point in the near future. I was going to purchase a book on Drupal development back in 2022, but the books on the market were covering Drupal 6-7 and the short lived Drupal 8. Drupal finally seems to have stabilized since Drupal 10, so perhaps now is the time to find a good book to learn some of the finer points. Thanks again for your help.
Thanks for your patience. I did click on 'create the issue fork', which then informed me that I have push access.
Issue fork forum-3456433 ✓ You have push access
In the show commands area, I see 2 options, one SSL, one non SSL:
Since I know I have not set up SSL for this, I believe the second option would apply to me:
Or, if you do not have SSH keys set up on git.drupalcode.org:
git remote add forum-3456433 https://git.drupalcode.org/issue/forum-3456433.git
git fetch forum-3456433
I did just install git on my Linux server. The git version listed is 2.45.2
Have stopped at this point.
Thanks for replying to issue. As a fairly new admin for drupal, I am not familiar with the drupal merge request process, or how to proceed. I pretty much know the basics of the drupal module file structure and how to report bugs, but have no drupal/PHP coding experience. I also am not familiar with git/github, which I believe is the repository for drupal development, including merging code. If there is some way to assist, I am willing to learn/help, but will likely be more of obstacle at this time.
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.
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
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.
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.
The "Save" issue in /admin/config/people/accounts (setting tab) is not fixed.
Still cannot save this tab.
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.
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.
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.
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?
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
Lee56 → created an issue.
Thank you for the assistance in pointing me to this setting. Still have much to learn
about this new theme, but like it so far. Lee