I have been asked to recover and upgrade two older versions of Moodle, the 1st being version 1.8.4, which was extensively used. I have the database and files set up, but I am getting various PHP errors, so I cannot get a web login or work with cli upgrades. What would be the best PHP and Ubuntu distro version to overcome the errors, so I can start walking through the upgrade paths?
Phew! 1.8 was a long time ago!
https://docs.moodle.org/20/en/PHP_settings_by_Moodle_version says that the required version of PHP for that version of Moodle is PHP 4.3.0. What version of PHP are you using? You can't use a modern version of PHP with such an old version of Moodle.
Lastly, turn the PHP debugging settings up to developer level (in the php.ini file). Then run Moodle again. You should see some error messages and those might help track down what's wrong.
See:
http://www.syndrega.ch/blog/#php-and-dbms-compatibility-of-major-moodle-releases
problem is not only distro and php version but DB version as well.
PHP Min/Max 4.3.0 5.6
MySQL Min/Max 4.1.16 5.7?
Not sure I'd lease anything on public internet for hosting either. Good chance
site would be hacked even before you could begin the march.
You mentioned you had files ... I assume that also means you had an SQL dump
that you imported into a DB on server.
You might be better off using a local virtualization ..
https://www.osboxes.org/ubuntu/
Scroll down to the bottom of the page linked above to see the oldest offered. One would need to find some page that showed what came with the the distro ... php and MySQL wise.
At some point, in march, you've have to make a full site backup, archive that off,
then install another OSboxes Ubuntu that had PHP/MySQL versions needed. Not sure the repos would be available to do upgrades.
Using /etc/host file trick one could keep its FQDN to that local virt.
(FQDN found in config.php of moodle code).
And another ... addons - how many and which? Versions available for a march?
I'd definitly make the first hop upwards to highest 1.8.x via GIT - then use GIT for the steps in the march.
And yet another ... space ... once you have been successful with a step and things check out, a site backup - code + DB dump + moodledata - which with versions prior to version 2 used course ID numbers in moodledata per course.
'SoS', Ken
Yes, the system software not only have minimum versions but also maximum versions. Watch the 'max.' columns in http://www.syndrega.ch/blog/#php-and-dbms-compatibility-of-major-moodle-releases.
About the "files", in Moodle 1.x the uploaded files were in sub-directories named after the course IDs they belong to. Moodle 2.x introduced the "encrypted" directory structure called Repositories.
Also take the footnote 3) in that chart, "Upgrade from 1.9 to 2.x broke so many things, it is advisable to rebuild the site - either through course backups and restore or create courses from scratch making use of the numerous new features added since then." to your heart. ;)
This only gets worse!
"... either through course backups ..."
First, have to stand up a vulnerable 1.8.highest - just to look at courses. Then make no user backups which also exclude any block/mod/etc. that no longer exist in newer versions of Moodle. Can't use CLI - no cli scripts in 1.8 or 1.9 ... they first appeared in 2.0.
Alt of using moosh - also iffy ... it's earliest https://moodle.org/plugins/pluginversion.php?id=11982
which supported 1.9 -> 3.1
Again, I wouldn't try to stand up a 1.8.x on a remotely hosted environment that's accessible via internet ... a Virtualbox OSTubes version of Ubuntu that had the PHP/MySQL requirements to run a 1.8/1.9 is the safest ... period! Imagine getting hacked while your marching (git, BTW, would make that more difficult).
Used to be that within the first 5 minutes of a server being on the internet it had it's first poke and probe. That's now down to the first minute ... it's 'game on' for those bots that would do harm from then on - and while attacking vulnerable version of PHP might be the first attempt, there were/are also other vulnerabilities that don't require a web site and no local access required to exploit!
I'd be surprised if any hosting company would allow their customers to install vulnerable OS's/Apps ... even on a VPS ... as that would pose a threat to all customers on that hosting providers network!
For rebuild route ... best options ... stand up a VB/OStubes 1.8 version on local host only. Stand up a 3.9.highest on public internet via git ... and manually rebuild the courses on the 3.9 site (that version is still supported for security fixes only). After that is complete, use git to march to whatever version desired that's higher.
My 2 cents!
Project time line - who knows!
'SoS', Ken
Yes, got that ... here we go ...
Moodle 1.8 PHP Min 4.3.0 Max 5.6 MySQL ONLY (no MariaDB exist for) Min 4.1.16 Max 5.7?
Note the ?
For you chosen distro - you want to use the highest Ubuntu but find repos for
lower version of PHP. If you were to use MySQL's own repo for Ubuntu, no sweat me thinks.
5.5, 5.6, *5.7*?, 8.0 supported
PHP different story on Ubuntu due to repos and your desired higher LTS version of Ubuntu.
"Add the Ondřej Surý PPA. The Ondřej Surý PPA is a Personal Package Archive that contains the latest versions of PHP."
Now that's PHP for web and PHP-CLI and required extensions to run Moodle.
Other references:
https://www.liquidweb.com/kb/install-multiple-php-versions-on-ubuntu-16-04/
https://vitux.com/how-to-install-php5-phpn-ubuntu/
Above covers PHP 5.6 on Ubuntu 22.04 LTS
Above , allow you to setup the 1.8 where you could at least see the GUI.
If one can do that, then - admin - server - environment - update component.
If that exist in 1.8 ... and use the drop down moodle version in pick list to see
what moodle says you need and when.
*Begin with the end in mind* - before standing that up or while:
1. use a valid FQDN - even if internal DNS only. See what config.php file has.
2. That far back, moodle sites could be run with http:// rather than expected and needed https:// today so you'd need a valid certificate for server ... even IF running in internal LAN/WAN only. To get a valid CA, server has to talk to outside CA. You could run self-signed cert for a while - until it's decided to access from outside the private network.
When you get those working, then and only then try to restore the 1.8.
If success doing that ... first thing I'd do is side load a git acquired code and update the 1.8 to the highest 1.8 via git.
Git is *by far* the best way to march a moodle from older version to higher version. Git is *by far* the best way to march a moodle from older version to higher version. Git is *by far* the best way to march a moodle from older version to higher version.
Yes, I repeated that!
You still have to look at themes and addons - compat with destination versions.
Auth of users ... all manual? or was site using internal LDAP (guess there).
Internal only will still require inside out access to repos - ability to pull in things from public internet.
Guess you'll have a VPN to your internal network to be able to work on this project beyond the normal working hours ... or work late for X days.
Doable - but unless you prepare to the hilt and research everything, potential for frustration.
On this internal server ... would be nice if it were guest OS to something like VMWare cause you could bump memory easily (min memory 8 gig). Space is a different story - got to have enough space for Moodle data AND especially full site backups so you can save what you've gained if the next hop upwards fails due to human error!
Also PHP tweaks ahead - max time to execute from 30 to say 120, max memory to consume from default to max. max_allowed_packets - at least 5000.
You'll also have to make MySQL changes at one point to Barricuda, character set utf8mb4 with collation utf8mb4_unicode_ci. Note: there are, eventually, in moodlecode/admin/cli/ that will help with those.
Fun and games! Should keep you occupied for some time.
'SoS', Ken
> Moodle 1.8 PHP Min 4.3.0 Max 5.6 MySQL ONLY (no MariaDB exist for) Min 4.1.16 Max 5.7?
>
It is because I don't have official sources to back up the claim. Rather this MySQL 5.7 was either my own observation or picked up from moodle.org discussions.
Talking of PHP, you'll see certain releases excel in Moodle longevity. For example PHP 5.6 was capable of powering Moodle 1.6 to to 3.2! (May be even more.) Life was quieter then.
Dancing in the streets here!! I'm in!
Created a new VM with Ubuntu 9.04 I386 server, and after recreating the directory structure, setting permissions, etc., I can log in and see all the courses and users.
The PHP version is, by default, 5.2, but it seems to be working. I will know more as I start upgrading.
Question: what's the VM? (VMWare?)
Congrats! But ... 'tip of iceburg' ... i386 versions are 32 bit - not 64 bit. Moodle won't check for that and if courses are 4 Gig or larger full course backups will fail - no, Moodle cannot be made to circumvent that for full course backups - neither can your VM.
Question: can you install git via package manager?
What is version of MySQL? Back then, Moodle supported only MySQL and Postgress7 - according to config-dist.php file in latest git acquired 1.8.
How are your mysql client skills?
You can gather some useful info by making some simply mysql client queries of tables: mdl_user, mdl_courses, mdl_config_plugins (if that exist).
And one can also see just how large moodledata really is:
du -h /path/to/moodledata
Anyhoo ... the 'adventure begins!'
'SoS', Ken
moodle18.mdl_block_search_documents
Error : Incorrect information in file: './moodle18/mdl_block_search_documents.frm'
error : Corrupt
moodle18.mdl_sessions2
Error : Incorrect information in file: './moodle18/mdl_sessions2.frm'
error : Corrupt
Also, the data folder is 7.2 Gb
I think I will create a new post for the upgrade process.
If you start a new thread make sure you fully disclose ... EVERYTHING.
For the sessions table ... could try this
add a line to config.php flie:
$CFG->dbsessions='0';
That should use moodledata/sessions/ directory with files rather than DB.
Not sure about mdl_block_search_documents but one might be able to truncate that table and, hopefully, moodle will, on run of cron job repopulate.
Uhhh ... you do have cron setup to run every minute ... correct? That's not done in moodle admin interface, but in OS crontab.
Me thinks you are in for many, many, more 'side adventures' - no offense, wouldn't wanna be ya! :|
'SoS', Ken
FYI - that block for search has 'dependencies' to function!
blocks in core of that version
activity_modules glossary_random participants
admin html quiz_results
admin_bookmarks index.html recent_activity
admin_tree loancalc rss_client
blog_menu login *search*
blog_tags mentees search_forums
calendar_month messages section_links
calendar_upcoming mnet_hosts site_main_menu
course_list moodleblock.class.php social_activities
course_summary news_items version.php
db online_users
This block instanciates a startup database model for the search engine.
## Installing
You need installing the following elements in order the global search to be available :
1. The global search bloc (this block)
2. update the /search root package from CVS
3. The antiword libraries
4. The xpdf libraries
Both last libraries are provided as a patch called "global_search_libraries" in the contrib section.'
I don't ask questions for fun ... will repeat ... can you install git?
Oh what fun this will be! [NOT!]
'SoS', Ken
Did you march the whole site with users or only the course content?
How about the format change in the Assignment activity somewhere Moodle 2.2?
Did you really need 4 VMs? Could you tell us which distribution, which versions? And also the exact march route?
However, this was only my first run at the upgrade attempt. Now that everything is in place, I will retrieve the latest school district data and rerun the process. Having the servers in place (not having to mess with php versions and features) will make that a much faster process.
Moodle 1.8.4-1.9.19
Ubuntu 9.0.4 (jaunty)
PHP 5.2.6
MYSQL 5.0.75
Moodle 2.0 - Moodle 3.3.1
Ubuntu 18.04 (bionic)
PHP 5.6.4
MYSQL 5.7
Moodle 3.4.1 - Moodle 3.10.1
Ubuntu 18.04 (bionic)
PHP 7.4.3
Added ondrej-ubuntu-php-bionic.list repository, allowing the upgrade of PHP versions.
MYSQL 5.7.4
Moodle 4.0.2 - Moodle 4.2.0
Ubuntu 20.04 (focal)
PHP 8.1.8
MYSQL 8.0.3
Thank you for your quick answer.
We choose 4.1 because it's an LTS and we plan to keep it to the next LTS and so on. In documentation 4.1 support 7.4, 8.0 and 8.1. We would probably install php 8.1.X. But after upgrading Moodle.
You accomplish something impressing. And made me relativate the big jump from 3.9 to 4.1 : ).
Docker could be useful in this scenario
https://dev.to/oracle2025/get-a-legacy-php-53-application-running-in-docker-1cb2