Moodle Upgrade from 3.5.1 to 3.6.x or 3.7.x

Moodle Upgrade from 3.5.1 to 3.6.x or 3.7.x

by Key Learning Centre -
Number of replies: 35

Hi there,

I'm planning to upgrade our moodle site from 3.5.1+ to 3.6.4 or latest 3.7.x. I'm guessing I have to upgrade php as well if I go for 3.7.x

1. I'm looking for steps that I should follow to do the upgrade safely. Please include if there is any difference for 3.6.4 and 3.7.x.

2. Also any guidelines, suggestions or recommendations that I should take care of before upgrade.

I'll be very grateful, Thanks

Average of ratings: -
In reply to Key Learning Centre

Re: Moodle Upgrade from 3.5.1 to 3.6.x or 3.7.x

by Howard Miller -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
You don't say which version of PHP you are currently using so it's hard to comment on PHP. Both 3.5 and 3.7 should work fine with 7.1+ so you should probably upgrade PHP first if you need to. All else being equal you would be better upgrading to the latest stable version of Moodle. That is 3.7. (It'll be 3.7.1 by the time you get to it)

1 & 2. See Upgrading

PS. Please consider changing your profile to reflect your *real* name. We really like to know who we are talking to wink
Average of ratings: Useful (2)
In reply to Howard Miller

Re: Moodle Upgrade from 3.5.1 to 3.6.x or 3.7.x

by Key Learning Centre -
Hi and thanks Howard for your reply, I will be using Git to upgrade Moodle based on the basic research I found out that will be more easier and faster.

Currently I am running PHP 7.0. Do I have to upgrade PHP first or Will Git take care of upgrading that as well. I am new to git, so looking for some guidelines for that too.
In reply to Key Learning Centre

Re: Moodle Upgrade from 3.5.1 to 3.6.x or 3.7.x

by Howard Miller -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
No... you will need to upgrade PHP separately. How, depends on your operating system and how PHP was installed in the first place. Upgrade to PHP 7.2 *first*. Moodle 3.5 is not compatible with the latest PHP 7.3 and Moodle 3.7 is not compatible with PHP 7.0!!

Git is for source control. It doesn't help much at all when jumping between major versions but is really useful if you have customisations (i.e. optional plugins) and you are updating on the same branch. It's also useful to deploy Moodle if you have tested a version in a different place and then transferred to production. Other than those use cases, I wouldn't bother. It's another layer of hassle you don't need.
Average of ratings: Useful (2)
In reply to Howard Miller

Re: Moodle Upgrade from 3.5.1 to 3.6.x or 3.7.x

by Key Learning Centre -

Hi,

What is the easiest and safest way to install PHP 7.2? Also I observed that the Ubuntu server I am running is 16.04 LTS, should I upgrade my Ubuntu first which already includes PHP7.2 in the process?
Please advise. 

Thanks

In reply to Key Learning Centre

Re: Moodle Upgrade from 3.5.1 to 3.6.x or 3.7.x

by Ken Task -
Picture of Particularly helpful Moodlers

Well, looks like am gonna go first on this one ... but will defer to Howard as he has more experience with Ubuntu.

Please read:

https://www.liquidweb.com/kb/how-to-upgrade-ubuntu-16-04-to-ubuntu-18-04/

(as good as any how-2 maybe).

Comment: in reading forum postings ... other forums about Ubuntu ... some say above worked flawlessly and others had serious issues.   Question I would ask myself ... just how 'game am I?' and 2 ... how much time do I have to spend on this?

IF you could make full backups of the moodle you have and archive those backups, couldn't you just wipe out what you have and install fresh 18.04 in it's place ... install apache/mysql/php get FQDN and a cert ... get that running ... then restore your moodle backup?

2 cents worth!

'SoS', Ken



Average of ratings: Useful (1)
In reply to Ken Task

Re: Moodle Upgrade from 3.5.1 to 3.6.x or 3.7.x

by Key Learning Centre -
Thanks for your response.

During my research on this I have found there are some folders that I have to move back from old (moodle.backup) to the new moodle folder.

Like I have keycourses, images etc. I have lots of courses and many plugins too (Not worried about plugins as the basic with new upgrade will still do the job, alternatively I will install them back or install the alternate plugin).

Can you please enlist what folders should I move back after the upgrade is done? Please advise. Thanks
In reply to Key Learning Centre

Re: Moodle Upgrade from 3.5.1 to 3.6.x or 3.7.x

by Ken Task -
Picture of Particularly helpful Moodlers

Don't understand the question .... 'what folders to move back?'!!!

My definition of where moodle code resides: .... where one finds the config.php and main (top level) version.php file.

Example: /var/www/html/moodle meets definition ... tar ball of /var/www/html/moodle is a backup of moodle code.

If you make a backup of the moodle code whatever folders/files are in the directory where the moodle code resides would have all the folders/files one would need to restore.

Complete backup of Moodle would be moodle code, moodledata, and an sql dump of the DB for moodle.

If you had symlinks in moodledata/repository/ those symlinked folders would need to be backed up as a separate tar ball.

If you had symlinks in the directory containing the moodle code ...  ditto.

tar will not follow symlinks.

'SoS', Ken


Average of ratings: Useful (1)
In reply to Ken Task

Re: Moodle Upgrade from 3.5.1 to 3.6.x or 3.7.x

by Key Learning Centre -
Where you mentioned: 'If you make a backup of the moodle code whatever folders/files are in the directory where the moodle code resides would have all the folders/files one would need to restore.'

Did you mean after upgrade to the new version of moodle which will create another 'moodle' (new) folder, I don't have to restore back any folders from old moodle folder to the new?

Our past moodle admin suggested to migrate back some folders after upgrade like keycourses, images folders etc. Is this needed? We wanna make sure everything remains the same like courses, plugins, settings etc. except the version of moodle, PHP should get upgraded.
Thanks
In reply to Key Learning Centre

Re: Moodle Upgrade from 3.5.1 to 3.6.x or 3.7.x

by Ken Task -
Picture of Particularly helpful Moodlers

Thought you were using/going to use git to maintain core code?   IF you do, code directory stays where it is ... including any additional directories you have inside the moodle code directory.    Nothing need be moved away or out ... nor back in.

A git pull gets updated core code ... that's all.

Where you see the config.php file, do you have a .git (note the dot in front) directory?

ls -1a

in that directory will also show not only the hidden .git directory but other hidden files:

Text listing of a 3.6

.eslintignore
.eslintrc
.gherkin-lintrc
.git
.gitattributes
.gitignore
.jshintrc
.shifter.json
.stylelintignore
.stylelintrc
.travis.yml
CONTRIBUTING.txt
COPYING.txt
Gruntfile.js
INSTALL.txt
PULL_REQUEST_TEMPLATE.txt
README.txt
TRADEMARK.txt
admin
analytics
auth
availability
backup
badges
behat.yml.dist
blocks
blog
brokenfile.php
cache
calendar
cohort
comment
competency
completion
composer.json
composer.lock
config-dist.php
course
dataformat
draftfile.php
enrol
error
file.php
files
filter
grade
group
help.php
help_ajax.php
index.php
install
install.php
iplookup
lang
lib
local
login
media
message
mnet
mod
my
notes
npm-shrinkwrap.json
package.json
phpunit.xml.dist
pix
plagiarism
pluginfile.php
portfolio
privacy
question
rating
report
repository
rss
search
tag
theme
user
userpix
version.php
webservice

'SoS', Ken



Average of ratings: Useful (1)
In reply to Ken Task

Re: Moodle Upgrade from 3.5.1 to 3.6.x or 3.7.x

by Key Learning Centre -
Yes! you are right, thanks. I do see .git folder and other . hidden files.

Ok, so after backup and putting site to maintenance, I will go inside my /var/www/moodle directory (code directory) and do git pull. Do I have to change the git branch to the version I want to upgrade to? OR does git automatically upgrade to the latest (according to git shortlog) during git pull?
In reply to Key Learning Centre

Re: Moodle Upgrade from 3.5.1 to 3.6.x or 3.7.x

by Ken Task -
Picture of Particularly helpful Moodlers

First, you have quite a few of us responding ... all responses are good ... might be getting harder for you to prioritize.

Here's official Moodle doc on git:

https://docs.moodle.org/37/en/Git_for_Administrators

There they show a -b option used.  That restricts to one branch and think you want the ability to update current code/branch ... which is what a git pull would do.

You'd also want to be able to upgrade ... like from 3.5.highest to 3.6.highest.

To upgrade ...

# git branch --track MOODLE_36_STABLE origin/MOODLE_36_STABLE;
# git checkout MOODLE_36_STABLE;

if you do a git branch -a at this point, the * should be on MOODLE_36_STABLE and to verify in code directory:

fgrep '$release' version.php

to actually perform the upgrade:

# php admin/cli/upgrade.php non-interactive;

Since you are looking at upgrading your OS also recommend not trying too much stuff at the same time.

You should probably double check requirements for 3.7 ... DB version character set/collations and PHP version, etc.

Use moodles Server -> Environment update component for a roadmap/plan.

But will stress ... full site backup!!! and archival of that full site backup off onto some other storage that you can access with new server.

My 2 cents.

'SoS', Ken

Average of ratings: Useful (1)
In reply to Ken Task

Re: Moodle Upgrade from 3.5.1 to 3.6.x or 3.7.x

by Key Learning Centre -
Thanks for your response, very helpful. btw I am seeing:
fgrep '$release' version.php
$release = '3.5.1+ (Build: 20180810)'; // Human-friendly version name
So do you suggest branch to 3.7 straight away or should I do 3.6 first, test and backup and then go to 3.7 branch git pull?
In reply to Key Learning Centre

Re: Moodle Upgrade from 3.5.1 to 3.6.x or 3.7.x

by Ken Task -
Picture of Particularly helpful Moodlers

Might be dis-agreement here ... but since git updates or upgrades don't take very long to do, I have a preference for a 'march' ... 3.5.1 to 3.5.highest - that with git pull.  Backup. Check.  Then upgrade ... 3.5.highest to 3.6.highest ... that done with setting branch track.  Upgrade DB via admin/cli/.

At that point might want check environment again ... any 'reds' when choosing 3.7?    Fix.

Backup.

Then upgrade again ... 3.6.highest to 3.7.highest via git.  Check. Ok?  Then backup.  Since you've checked and everything working don't think you'll be restoring the 3.5.x version ... remove backups made for 3.5.x.  And since one doesn't 'roll back' easily (but restore) and you checked the site after upgrading to 3.7.highest, really no reason to keep the 3.6.x backups.

As long as you are on 3.7.x, make daily backups of DB, rsync moodledata/filedir ... once a month or so, check space used by those daily backups of DB ... since I make backups with date/time stamps in filenames and this is July I no longer need any June daily dump.

Last thing you want is for the backups to fill up drive where the active databases live.   Best to save backups to an attached device/drive with plenty of room - that could be a mounted backup box directory.  That's *your* homework! smile

Once the dust settles, you won't be doing this sort of thing often ... and you've had plenty of practice at backups and updates/upgrades.   Just try not to wait 2 or 3 or 4 versions of Moodle before upgrading again.

Again ... my 2 cents. smile

'SoS', Ken

Average of ratings: Useful (1)
In reply to Ken Task

Re: Moodle Upgrade from 3.5.1 to 3.6.x or 3.7.x

by Howard Miller -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
It shouldn't matter - excepting the requirements for a particular Moodle version - but you should definitely always use the latest version (i.e. the weekly build of whatever branch it is) to upgrade to. This guarantees that you have any fixes that may have been made in the upgrade code.
Average of ratings: Useful (2)
In reply to Howard Miller

Re: Moodle Upgrade from 3.5.1 to 3.6.x or 3.7.x

by Key Learning Centre -
So you are saying that I can straight away go from 3.5.1 to 3.7 latest, right?
In reply to Key Learning Centre

Re: Moodle Upgrade from 3.5.1 to 3.6.x or 3.7.x

by Ken Task -
Picture of Particularly helpful Moodlers

In your current 3.5.1 server, go to Server -> Environment check - update the component.   Set dropdown pick list to 3.7 of Moodle.   Read what resulting page says. smile

What info have you collected on the requirements for 3.7.x?

While everyone that has responded has helped ... time for you to take some ownership here, don't ya thimk?

No offense! smile

'SoS', Ken

In reply to Key Learning Centre

Re: Moodle Upgrade from 3.5.1 to 3.6.x or 3.7.x

by Howard Miller -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Yep - but you need to take backups and you need to read the release notes

https://docs.moodle.org/dev/Moodle_3.6_release_notes
https://docs.moodle.org/dev/Moodle_3.7_release_notes

...and make sure you won't have any issues with requirements.

Coincidentally, I'm just about to do exactly that on 40,000 user site. It's been 3 months in the planning wink
Average of ratings: Useful (1)
In reply to Howard Miller

Re: Moodle Upgrade from 3.5.1 to 3.6.x or 3.7.x

by Ken Task -
Picture of Particularly helpful Moodlers

Ahhhh ....yes!

Might be old but still true:

'Plan your work. Work your plan.'

Maybe 'KLC Support' should write up a 'plan' ... simple text file would do - steps he/she plans to do ... and in order of priority? (even though some steps could be done in different order [depending])

'SoS', Ken




In reply to Ken Task

Re: Moodle Upgrade from 3.5.1 to 3.6.x or 3.7.x

by Key Learning Centre -
Everyone's response is very useful and I'm really learning a lot through this forum, you guys are gem... respect. I've planned to do this upgrade project this Friday, will keep you guys posted.
Big thanks to all...
In reply to Ken Task

Re: Moodle Upgrade from 3.5.1 to 3.6.x or 3.7.x

by Howard Miller -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
To be honest, I would just upgrade Ubuntu if you're running 16.04. Probably quicker in the long run.
Average of ratings: Useful (3)
In reply to Howard Miller

Re: Moodle Upgrade from 3.5.1 to 3.6.x or 3.7.x

by Key Learning Centre -
Hi,

I upgraded ubuntu from 16.04 LTS to 18.04 LTS and after upgrade it shows me this page:
<?php
// This file is part of Moodle - http://moodle.org/
//
// Moodle is free software: you can redistribute it and/or modify
// it under the terms of the GNU General Public License as published by
// the Free Software Foundation, either version 3 of the License, or
// (at your option) any later version.
//
// Moodle is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
// GNU General Public License for more details.
//
// You should have received a copy of the GNU General Public License
// along with Moodle. If not, see .

/**
* Moodle frontpage.
*
* @package core
* @copyright 1999 onwards Martin Dougiamas (http://dougiamas.com)
* @license http://www.gnu.org/copyleft/gpl.html GNU GPL v3 or later
*/

if (!file_exists('./config.php')) {
header('Location: install.php');
die;
}

require_once('config.php');
require_once($CFG->dirroot .'/course/lib.php');
require_once($CFG->libdir .'/filelib.php');

redirect_if_major_upgrade_required();

$urlparams = array();
if (!empty($CFG->defaulthomepage) && ($CFG->defaulthomepage == HOMEPAGE_MY) && optional_param('redirect', 1, PARAM_BOOL) === 0) {
$urlparams['redirect'] = 0;
}
$PAGE->set_url('/', $urlparams);
$PAGE->set_pagelayout('frontpage');
$PAGE->set_other_editing_capability('moodle/course:update');
$PAGE->set_other_editing_capability('moodle/course:manageactivities');
$PAGE->set_other_editing_capability('moodle/course:activityvisibility');

// Prevent caching of this page to stop confusion when changing page after making AJAX changes.
$PAGE->set_cacheable(false);

require_course_login($SITE);

$hasmaintenanceaccess = has_capability('moodle/site:maintenanceaccess', context_system::instance());

// If the site is currently under maintenance, then print a message.
if (!empty($CFG->maintenance_enabled) and !$hasmaintenanceaccess) {
print_maintenance_message();
}

$hassiteconfig = has_capability('moodle/site:config', context_system::instance());

if ($hassiteconfig && moodle_needs_upgrading()) {
redirect($CFG->wwwroot .'/'. $CFG->admin .'/index.php');
}

// If site registration needs updating, redirect.
\core\hub\registration::registration_reminder('/index.php');

if (get_home_page() != HOMEPAGE_SITE) {
// Redirect logged-in users to My Moodle overview if required.
$redirect = optional_param('redirect', 1, PARAM_BOOL);
if (optional_param('setdefaulthome', false, PARAM_BOOL)) {
set_user_preference('user_home_page_preference', HOMEPAGE_SITE);
} else if (!empty($CFG->defaulthomepage) && ($CFG->defaulthomepage == HOMEPAGE_MY) && $redirect === 1) {
redirect($CFG->wwwroot .'/my/');
} else if (!empty($CFG->defaulthomepage) && ($CFG->defaulthomepage == HOMEPAGE_USER)) {
$frontpagenode = $PAGE->settingsnav->find('frontpage', null);
if ($frontpagenode) {
$frontpagenode->add(
get_string('makethismyhome'),
new moodle_url('/', array('setdefaulthome' => true)),
navigation_node::TYPE_SETTING);
} else {
$frontpagenode = $PAGE->settingsnav->add(get_string('frontpagesettings'), null, navigation_node::TYPE_SETTING, null);
$frontpagenode->force_open();
$frontpagenode->add(get_string('makethismyhome'),
new moodle_url('/', array('setdefaulthome' => true)),
navigation_node::TYPE_SETTING);
}
}
}

// Trigger event.
course_view(context_course::instance(SITEID));

// If the hub plugin is installed then we let it take over the homepage here.
if (file_exists($CFG->dirroot.'/local/hub/lib.php') and get_config('local_hub', 'hubenabled')) {
require_once($CFG->dirroot.'/local/hub/lib.php');
$hub = new local_hub();
$continue = $hub->display_homepage();
// Function display_homepage() returns true if the hub home page is not displayed
// ...mostly when search form is not displayed for not logged users.
if (empty($continue)) {
exit;
}
}

$PAGE->set_pagetype('site-index');
$PAGE->set_docs_path('');
$editing = $PAGE->user_is_editing();
$PAGE->set_title($SITE->fullname);
$PAGE->set_heading($SITE->fullname);
$courserenderer = $PAGE->get_renderer('core', 'course');
echo $OUTPUT->header();

// Print Section or custom info.
$siteformatoptions = course_get_format($SITE)->get_format_options();
$modinfo = get_fast_modinfo($SITE);
$modnames = get_module_types_names();
$modnamesplural = get_module_types_names(true);
$modnamesused = $modinfo->get_used_module_names();
$mods = $modinfo->get_cms();

if (!empty($CFG->customfrontpageinclude)) {
include($CFG->customfrontpageinclude);

} else if ($siteformatoptions['numsections'] > 0) {
if ($editing) {
// Make sure section with number 1 exists.
course_create_sections_if_missing($SITE, 1);
// Re-request modinfo in case section was created.
$modinfo = get_fast_modinfo($SITE);
}
$section = $modinfo->get_section_info(1);
if (($section && (!empty($modinfo->sections[1]) or !empty($section->summary))) or $editing) {
echo $OUTPUT->box_start('generalbox sitetopic');

// If currently moving a file then show the current clipboard.
if (ismoving($SITE->id)) {
$stractivityclipboard = strip_tags(get_string('activityclipboard', '', $USER->activitycopyname));
echo '

';
echo "$stractivityclipboard  (";
echo get_string('cancel') . '
)';
echo '

';
}

$context = context_course::instance(SITEID);

// If the section name is set we show it.
if (trim($section->name) !== '') {
echo $OUTPUT->heading(
format_string($section->name, true, array('context' => $context)),
2,
'sectionname'
);
}

$summarytext = file_rewrite_pluginfile_urls($section->summary,
'pluginfile.php',
$context->id,
'course',
'section',
$section->id);
$summaryformatoptions = new stdClass();
$summaryformatoptions->noclean = true;
$summaryformatoptions->overflowdiv = true;

echo format_text($summarytext, $section->summaryformat, $summaryformatoptions);

if ($editing && has_capability('moodle/course:update', $context)) {
$streditsummary = get_string('editsummary');
echo " " href=\"course/editsection.php?id=$section->id\">" . $OUTPUT->pix_icon('t/edit', $streditsummary) .
"

";
}

$courserenderer = $PAGE->get_renderer('core', 'course');
echo $courserenderer->course_section_cm_list($SITE, $section);

echo $courserenderer->course_section_add_cm_control($SITE, $section->section);
echo $OUTPUT->box_end();
}
}
// Include course AJAX.
include_course_ajax($SITE, $modnamesused);

if (isloggedin() and !isguestuser() and isset($CFG->frontpageloggedin)) {
$frontpagelayout = $CFG->frontpageloggedin;
} else {
$frontpagelayout = $CFG->frontpage;
}

foreach (explode(',', $frontpagelayout) as $v) {
switch ($v) {
// Display the main part of the front page.
case FRONTPAGENEWS:
if ($SITE->newsitems) {
// Print forums only when needed.
require_once($CFG->dirroot .'/mod/forum/lib.php');

if (! $newsforum = forum_get_course_forum($SITE->id, 'news')) {
print_error('cannotfindorcreateforum', 'forum');
}

// Fetch news forum context for proper filtering to happen.
$newsforumcm = get_coursemodule_from_instance('forum', $newsforum->id, $SITE->id, false, MUST_EXIST);
$newsforumcontext = context_module::instance($newsforumcm->id, MUST_EXIST);

$forumname = format_string($newsforum->name, true, array('context' => $newsforumcontext));
echo html_writer::link('#skipsitenews',
get_string('skipa', 'access', core_text::strtolower(strip_tags($forumname))),
array('class' => 'skip-block skip'));

// Wraps site news forum in div container.
echo html_writer::start_tag('div', array('id' => 'site-news-forum'));

if (isloggedin()) {
$SESSION->fromdiscussion = $CFG->wwwroot;
$subtext = '';
if (\mod_forum\subscriptions::is_subscribed($USER->id, $newsforum)) {
if (!\mod_forum\subscriptions::is_forcesubscribed($newsforum)) {
$subtext = get_string('unsubscribe', 'forum');
}
} else {
$subtext = get_string('subscribe', 'forum');
}
echo $OUTPUT->heading($forumname);
$suburl = new moodle_url('/mod/forum/subscribe.php', array('id' => $newsforum->id, 'sesskey' => sesskey()));
echo html_writer::tag('div', html_writer::link($suburl, $subtext), array('class' => 'subscribelink'));
} else {
echo $OUTPUT->heading($forumname);
}

forum_print_latest_discussions($SITE, $newsforum, $SITE->newsitems, 'plain', 'p.modified DESC');

// End site news forum div container.
echo html_writer::end_tag('div');

echo html_writer::tag('span', '', array('class' => 'skip-block-to', 'id' => 'skipsitenews'));
}
break;

case FRONTPAGEENROLLEDCOURSELIST:
$mycourseshtml = $courserenderer->frontpage_my_courses();
if (!empty($mycourseshtml)) {
echo html_writer::link('#skipmycourses',
get_string('skipa', 'access', core_text::strtolower(get_string('mycourses'))),
array('class' => 'skip skip-block'));

// Wrap frontpage course list in div container.
echo html_writer::start_tag('div', array('id' => 'frontpage-course-list'));

echo $OUTPUT->heading(get_string('mycourses'));
echo $mycourseshtml;

// End frontpage course list div container.
echo html_writer::end_tag('div');

echo html_writer::tag('span', '', array('class' => 'skip-block-to', 'id' => 'skipmycourses'));
break;
}
// No "break" here. If there are no enrolled courses - continue to 'Available courses'.

case FRONTPAGEALLCOURSELIST:
$availablecourseshtml = $courserenderer->frontpage_available_courses();
if (!empty($availablecourseshtml)) {
echo html_writer::link('#skipavailablecourses',
get_string('skipa', 'access', core_text::strtolower(get_string('availablecourses'))),
array('class' => 'skip skip-block'));

// Wrap frontpage course list in div container.
echo html_writer::start_tag('div', array('id' => 'frontpage-course-list'));

echo $OUTPUT->heading(get_string('availablecourses'));
echo $availablecourseshtml;

// End frontpage course list div container.
echo html_writer::end_tag('div');

echo html_writer::tag('span', '', array('class' => 'skip-block-to', 'id' => 'skipavailablecourses'));
}
break;

case FRONTPAGECATEGORYNAMES:
echo html_writer::link('#skipcategories',
get_string('skipa', 'access', core_text::strtolower(get_string('categories'))),
array('class' => 'skip skip-block'));

// Wrap frontpage category names in div container.
echo html_writer::start_tag('div', array('id' => 'frontpage-category-names'));

echo $OUTPUT->heading(get_string('categories'));
echo $courserenderer->frontpage_categories_list();

// End frontpage category names div container.
echo html_writer::end_tag('div');

echo html_writer::tag('span', '', array('class' => 'skip-block-to', 'id' => 'skipcategories'));
break;

case FRONTPAGECATEGORYCOMBO:
echo html_writer::link('#skipcourses',
get_string('skipa', 'access', core_text::strtolower(get_string('courses'))),
array('class' => 'skip skip-block'));

// Wrap frontpage category combo in div container.
echo html_writer::start_tag('div', array('id' => 'frontpage-category-combo'));

echo $OUTPUT->heading(get_string('courses'));
echo $courserenderer->frontpage_combo_list();

// End frontpage category combo div container.
echo html_writer::end_tag('div');

echo html_writer::tag('span', '', array('class' => 'skip-block-to', 'id' => 'skipcourses'));
break;

case FRONTPAGECOURSESEARCH:
echo $OUTPUT->box($courserenderer->course_search_form('', 'short'), 'mdl-align');
break;

}
echo '
';
}
if ($editing && has_capability('moodle/course:create', context_system::instance())) {
echo $courserenderer->add_new_course_button();
}
echo $OUTPUT->footer();

Is there any configuration I have to do? Please advise

Thanks
In reply to Key Learning Centre

Re: Moodle Upgrade from 3.5.1 to 3.6.x or 3.7.x

by Ken Task -
Picture of Particularly helpful Moodlers

So the first step in your 'plan' was to upgrade Ubuntu from 16.04 to 18.04 ... and without doing anything more on the new environment immediately went to the moodle and saw the raw code of a php script.

That right?

You did 16.04 -> 18.04 to get higher version of PHP ... correct?

So before checking the moodle, might have been a good idea to check out ... apache (which appears to be working ... kinda), PHP, and MySQL.

Did you check config of apache?  PHP?

Suggest creating a phpinfo page and putting it at document root of apache, hit with browser.

phpinfo page has only this in it:

<? phpinfo(); ?>

and is named with a .php extension.

If you get text and no web page, php is not configured to talk to apache - ie, apache doesn't know what to do with .php scripts thus chooses to serve it out as text.

Also ... Friday is perhaps the worst day for relying upon community/volunteer support for any major undertaking .... no one here is working ... and like everyone ... might be taking a well-deserved break from last weeks work! smile

'SoS', Ken


In reply to Ken Task

Re: Moodle Upgrade from 3.5.1 to 3.6.x or 3.7.x

by Key Learning Centre -
I got that issue sorted out and was able to log back in on my moodle after ubuntu upgrade, I've taken backups at each step.

Everything went fine except seems like I missed some step. Now:

I see HTTP 500 error when I take off maintenance mode, when I put it back to maintenance mode it gives me maintenance message that I put earlier. I'm trying to find solution to that and yes google was helpful.

Please advise.
In reply to Key Learning Centre

Re: Moodle Upgrade from 3.5.1 to 3.6.x or 3.7.x

by Ken Task -
Picture of Particularly helpful Moodlers

Google is your friend .... found the following via Google:

https://askubuntu.com/questions/1028422/php-shows-up-as-plain-text-after-upgrade-to-18-04

I hope this is not your production server cause you could have left a rather big hole for hackers ...  conditions:

IF the DB user and password in config.php of your site happens to be a sudo user on the system and the ssh port is open (normally is).

Since the only thing 'protecting' display of config.php is properly working PHP and apache, hacker could use wget to acquire config.php off your server.

Then try using those credentials for ssh login.

If successful and nothing alerts you the admin, hacker could acquire a lot of info concerning users.   Such a breach might be reported to GDPR if discovered ... and you don't want that ... for sure.

Don't mean to ruin your weekend, but ....

'SoS', Ken


In reply to Ken Task

Re: Moodle Upgrade from 3.5.1 to 3.6.x or 3.7.x

by Key Learning Centre -
Thanks for your response. I was able to resolve php and moodle3.7 pull issues. Now during the upgrade process I see this:

Unavailable missing dependencies
× Not in the Plugins directory: theme_boost.

Tried changing the config to use boost, theme_boost and making sure folder is there... no luck. Please advise.
In reply to Key Learning Centre

Re: Moodle Upgrade from 3.5.1 to 3.6.x or 3.7.x

by Ken Task -
Picture of Particularly helpful Moodlers

Database for 3.6.x mdl_config_plugins (themes are plugins) refers to them thusly:

mysql> select * from mdl_config_plugins where name like '%theme%';

+------+---------------------+----------+------------+
| id   | plugin              | name     | value      |
+------+---------------------+----------+------------+
| 1891 | theme_boost         | themerev | 1562334843 |
| 1927 | theme_bootstrapbase | themerev | 1562334876 |
| 1928 | theme_clean         | themerev | 1562334884 |
| 1929 | theme_more          | themerev | 1562334893 |

Database for Moodle 3.7
mysql> select * from mdl_config_plugins where name like '%theme%';
+------+---------------+----------+------------+
| id   | plugin        | name     | value      |
+------+---------------+----------+------------+
| 1891 | theme_boost   | themerev | 1562541168 |
| 1953 | theme_classic | themerev | 1562541194 |
| 1977 | theme_academi | themerev | 1562541123 |

academi an addon theme installed on system I was using
to write this response.  It is NOT core and am not recommending you install it.

But, in config.php file one uses:

$CFG->theme="directoryname" (as seen in moodlecode/theme/

Themes that come with stock 3.7.1 ... boost,classic

'SoS', Ken

In reply to Key Learning Centre

Re: Moodle Upgrade from 3.5.1 to 3.6.x or 3.7.x

by Ken Task -
Picture of Particularly helpful Moodlers

See you've stopped at 3.6.x in your courses site - so doesn't look like 3.7 git pull resolved.

Also see a lot of work has been done on front page of site ... all the pics linking to campus courses.

By chance did you do something like rename the boost directory in moodlecode/theme/ to theme_boost?  The old 3.5.x/3.6.x boost used bootstrape and had a 'bootstrapbase' directory in theme.  3.7 doesn't and there should be no 'bootstrapbase' directory in 3.7 code/theme/

'SoS', Ken


In reply to Ken Task

Re: Moodle Upgrade from 3.5.1 to 3.6.x or 3.7.x

by Key Learning Centre -
Thanks for all your help guys. I've decided to stop at 3.6.5 for now as it meets our requirements for all the courses. Upgrading to 3.7.1 didn't go very well so I rolled back to 3.6.5. I will touchbase when I will need 3.7.1+

Once again thanks everyone...
In reply to Key Learning Centre

Re: Moodle Upgrade from 3.5.1 to 3.6.x or 3.7.x

by Ken Task -
Picture of Particularly helpful Moodlers

Well then ... one more suggestion ... clone production to a test environment.  Test the upgrade from 3.6.x to 3.7.x (by the time you get round to that, things change - higher version of 3.7.x will probably be available by then).

One can then 'leisurely' work on the test environment. smile

And if there are issues then, start a new thread in forums ... or this thread becomes the "KLC Support blog".

'SoS', Ken


In reply to Key Learning Centre

Re: Moodle Upgrade from 3.5.1 to 3.6.x or 3.7.x

by Dominique-Alain Jan -
Picture of Testers
Dear KLC Support,

And YES, I also would prefer to know the real person who is behind this brand, so if you could change this in your profile, many of us would appreciate it.

Regarding your questions I understand that you are on the learning curve of many little things about managing a server. We all been in that position, and I was also. My advise is to move gently, on step at a time and to document every more you make, to learn from them and be able to replicate them and also to roll back when something goes wrong.

You have different issues to solve: upgrade php, upgrade Moodle and manage the plugins you have installed and from which some may not work with the new Moodle or the new version of php.

Based on my past experience (and also bad experiences) I would recommend to back up your whole server. It is easy if you have virtual machine (e.g. VMWare) or sometimes your service provider offers this service/feature. Doing this you will be able to work on a copy of your environment leaving the production site untouched and running. When you are up-to-date and ready on the copied machine you can swap one for the other but if something goes wrong you are just killing your "learning" machine.

First, and as you suggest I would upgrade Ubuntu from 16.04 to 16.04. Always upgrade Ubuntu to a LTS version; so the latest LTS version is 18.04 where 19.04 is NOT. Always using LTS minimises the problems you may face when upgrading from non LTS versions. When I personally did this upgrade last year it was not straight forward for me and I had to overcome some issues. For exemple please take into account that the way Ubuntu 16.04 manage the ethernet interface has changed in 18.04 and you will have to reconfigure this accordingly. As said by others in this forum, changing for Ubuntu 18.04 will give you php 7.x natively and also an easy support for new update directly in Ubuntu core. As Howard Miller wrote, use php 7.2 because this version is supported by Moodle 3.5 and also by the latest release 3.7.

Before upgrading your Moodle, read carefully https://docs.moodle.org/en/Moodle_migration as Visvanath Ratnaweera recommended. But before all I would recommend to move the template you are using with your Moodle to a standard template of the core. Upgrading a Moodle with a customised or non official template may cause some trouble which are sometimes difficult to overcome for an unexperimented Moodle manager.

The third party plugins may also cause problems when upgrading. I suggest to ways: 1/ try to upgrade your Moodle and then if it does not work, come back with a backup and deactivate all third party plugins and upgrade again; 2/ do the opposite: deactivate all the plugins and then upgrade Moodle and reactivate the plugins after upgrading each of the with the latest compatible version.

I personally had a big problem with one commercial plugin (compilatio) last year when I have upgraded my Moodle in September. It took me hours to determine that it was this plugin that was stalling my upgrading process. Sometimes little things take much of your time.

Using GIT to upgrade and maintain your sever is a good thing IMHO. With GIT you always know on which version you are working

git branch -a (for exemple)

and you can easily ugrade Moodle from a major version to another with a few commands. This page gives you full detail but there are others on the net that explain the whole process: https://alephnull.uk/moodle-major-version-upgrade-git.

The tasks you are facing now are not trivial, but full of learning experience. But do not forget to backup backup backup and document document document and eventually your server will be clean-new-shiny very soon now.

All the best and HTH,
Dr Dominique-Alain Jan
Average of ratings: Useful (4)
In reply to Key Learning Centre

Re: Moodle Upgrade from 3.5.1 to 3.6.x or 3.7.x

by Ken Task -
Picture of Particularly helpful Moodlers

+1 to what Howard said ... just one additional which should be SOP, but this to remind ...

Current site ... check server environment, update component.   See what it says about DB ... character set/collation as that is also something one might want to do/have to do along the 'march path'.

Have any additional plugins including themes?  Check them out for compatibility with destination version.

Do a DB backup and code backup before you begin.  Upgrade to X, test, if OK, again DB backup and code backup ... those backup files having mdl version in their file names.   They are 'fall back' positions if the next hop goes terribly wrong for some reason.

Then next hop ... wash/rinse/repeat ...

'spirit of sharing', Ken


Average of ratings: Useful (1)
In reply to Ken Task

Re: Moodle Upgrade from 3.5.1 to 3.6.x or 3.7.x

by Key Learning Centre -
Hi and thanks Ken for your reply, do I have to backup and then upgrade 1 step at a time? OR the one backup in the start and then git should upgrade to the latest stable version?

I am not sure if git upgrade process will say something like I am at this version of moodle now would you like to upgrade further...
In reply to Key Learning Centre

Re: Moodle Upgrade from 3.5.1 to 3.6.x or 3.7.x

by Ken Task -
Picture of Particularly helpful Moodlers

+1 to Howards response ...

About backups at each stage ... I've never regretted not taking the few minutes that it takes to do that.  May as well start out with a SOP .... backup first.   Why?  Hmmm ... dunno bout your crystal ball, but mine is kinda cloudy.  Now its rare that it would happen, but what if the git hub where Moodle code is stored and which git will attempt to use to update goes down in the middle of your upgrade?

Have backup?  No problem ... restore backup, try again later.

Marching a moodle .... backup at each stage ... why?  You might have done your research and know that plugins you have will need upgrading.  And requirements for PHP/MySQL versions as well as character set/collation of DB server/clients (moodle code is a client).

Same kinda thing ... on the rare occasion where something is missed or a hickup in network, etc. happens ... having a fall back position is advised.

Case in point ... Rackspace hosted Linux servers.  Owners have seen that RS provides server backups ... that's the entire server.   Should owners rely on those for restore IF there is a hickup with DB?   Uhhhh ... those backups are raw file backups.   That good for DB backups?  Nope!  Even RS docs say that!!!!

To me, it's like taking a sledge hammer to something that only needs an 'exacto knife' ... and takes less time ... an in the case of DB server, better to restore an SQL dump of DB.

On most servers I have a bash shell 'bu' script just for backups, but if in a hurry, also have an 'up' script that backs up code, does DB dump, and minimal moodledata/filedir/ and then puts site in maintenance mode, does a point release upgrade of code (git), then uses the scripts in moodlecode/admin/cli/ to upgrade the site.   Out of maint, run purge of caches/cron job ... done.  Done in no more than 5 minutes time for most servers.

Of course, you are free to do as you please! smile

'SoS', Ken


Average of ratings: Useful (1)