Upgrade Settings loop

Upgrade Settings loop

by Seth Yoder -
Number of replies: 16

Happy Wednesday,


On one of our Moodle (3.2.4+) sites, I am getting stuck on the Upgrade Settings page when I log in as an admin. If I visit the /admin URL, I am redirected to /admin/upgradesettings.php.

If I try to change any of the settings listed, their values in the database do actually change, but when I click "Save Changes", the Upgrade Settings page is just reloaded with the default values filled in.

The same thing happens if I go directly to the settings page for one of the plugins - for example, the General Backup Defaults settings page. If I change any settings there, they change in the DB backend, but their default values are loaded.

At first, I thought this might be cache-related. I disabled Nginx caching, cleared out the Nginx cache folder, purged all moodle caches, purged my browser caches, and used Incognito Mode. Nothing changed.

Has anyone run into anything like this?


Thanks!

-Seth Y.

Average of ratings: -
In reply to Seth Yoder

Re: Upgrade Settings loop

by Ken Task -
Picture of Particularly helpful Moodlers

@Seth ... multiple sites on one server could mean sharing of PHP/MySQL/web service resources.  Are setting of those sufficient to handle the # of sites?

How many different settings are involved in the upgrade to settings? ... # of plugins to be updated?

Have experienced something similar in past ... too many settings on one page.   Had to revert to clicking on one of items to be changed and saving settings there.  Wash - rinse - repeat sort of thing until all completed - or until the culprit discovered.

Do you use the Essentials theme?

Upgrades to that theme could be massive.  At one time author of the theme suggested setting the default theme to something stock, then tackle the theme by itself.  Could set default theme via config.php file.

Have you checked apache/web service error logs for anything related?

Have you/can you turn on debugging?   Might have do that via config.php as well.

What is your max_input_vars setting in MySQL?

There is yet another cache ... php opache.  Might install one of these:

https://www.stevejenkins.com/blog/2014/07/my-favorite-zend-opcache-status-scripts/

To see what's in opcache.

'spirit of sharing', Ken

Average of ratings: -
In reply to Ken Task

Re: Upgrade Settings loop

by Seth Yoder -

Hi Ken,

Thanks for your reply!  There are only ~25 settings on the page. I have cleared the opcache, and max_input_vars is currently =1000. I'm using the Adaptable theme, and there are no theme settings on the /admin/upgradesettings.php page.


But here's some more relevant info: 

If I change a setting on the /admin/upgradesettings.php page, the values do actually change in the database. For example, one of the settings is backup_general_calendarevents. I can modify this on the /admin/upgradesettings.php page, click "Save changes" (after which the page loops back) and the boolean value will flip from 1 to 0 (or vice versa) in the database. BUT, if I go to the /admin/settings.php?section=backupgeneralsettings page, the settings seem to have a mind and memory of their own. Nothing I do on this page modifies database values, and backup_general_calendarevents is set permanently to 0. 

I have cleared every cache imaginable, and at this point I'm convinced I'm dealing with a poltergeist. If I have time this week, I'll do some code-digging.


Thanks again,

Seth

Average of ratings: -
In reply to Seth Yoder

Re: Upgrade Settings loop

by Ken Task -
Picture of Particularly helpful Moodlers

Just thinking out loud here ...

'one of sites' ... 3.2.4+ (build date?) - so it's just one site of X.   How was site installed/upgraded?

And dubugging returns nothing?

What would be different on this one site?

Are setting of the problem plugins locked? 

For one, DB, DB user ... and maybe priv's of that user for that DB.  You could temp change the DB user and password to that of your DB server superuser ... then TIA.

'spirit of sharing', Ken

Average of ratings: -
In reply to Ken Task

Re: Upgrade Settings loop

by Seth Yoder -

The build date is 20170901... It's the only site on the server. I manage 30-40 Moodle sites all on separate servers, hence the "one of". The site was upgraded last September from version... I think 3.0? I don't completely remember, to be honest.

Nothing coming out of the server logs with the most verbose debugging! The "_locked" rows in the database's mdl_config_plugins table all have NULL/empty values. Is this normal?

I'll test it with the DB superuser account on a test server tomorrow. Thanks for your suggestions!


-Seth

Average of ratings: -
In reply to Seth Yoder

Re: Upgrade Settings loop

by Ken Task -
Picture of Particularly helpful Moodlers

We seem to be disclosing a little more info at a time ... site having issues is a dedicated server.  That means no shared PHP/MySQL etc. settings.   How updated/upgraded?   The 'old way' or via git?   The 'old way' - ftp or similar ... also involves ownerships/permissions, etc..   So I was seeking info on if something is missing or has owerships/permissons that might be at play.

The 'locked' to which I referred is in the config of some addons ...  some even have locked and advanced settings.  When I run into something like this I'll check the Moodle Admin UI first for settings seen there and then the related tables.

Go to your server's: /admin/plugins.php?updatesonly=0&contribonly=1

That should list your 25 addons.   There will be an update link as well as version info for each plugin.  There one might see 'cannot be upgraded' ... directory permissions issue.

Sometimes issues like this are a result of some 'minor' thing but I'll do one plugin at a time - get the updated code, then update the database.    Yes, that could mean 25 times.   But, if doing it the other way ... all of them at one time, you might not ever discover what's causing the hickup.

Latest build is 3.2.7 (Build: 20180115).  Might be a bug that was fixed between your 3.2.4+ and the 3.2.7 (soon to be updated again next week, I thought).

'spirit of sharing', Ken


Average of ratings: -
In reply to Seth Yoder

Re: Upgrade Settings loop

by Tania Ramirez -

I'm having a similar issue. 

When going to the Notifications page I'm redirected to the upgradesettings.php where part of the configuration of some authentication plugins are listed (like showed in the image below), but we don't even have those authentication plugins enabled :/



Average of ratings: -
In reply to Tania Ramirez

Re: Upgrade Settings loop

by Ken Task -
Picture of Particularly helpful Moodlers

@Tania ..

Are you sure?  Admin user can login cause admins accounts are normally 'manual', but other authentications could be active ... yes, I know you said they are not active ... but why would your Moodle ask for config if they were off?  Both appear to be looking for new settings related to 'data mappings'.

So, let's see what's turned on in the DB ... as superuser or using credentials from config.php file try this query:

mysql> select name,value from mdl_config where name like 'auth';

What does that return?

You could try to put some text in the text boxes ... characters not true junk.  Don't set them to check upon every login ... in other words, don't change the drop down pick list/options list, just leave them for defaults.   That's just to get by the updates screen.   Of course if you were really using CAS (sso) and Shilbo ... then those users auth via those will be locked out ... cannot log in.    Might check with your networking folks/true server techs.

'spirit of sharing', Ken

Average of ratings: -
In reply to Tania Ramirez

Re: Upgrade Settings loop

by Peter Stacey -

I had a very similar issue with getting stuck on the update settings pages for ldap field mapping for a custom field after upgrading to 3.5. In our case it turned out that there was a case mismatch problem in the mdl_config_plugin records. Ours was for a field called 'instrument' so for the auth_ldap settings the parameter names in the database were  e.g. field_map_profile_field_Instrument instead  of field_map_profile_field_instrument

Editing this in the database for field_map_profile_field_instrument, field_lock_profile_field_instrument, field_updatelocal_profile_field_instrument and field_updateremote_profile_field_instrument fixed the problem. Not sure how it happened or why it didn't affect other auth methods.


Average of ratings: Useful (3)
In reply to Peter Stacey

Re: Upgrade Settings loop

by Pierpaolo Gallo -

I had the same problem and I fixed it in the same way.

the problem was a custom field in capital letters that in mdl_config_plugins table was in lowercase in several records.


Average of ratings: -
In reply to Peter Stacey

Re: Upgrade Settings loop

by Michal B -
Thanks a lot ... the same problem + solution when upgrading to 3.6.5 year later...
Average of ratings: -
In reply to Tania Ramirez

Re: Upgrade Settings loop

by Alberto Castro Servicios -

Hi, Tania.

I am having the exact same problem as you reported. 

Is there any chance you can help how to solve this?

Best regards.

Average of ratings: -
In reply to Alberto Castro Servicios

Re: Upgrade Settings loop

by Kyriakos Terzopoulos -
Picture of Translators
The same problem on Moodle 3.9+
The auth_xxx plugins showing again and again in the upgrade settings page.

The reason was that I had changed the machine names on some existing user fields and Moodle did not like this.

To solve this you have to either:
  •  Access the database of your site with phpMyAdmin and open the mdl_config_plugins table, then set the new machine names of the fields you have changed by changing the "name" column on this table to the correct value (e.g field_lock_profile_field_SCHOOL to field_lock_profile_field_school if you have changed the machine name of the user field to the lower alphabet)
  • Or change back the short names of the user fields you previously changed.
After this, the admin page should be loaded correctly.

In my opinion this is a bug with the auth_ plugins, but that's just my two cents.
Average of ratings: -
In reply to Kyriakos Terzopoulos

Re: Upgrade Settings loop

by sebastian yepes -

Yeah, that was right.

But the way I change back the short names was going to user profile fields and change the first letter, lowercase for capital letters. Thanks a lot, you surely save my job man. Thanks!!!!

Average of ratings: -
In reply to Seth Yoder

Re: Upgrade Settings loop

by Guillermo Dova -

Had the same issue recently while upgrading a 3.5+ moodle.
This are the steps I followed to fix it:

  1. take note of each of the params displayed on the Settings page (the page that loops)
  2. on the database, "mdl_config_plugins" table, on the "name" field, search each of the params.
  3. compare uppercase/lowercase and fix as needed
  4. BACKUP db! just in case.
  5. in my case all the params ended with "_Edad" ("E" as uppercase), but in the table where inserted as "_edad" ("e" as lowercase), so I updated all the records ending as "_edad" to "_Edad". That fixed the problem.
  6. Go back to the settings page, click on "Save", and now it should work.





Average of ratings: Useful (1)