I was recently contacted by a user who was unable to change his own password. I quickly recreated the issue with a test account when trying to make any changes to my own profile as the test user. The error message I get is:

The field cms_smart_topic_notification is required and cannot be left blank

That error shows up whether I have the "Smart topic notification" setting checked or unchecked in the Notifications tab.

The "cms_smart_topic_notification" setting is built-in, and the "required" parameter can't be edited from within the Composr admin zone. Long story short, I tried installing a new Composr site on a test box, and I found in the MariaDB database that "cms_smart_topic_notification" had "cf_required" set to 0 by default. I was able to recreate the issue on the test box by changing that to 1, and I was able to fix the issue on my own site by changing it to 0 in the database.

What's confusing me is that I looked up where the table's originally created in the source code, and it appears it's being created with "cf_required" set to 1 (as far back as it's included in the file's history). Does anyone know where in the installation code it would have been changed to 0 on my fresh install of Composr? Any other Composr users out there, what's it set to on your installation?

jacobgkau said

I was recently contacted by a user who was unable to change his own password. I quickly recreated the issue with a test account when trying to make any changes to my own profile as the test user. The error message I get is:

The field cms_smart_topic_notification is required and cannot be left blank

That error shows up whether I have the "Smart topic notification" setting checked or unchecked in the Notifications tab.

The "cms_smart_topic_notification" setting is built-in, and the "required" parameter can't be edited from within the Composr admin zone. Long story short, I tried installing a new Composr site on a test box, and I found in the MariaDB database that "cms_smart_topic_notification" had "cf_required" set to 0 by default. I was able to recreate the issue on the test box by changing that to 1, and I was able to fix the issue on my own site by changing it to 0 in the database.

What's confusing me is that I looked up where the table's originally created in the source code, and it appears it's being created with "cf_required" set to 1 (as far back as it's included in the file's history). Does anyone know where in the installation code it would have been changed to 0 on my fresh install of Composr? Any other Composr users out there, what's it set to on your installation?

From “cms_smart_topic_notifications issue preventing member profile updates”, 6th May 2025

 
The .sql files are not used by Composr directly. They are there for manual installation of the database.

There was a bug in Composr v10 where the field was marked required. In version 10.0.46, I fixed this bug (or, at least, it should be fixed; if you are running 10.0.46 or later, or v11, and are having this issue, please let me know.)

For v10: https://gitlab.com/composr-foundation/composr/-/blob/master/adminzone/pages/modules/admin_version.php?ref_type=heads line 996

For v11: https://gitlab.com/composr-foundation/composr/-/blob/v11/adminzone/pages/modules/admin_version.php?ref_type=heads line 1052

Thank you for the insight, Patrick. I think I know what happened– I just tried setting changing the setting back to 1 in the database, opened up upgrader.php, and clicked the "Do a database upgrade" button, and sure enough, the setting was changed to 0 in the database automatically. When I upgraded from 10.0.43 to 10.0.50, I think I skipped clicking that button because it says to the left of it "(Only needed for feature/major upgrades)" and underneath it "The on-disk version of Composr is 10 and the in-database version is 10. This means the database is currently up-to-date."

I'll remember to click the button on all updates moving forward, and am looking now to see if the check/copy near that button is something simple enough for me to contribute an improvement to. I know I've clicked the button anyway during some past minor updates, but I was in more of a rush for this last one since I was only updating for the sake of validating a bug report (ironically).

That makes sense.

Rarely, database upgrades happen in v10, thus the statement. But it doesn't hurt to run it every upgrade; it just won't do anything if there's nothing to upgrade.

v11 operates differently now because I expect to be making database changes as necessary with patch releases. It will use timestamps to determine when the database needs upgrading, and will tell you such on the upgrader (after transferring files).