After successfully upgrading 1.8.4 to 4.2 in a test run, I am now working with the latest files and will upgrade to a 4.2 fully operational install in preparation for the 23/24 school year. Right away, I ran into a snag with the admin password. Apparently, someone changed it after my last visit to the school district, and no one was around to ask, so I updated the mdl_user table with the desired admin password and verified it checks out on an md5 password-generating site. However, I am still unable to log in, although I am positive I am using the correct password, yet logs show authentication was unsuccessful. What might be causing this issue? I am on the VM that I used on the test upgrade run, so it surprises me that it's not working.
Try:
$ /path/to/php /path/to/admin/cli/reset_password.php
The reset_password.php script that Mr. V pointed you to works only with manual accounts. Just checked a git acquired 1.8.14 code directory ... sorry, but there is no code/admin/cli/reset_password.php script! 
Matter of fact, no code/admin/cli/ directory. (double )
The first user in mdl_user table created (id 1) was guest user.
The second user in mdl_user table created (id 2) was the user initial installer created for the 'admin' account. 'admin' was the default user, but someone could have changed the account username - ie, no longer 'admin'.
Make a query of the DB mdl_user table:
select firstname,lastname,email,username,auth from mdl_user where id=2;
Not sure that the following will work with that old a moodle, but, there was/is a setting for use with config.php that will allow 'any user' in the mdl_user table to be admin level.
$CFG->siteadmin='2,userid,userid';
Accounts don't have to be manual. If you insesrt that in config.php you don't have to reboot ... just access the site. If Moodle complains, then delete the line from config.php ... and onto plan D - for 'desparate'!
Plan D:
What you might have to do ... if the admin account exist and you know the password for another user - student or teacher - copy the password column data of the known into the password column of the admin account via DB.
Then attempt login as admin with the known password of the other user.
And a question about the contents of config.php ... are there/is there 'password salt' lines?
Plan Double D ...
dpends if you can get an old moosh installed and IF that old version of moosh had the command ... a moosh command for user account manipulation:
user-mod
See:
'SoS', Ken
It is quite possible that the reset_password.php is newer than the Moodle rel. 1.8!
It reminds me that the password hashing had at least two changes: the algorithm has been changed and the a password salt has been introduced (and then removed?). Needs to dive deep.
If that Moodle can send mails, requesting a new password in the log-in page would shortcut all that.
It reminds me that the password hashing had at least two changes: the algorithm has been changed and the a password salt has been introduced (and then removed?). Needs to dive deep.
If that Moodle can send mails, requesting a new password in the log-in page would shortcut all that.
"If that Moodle can send mails, requesting a new password in the log-in page would shortcut all that."
Would think the OP needs to change at least the email address of that user so OP would be able to get the email. Possibly root@localhost.localdomain so that moodle sees it as a valid email address and system won't attempt to send the message to any other mail servers that surely would block due to more modern spam/etc checking.
Then also, possibly installing something like alpine to be able to read root user mail or the old time 'mail' client that came with OS.
Any direction the OP goes with this, there is 'work to work'. :| But that was expected.
'SoS', Ken
One other thought ... the guest account did have data in the password column that equated to a 'blank' password. If guest account wasn't also changed then OP could copy the password data from the guest account into the admin password and login as admin with no password.
Once in as admin could change the admin user password.
Don't mind saying ... this is taxing old timers' memory!
'SoS', Ken
The OP knows how to edit the database directly. His problem is that the MD5 hash doesn't respond.
I'm not sure whether Moodle moved to Bcrypt - if so, get ready for a long goodbye https://it.slashdot.org/story/23/05/25/2351200/a-popular-password-hashing-algorithm-starts-its-long-goodbye.
I'm not sure whether Moodle moved to Bcrypt - if so, get ready for a long goodbye https://it.slashdot.org/story/23/05/25/2351200/a-popular-password-hashing-algorithm-starts-its-long-goodbye.
Was just looking through the config-dist.php file that comes with a 1.8.x.
No debug settings!!!!
That leaves only error logs of web service or the DB server to get clues as to what is going on! More 'work to work'!
'SoS', Ken
Thank you for the replies. I have it working. It seems the few changes needed between 1.8.4 and 1.9 caused the issue. I forgot that I had an epiphany while working through the versions, and I had taken a snapshot of version 1.8.4. I rolled back, and everything is working, so on with the upgrade march.
How exactly did you solve the original problem in this thread, resetting the admin password of a Moodle rel. 1.8?
I rolled the snapshot back to pre-1.9, copied the data back over, and it worked. I believe the issue was the database encoding required for 1.9 that was not needed for 1.8. That is about the only modification I made in preparing for 1.9
Antelope to Barracuda transition? https://docs.moodle.org/27/en/admin/environment/custom_check/unsupported_db_table_row_format
Thank you! I will take a snapshot and look into this next week.
There are some command line only .php scripts in code/admin/cli/ that will help.
Suggest you run the checks.php first to see.
The mysql_ scripts will work with MariaDB.
'SoS', Ken
I have successfully upgraded to 3.10, but unlike during the test run, I am getting PHP errors when moving to the final VM and attempting to upgrade to 3.11 or 4.0
Environment:
Ubuntu 20.04
PHP 8.0.28
mysql Ver 8.0.33
Error:
PHP Fatal error: Uncaught Error: Attempt to assign property "dbtype" on null. If I comment that line out, the error moves to the next line, and so on.
Config.php
<?php /// Moodle Configuration File
unset($CFG);
$CFG->dbtype = 'mysql';
$CFG->dbhost = 'localhost';
$CFG->dbname = 'name';
$CFG->dbuser = 'user';
$CFG->dbpass = 'password';
$CFG->dbpersist = false;
$CFG->prefix = 'mdl_';
$CFG->wwwroot = 'http://moodle.domain.com';
$CFG->dirroot = 'path';
$CFG->dataroot = 'path';
$CFG->admin = 'xxxx';
$CFG->directorypermissions = 00777; // try 02777 on a server in Safe Mode
$CFG->unicodedb = true; // Database is utf8
require_once("$CFG->dirroot/lib/setup.php");
// MAKE SURE WHEN YOU EDIT THIS FILE THAT THERE ARE NO SPACES, BLANK LINES,
// RETURNS, OR ANYTHING ELSE AFTER THE TWO CHARACTERS ON THE NEXT LINE.
?>
Environment:
Ubuntu 20.04
PHP 8.0.28
mysql Ver 8.0.33
Error:
PHP Fatal error: Uncaught Error: Attempt to assign property "dbtype" on null. If I comment that line out, the error moves to the next line, and so on.
Config.php
<?php /// Moodle Configuration File
unset($CFG);
$CFG->dbtype = 'mysql';
$CFG->dbhost = 'localhost';
$CFG->dbname = 'name';
$CFG->dbuser = 'user';
$CFG->dbpass = 'password';
$CFG->dbpersist = false;
$CFG->prefix = 'mdl_';
$CFG->wwwroot = 'http://moodle.domain.com';
$CFG->dirroot = 'path';
$CFG->dataroot = 'path';
$CFG->admin = 'xxxx';
$CFG->directorypermissions = 00777; // try 02777 on a server in Safe Mode
$CFG->unicodedb = true; // Database is utf8
require_once("$CFG->dirroot/lib/setup.php");
// MAKE SURE WHEN YOU EDIT THIS FILE THAT THERE ARE NO SPACES, BLANK LINES,
// RETURNS, OR ANYTHING ELSE AFTER THE TWO CHARACTERS ON THE NEXT LINE.
?>
I fixed this issue by rolling back to PHP 7.4
Looks like my fix only worked on Moodle version 4.0. Moving to 4.2 caused the same issue. My current environment is:
Ubuntu 20.0
PHP 8.1
Mysql 8.0
Same error:
PHP Fatal error: Uncaught Error: Attempt to assign property "dbtype" on null in path/config.php:5
Ubuntu 20.0
PHP 8.1
Mysql 8.0
Same error:
PHP Fatal error: Uncaught Error: Attempt to assign property "dbtype" on null in path/config.php:5
Are you sure that it is $CFG->dbtype = 'mysql' not 'mysqli'?
Side note: $CFG->dirroot = 'path', yeah, one sees that it comes from ancient times. Moodle doesn't need 'dirroot' a decade at least.
Side note: $CFG->dirroot = 'path', yeah, one sees that it comes from ancient times. Moodle doesn't need 'dirroot' a decade at least.
What is $CFG->dbtype= variable in config.php file?
What is on line 5 of config.php?
config.php is very sensitive as to formating .. each line must end with a ';'
The variables enclosed in 'ticks' or 'regular quotes' (not smartquotes).
cd /path/to/moodlecode/admin/cli/
php checks.php
there is also
php check_database_schema.php
What does: mysql -V show
What does php -m |grep mysql show?
DB version was what on previous?
'SoS', Kensystemctl status mysql
mysqladmin -u root -p version
What does my.cnf look like?
I rolled back to PHP 7.4 with Moodle 4.1.3 before I read this post. I will make a snapshot and recreate the 4.2 environment and respond next week. However, the error can be reproduced at each config line, as I commented out the previous offending line. Hence, it leads me to believe it is a parsing issue unrelated to any specific config line. I'll let you know what I learn.
So now we are learning what one should have learned from the 'git' (yes, that's a play on words) go ... using package manager to either downgrade or upgrade. 
So when you finally get this customers site to destination version, will you impress upon them the need to keep their server up-2-date? Or will they wait another 5 years to update/upgrade?
Anyhoo ... this 'saga' is a good example of the trials and tribulations if one wait's too long to update/upgrade!
But, congrats!
'SoS', Ken
So you have 3.10.highest with PHP 8 and MySQL 8 ... right?
See chart:
Min/Max:
For 3.10 PHP min/max 7.2.0 / 7.4
If I was correct in first question, you must now do what you've been trying to avoid ... downgrade the PHP to 7.4 in order to upgrade Moodle from 3.10 to 3.11.highest or 4.0 highest, before the next VM hop!
Actually, I have a server running PHP 7.4.highest and also have Moodle instances of 3.9, 3.10, 3.11, 4.0, and 4.1 on it ... but must upgrade PHP to go any higher.
'SoS', Ken
You are correct. I had to downgrade to PHP 7.4 and it worked up to Moodle 4.0, but now I have moved up to PHP 8.1 for Moodle 4.2, but I am back to the same error message
I was able to move from 4.0 to 4.1 with PHP 7.4 but moving to 4.2 with PHP 8.0 throws the error. looking at PHP settings more closely.
Tried PHP 8.1 and 8.2 . Both throw the same error
I don't get it ... why would one go to 4.2 when:
4.1 (LTS) support ends 8 December 2025
4.2 NOT LTS support ends 7 October 2024
4.1 (LTS) support ends 8 December 2025
4.2 NOT LTS support ends 7 October 2024
Maybe you should inform the customer?
When you finish this fantastic march, it ain't over ... more like tip of an iceburg!
'SoS', Ken
As you said: it is a march. I did not bother to look for the release support dates. The district asked to upgrade the server to the latest release, which was my mission. However, your reply is very welcome, as I suddenly realize I have accomplished that mission with a working install of 4.1.3. That just leaves changing all the media file URLS and moving the files to a SAN (over 1Tb). Your guidance is most appreciated!