Error when users are enrolled in too many courses (or long course names)

[superklausi]

Some users who are enrolled in many courses (~100) get the following error when logging in or opening their dashboard in Moodle 3.3.2 with Boost theme: "Coding error detected, it must be fixed by a programmer: Invalid value in set_user_preference() call, value is is too long for the value column".
In the debug mode we find that this error may be related to the plugin moodle-block_course_overview_campus. The version of our plugin according to our moodle-plugin overview is 2017063000.
Is there any way you or we can fix that easily?
The plugin works fine for users being enrolled in fewer courses, only teachers who are in charge of a large number of courses get this error message.

We would be very happy if you could help us,
best wishes from Vienna,
Klaus

This is what we get from the debug-mode:

line 1022 of /lib/outputrequirementslib.php: call to debugging()
line 1465 of /blocks/course_overview_campus/block_course_overview_campus.php: call to page_requirements_manager->js_call_amd()
line 288 of /blocks/moodleblock.class.php: call to block_course_overview_campus->get_content()
line 230 of /blocks/moodleblock.class.php: call to block_base->formatted_contents()
line 1197 of /lib/blocklib.php: call to block_base->get_content_for_output()
line 1249 of /lib/blocklib.php: call to block_manager->create_block_contents()
line 374 of /lib/blocklib.php: call to block_manager->ensure_content_created()
line 3839 of /lib/outputrenderers.php: call to block_manager->region_has_content()
line 42 of /theme/university_boost/layout/columns2.php: call to core_renderer->blocks()
line 1162 of /lib/outputrenderers.php: call to include()
line 1092 of /lib/outputrenderers.php: call to core_renderer->render_page_layout()
line 164 of /my/index.php: call to core_renderer->header()

Coding error detected, it must be fixed by a programmer: Invalid value in set_user_preference() call, value is is too long for the value column
Debug info:
Error code: codingerror
Stack trace:

line 1897 of /lib/moodlelib.php: coding_exception thrown
line 436 of /blocks/course_overview_campus/locallib.php: call to set_user_preference()
line 1500 of /blocks/course_overview_campus/block_course_overview_campus.php: call to block_course_overview_campus_remember_notshowncourses_for_local_boostcoc()
line 288 of /blocks/moodleblock.class.php: call to block_course_overview_campus->get_content()
line 230 of /blocks/moodleblock.class.php: call to block_base->formatted_contents()
line 1197 of /lib/blocklib.php: call to block_base->get_content_for_output()
line 1249 of /lib/blocklib.php: call to block_manager->create_block_contents()
line 374 of /lib/blocklib.php: call to block_manager->ensure_content_created()
line 3839 of /lib/outputrenderers.php: call to block_manager->region_has_content()
line 42 of /theme/university_boost/layout/columns2.php: call to core_renderer->blocks()
line 1162 of /lib/outputrenderers.php: call to include()
line 1092 of /lib/outputrenderers.php: call to core_renderer->render_page_layout()
line 164 of /my/index.php: call to core_renderer->header()

[abias]

Hi Klaus,

first of all, I am sorry to hear that you encountered this problem. This shouldn't have happened.

Then, this problem only occurs if you are using our plugin local_boostcoc at the same time. Can you please confirm that you also use this plugin?

The underlying problem is that we decided to store the list of not-shown courses for local_boostcoc in a user preference. Unfortunately, user preferences are quite limited in length (see https://github.com/moodle/moodle/blob/master/lib/moodlelib.php#L1898) which we were not aware of until now.

If we calculate with 5-digit course IDs, this limit will be broken at approx. 160 enrolled courses. That's why we haven't hit this limit in our instance yet.

If you read through https://tracker.moodle.org/browse/MDL-46739, you will see that there were plans to change user preferences to a (longer) text field in DB, but there were objections / discussions about side-effects and the thing was neither finished nor closed as won't fix.

As a long-term solution, I will rebuild the storage of this data in a separate table. But this will take some time and won't be finished before the end of october, I'm afraid.

As an intermediate-solution, I can only recommend you to replace the existing line https://github.com/moodleuulm/moodle-block_course_overview_campus/blob/master/locallib.php#L436
which currently reads

// Store the current status of not shown courses.
set_user_preference('local_boostcoc-notshowncourses', $jsonstring);

with

if (core_text::strlen($jsonstring) < 1333) {
    // Store the current status of not shown courses.
    set_user_preference('local_boostcoc-notshowncourses', $jsonstring);
}

For the users who had the debug message which you quoted before, filtering the courses in Boosts nav drawer will be broken then until there is a real fix, but all other user will still have the same functionality.

I will keep you updated.

Thanks,
Alex

[zidludwig]

hi Alex,
thanks for the workaround! Only i took
if (core_text::strlen($jsonstring) < 1333) {

best
Ludwig

[abias]

thanks for the workaround! Only i took
if (core_text::strlen($jsonstring) < 1333) {

Damn, you're right, of course. That was a copy & paste mistake. I fixed it in my comment above.

[superklausi]

thanks Alex for your help. the workaround does work as you described.
We would appreciate a "real" fix as soon as you find time to do it.
Again, thanks for your great work!

[abias]

Hi,

this issue has been stale for 1.5 years now.

While we still would like to see this issue fixed, it won't be done anymore as we are foreseeably transitioning our own usage of this block to the Dashboard blocks which have been dramatically improved from Moodle 3.6 on and thus can't spend any more substantial resources on this plugin.

Fixing this problem would require to change the logic of storing hidden courses not in (length-limited) user preferences but in a custom table, including the creation of custom webservices for getting and setting the values.

Since this issue was reported, only one of our own users has hit the limit and turned his Dashboard unusable.
We decided to go with this hack for the time being:

[root@moodle1 moodle_prod]# git diff lib/moodlelib.php
diff --git a/lib/moodlelib.php b/lib/moodlelib.php
index 79c93fe..8ab9a9f 100644
--- a/lib/moodlelib.php
+++ b/lib/moodlelib.php
@@ -1893,7 +1893,13 @@ function set_user_preference($name, $value, $user = null) {
     }
     // Value column maximum length is 1333 characters.
     $value = (string)$value;
+/* KIZ MODIFICATION START
+   REASON: Invalid value in set_user_preference() call, value is is too long for the value column */
+    if (core_text::strlen($value) > 3000) {
+/* KIZ MODIFICATION END */
+/* ORIGINAL START
     if (core_text::strlen($value) > 1333) {
+   ORIGINAL END */
         throw new coding_exception('Invalid value in set_user_preference() call, value is is too long for the value column');
     }

This hack has to be accompanied by a SQL change of the user preferences table which, in Postgres, looks like this:
ALTER TABLE mdl_user_preferences ALTER COLUMN value TYPE varchar(3000);

As soon as we retire this block, we can change the table back with
ALTER TABLE mdl_user_preferences ALTER COLUMN value TYPE varchar(1333);

I am really sorry for the hassle which this bug has caused, but I rely on your understanding of our limited resources.

I will keep this issue open as a reference for anyone who also stumbles into the problem.

Cheers,
Alex