Trying to upgrade from 3.3.1 to 3.3.2 and I get this error:
Debug info: Table 'aslwithr_lhhs.lhhs_oauth2_system_account' doesn't exist
ALTER TABLE lhhs_oauth2_system_account MODIFY COLUMN email LONGTEXT CHARACTER SET utf8 COLLATE utf8_general_ci NULL after grantedscopes
Error code: ddlexecuteerror
I have another moodle that I upgraded from 3.3 to 3.3.2 with no problem on the same server. What could be the cause and how do I fix?
Thanks!
And a related question -
I've backed up the previous installation. But it never installed the upgrade. So can I just delete the upgrade php (or whatever) and have it just stay as-is? My students can still access the moodle just fine, but I can't because when I login it immediately takes me to the upgrade screen.
The upgrade issue will take some time/investigation, etc. The infinite loop in updating plugins can be bypassed now by using an sos.html file in moodlecode/local/
It's a static plain old pre formated html page with nothing but relative links to areas in moodle directly.
Attached is sos.txt which is really sos.html.
What you might have to figure out are the direct urls to areas you need to get to.
Once logged on and thrown to updating plugins, your browser has a cookie and you really can open another browser, use the url line to go directly to http://yoursite/local/sos.html.
Links in sos.html point to other admin areas of Moodle by direct realative links from local. Those areas still require an access level.
Here's what one looks like:
< a href= "./admin/settings.php?section=debugging" target="_new" > ./admin/settings debugging < / >
Broken here with spaces, etc. so it's viewable.
'spirit of sharing', Ken
What are authentication methods used for whom?
Direct URL to authenticatons:
/admin/category.php?category=authsettings
Setting for Oath2
/admin/settings.php?section=authsettingoauth2
'spirit of sharing', Ken
Follow up ... URL to Oauth2 setups
/admin/tool/oauth2/issuers.php
Those that are configured and working show all green checks.
'spirit of sharing', Ken
What are the DB settings for character set and collation?
"CHARACTER SET utf8 COLLATE utf8_general_ci" in what is reported as an error.
Please see:
https://docs.moodle.org/33/en/MySQL_full_unicode_support
'spirit of sharing', Ken
Thank you for all the help. I had to make a decision between trying to fix the problem or reverting back to a previous working version. Because this is a "live" version that my students use regularly I couldn't risk things breaking until such a time that I have enough time to fix it.
I would like to install the latest working version if at all possible. I have two running versions of Moodle. Both of them installed on the same server on the same day with no extra plugins, or custom changes, etc. One upgraded just fine, the other obviously did not.
On a whim, I did try something -
With moodle #2 (the one that won't upgrade) I cannot duplicate activities. Any time I try to do so I get an error:
Seeing as you are having more than one issue, it is most possible that they are related. I would start by checking permissions on your folders and on your database. Make sure that the config.php file is correctly reading from the correct database and that you didn't inadvertently copy the config file from the wrong moodle over.
I would try a restart of the database server as well. You could also try a new upgrade on the one that is not working and see if that resolves anything. Preferably a one week newer version to prompt an actual upgrade. Failing that, the next step would be to restore back to prior to the initial upgrade and start again.
Please see:
https://docs.moodle.org/31/en/error/moodle/dmlreadexception
2 moodles on same server using the same DB server could develop issues in only one instance *IF* there is a difference in the moodle implemations setups. I speak from experience there - have a 'sandbox' server with 3.1, 3.2, and 3.3 ... and original 3.0's that am 'marching upwards' to latest greatest as test. Not bragging here ... just relating experiences and am aware that there are differences and requirements for 3.3 for DB that if not implemented prior to upgrade attempt might come into play.
Googling for dmlreadexception
https://www.google.com/search?q=dmlreadexception&ie=utf-8&oe=utf-8
one sees multiple hits ... some here in these forums ... resolutions may or may not be present ... and may not relate to the issues you are seeing with the authentications.
The link above says to turn on debugging all the way to developer and then share back what moodle is saying - the stack trace. Since you've reverted back to working version that may not show what you need to see.
Maybe you could view your apache error logs from the day of the upgrade attempt to see if there is some hint/clue in those?
Are both using the same authentication methods?
Are both instances databases using the same character set/collation as there is now a change in 3.3 that will in the future become the standard ... utf8mb4
Please see:
https://docs.moodle.org/33/en/MySQL_full_unicode_support
Have you run the environment checks (update the component before reporting what that check says) on both instances to see if one is reporting there needs to be a change in DB?
Then there is the upgrade method ... how are you upgrading? Via new code/FTP etc. etc. old method?
Where hosted? Is there some sort of hosting restriction that might be a factor?
And finally, what operating system? Ok, call me a Linux bigot ... but think that sometimes is a factor in things like upgrading. ;)
Can you setup a sandbox implementation that's a clone of the instance having issues on the same server (better as you would be using the same environment). A sandbox clone you wouldn't have to worry about ... could turn on debugging to the hilt ... try the upgrade ... and report back any details to that here.
'spirit of sharing', Ken