Hello
I was wondering what is the best way to update Moodle Core, when I have installed a lot of plugins on my Moodle instance.
I have read few older forum posts about the same question but I am still confused.
1. I have installed Moodle from Git.
2. I installed 10+ plugins
3. Now I want to update to latest 3.3 version
How can I update Moodle core and keep the changes I made?
Kind regards
Christos
Key to your question ... involves another question ... was the Moodle originally installed using git to acquire the code?
Evidence of that ... in the moodle code directory there is a hidden .git directory. Note the 'dot' in front of the word git.
So as not to confuse with options let's find out that first.
A general comment however ... git only updates/upgrades core code. If plugins/add-ons were installed in the typical fashion (via Moodle Admin UI) those are not updated nor upgraded by the git commands to update/upgrade the core, but rather through the Moodle Admin UI (it's called mdeploy).
*** You must find out if the plugins/add-ons you've added are compatible with the version you are upgrading to.
A great tool to find out if a plugin has an X version is 'moosh' ... which is command line only. More on that after we get by the first question.
'spirit of sharing', Ken
Yes Moodle was initially installed using git, the .git folder is present
If I use
git status
there are few Untracked files, if I just git pull will this upgrade Moodle Core files without affecting plugins?
I am interested to upgrade Moodle Core only, I dont worry about upgrading plugins.
That command id's files that git doesn't recognize as part of core obtained previously.
Example:
I have some bash shell scripts and text files related in /moodlecode/admin/cli/ None of those change core code.
# On branch MOODLE_33_STABLE
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# admin/cli/checkaddons
# admin/cli/clirestore
# admin/cli/courses.txt
# admin/cli/dobu
# admin/cli/get1courseinfo
# admin/cli/getcourseinfo
# admin/cli/getcourses
# bu
# mod/lightboxgallery/
# up
nothing added to commit but untracked files present (use "git add" to track)
To update ... ie, acquire updates to the version you have ...
check:
git branch -a
At the top:
* MOODLE_33_STABLE
shows am tracking the 33 branch.
root@sos moodle33]# fgrep '$release' version.php
$release = '3.3.1 (Build: 20170710)'; // Human-friendly version name
git pull would aquire any/all updates to the 33 branch
To upgrade, however, one must issue two commands to track the next highest branch.
# git branch --track MOODLE_34_STABLE origin/MOODLE_34_STABLE;
# git checkout MOODLE_34_STABLE;
Again ... it's important to check if the addons have a compat version. The upgrade process will check and in some cases, might stop your upgrade cold.
This is where a bash shell script using moosh comes in handy.
addons.txt is a simple text file listing the true name of an addon.
The script, checkaddons, reads the lines in addons.txt one at a time, then uses moosh to see what's available for that addon:
#!/bin/bash
#
echo 'Add-on listing: ';
cat ./addons.txt;
echo '---------------------';
for i in `cat ./addons.txt`
do
echo "Addon in que: $i";
moosh plugin-list |grep '^'$i
done
Again ... IF an addon doesn't have a compat version for the upgraded version you are moving to, it could cause problems - in some cases, major ... like themes.
moosh uses config.php and the moosh command above issued by itself should acquire infor on *all* plugins - even ones you don't have installed.
Output looks like:
workshopeval_weightiest,2.5,2.6,2.7,2.8,2.9,3.0,3.1,3.2,3.3,https://moodle.org/plugins/download.php/11123/workshopeval_weightiest_moodle33_2015042200.zip
The mod/addon workshopeval_weightiest has compat versions for 2.5->3.3. IF I had the addon installed and was upgrading site to 3.3 then that addon should continue to function ... after upgrading it via the Moodle admin UI.
That clear as mud? ;)
Might be a good thing to have a clone of production to test before applying on production server.
Cravat ... if you installed a plugin via git, then you could change into that directory and a git pull there should work like the git pull does with core ... acquires updates to just that plugin ... directory has it's own hidden .git directory.
'spirit of sharing', Ken
Thank you soooooooooo much for the detailed reply.
Now its clear! Thank you.
I will try to also use Moosh as per your recommendation
Thank you again
Welcome. Feel free to rate postings that were useful as 'useful' ... helps me keep my 'badge'. ;)
'spirit of sharing', Ken
Dear Ken
Hi again, I tried to use Moosh, but it does not always work.
I downloaded Moosh from git and created a symlink to /usr/local/bin.
When I do
moosh plugin-list
It works, I get a list of plugins
When I do
moosh course-create newcourse{1..3}
One of your Moodle data directories (/var/www/moodledata/cache) is owned by
different user (apache) than the one that runs the script (root).
If you're sure you know what you're doing, run moosh with -n flag to skip that test.Then I try
sudo -uapache moosh course-create newcourse{1..3}
sudo: unable to execute /usr/local/bin/moosh: Permission deniedDid you ever had the same problem? Am running on Centos 7
Thanks in advance
The last line in the notice 'if you know what you are doing ...' ... -n skips the check to run moosh as web service user and will allow execution as the root user. I know some will shudder at that ... might even be a little afraid to run as root user, but ... we do as we must when it comes to Moodle.
Something might get tagged as belonging to the root user when it comes to files/folders .. owerships/permissions fixes are easy and I'll gladly trade off having to do that IF moosh can do things it advertises it can do.
Moosh reads the config.php file and takes DB info from it when working with DB. And think one needs to execute commands inside the code diretory so that it can read that config.php.
Sooooo ... all that to say, be less afraid! Issue the command inside the code directory.
moosh -n course-create newcourse{1..3}as root.'spirit of sharing', Ken
To be honest i got scared from the documentation and didnt want to run the command with -n
I will run it as root then thanks
Dear Ken
Sorry for coming back on this after 2+ months
When I tried to pull Moodle 3.3.2 I got
....
modified: webservice/wsdoc.php
modified: webservice/xmlrpc/db/access.php
modified: webservice/xmlrpc/lang/en/webservice_xmlrpc.php
modified: webservice/xmlrpc/lib.php
modified: webservice/xmlrpc/locallib.php
modified: webservice/xmlrpc/server.php
modified: webservice/xmlrpc/simpleserver.php
modified: webservice/xmlrpc/tests/fixtures/array_response.xml
modified: webservice/xmlrpc/tests/fixtures/fault_response.xml
modified: webservice/xmlrpc/tests/fixtures/value_response.xml
modified: webservice/xmlrpc/tests/lib_test.php
modified: webservice/xmlrpc/tests/locallib_test.php
modified: webservice/xmlrpc/tests/xmlrpc_server_test.php
modified: webservice/xmlrpc/version.php
Untracked files:
blocks/accessibility/
blocks/course_contacts/
blocks/iframe/
blocks/teleconference_noticeboard/
course/format/topcoll/
dcduplicate/
mod/bootstrapelements/
mod/choicegroup/
mod/turnitintooltwo/
plagiarism/turnitin/
theme/bootstrap/
Commit your changes or stash them before you can merge
Given that all plugins are compatible with 3.3.2, If I do:
git stash
git pull
then run upgrade.php
will it work? Will Moodle core files be upgraded to 3.3.2 with no issues?
Wow! This response delayed due to circumstances beyond control. Hope you've resolved the problem already. But, if not ... here goes ...
Qualifications for this response: not a git guru but can google.
Git doesn't normally 'loose track' but it would recognize if a file has changed. Did you maually edit or tinker with the webservices files listed? Hope not as they are core.
The other listing of files look to be mostly addons/plugins. How were those installed?
Have run the git stash before as suggested via git before. Seem to fix and never had issue with that site again. Still made me wonder though. Not long ago discovered yet another 'glitch' ... a git branch -a kept listing two versions at the top and neither had the asterisc marking that one as the one being tracked. There was something network related that prevented git from acquiring what it needed. Git would get to 80% and then stop!!!! ????? Never did figure that out. Share with network folks what we were seeing (they had a rather restrictive VPN setup ... no one could sneeze!). Think network forks relaxed a rule or something cause the next git started to behave as expected.
Via google, found a command to 'reset' git.
First, re-issue the two commands for the branch desired ... need to match what's in version.php of the site -the # symbol below needs to be changed to a digit.
git branch --track MOODLE_3#_STABLE origin/MOODLE_3#_STABLE
git checkout MOODLE_3#_STABLE
That makes sure you've told git which version. They might report 'already tracking' or 'not needed' ... that's a good sign.
Then issue:
git reset --hard
Check the branch ... before pulling the trigger on upgrade.php. Is is the one desired?
git branch -a
update and upgrade went well after that. And as far as I know, the site is still running ok.
'spirit of sharing', Ken
Hi Ken
Always with detailed explanations!! Thank you!
Being on version 3.3 I wanted to update to 3.3.2.
I did search on Google and I used
git stash
Use git stash when you want to record the current state of the working directory and the index, but want to go back to a clean working directory. The command saves your local modifications away and reverts the working directory to match the HEAD commit.(source)
Then
git pull
Everything worked, my plugins are still there, Moodle core files were updated and update worked like a charm. Site is fully functional.
To answer your question, the additional plugins where installed without git.
Now the only question pending in my mind is if git stash will work when I want to go from branch 3.3 to 3.4. I have the feeling that your solution (git reset) will be suitable then.
Kind regards
Christos