Moodle updates and Plugins :(

Moodle updates and Plugins :(

- Niall Sheehan の投稿
返信数: 5

Morning all. I run several Moodle sites and dread updating the core every time it is needed. I'm prepping my dev site for the 3.7.2 update and wondering if there is a better way. The biggest PITA with updates are plugins. This means to update you rename your moodle site folder, back up the Moodle Data folder, run a database backup, create a new folder, extract Moodle and start painstakingly going through all the plugin folders to copy what you have installed. 

It would seem that there is a good case for moving the "additional plugins" to a dedicated folder as this would allow us to copy a single folder rather than hunting down, in our case, 50 plugins.

Cheers.

評点平均: -
Niall Sheehan への返信

Re: Moodle updates and Plugins :(

- Jez H の投稿
Managing your codebase using GIT repositories as opposed to folders would be a better approach. That is how commercial Moodle hosts / partners manage things.
評点平均: -
Niall Sheehan への返信

Re: Moodle updates and Plugins :(

- Ken Task の投稿
画像 Particularly helpful Moodlers

+1 to Jez response ...

this posting a little deeper ... and my 2 cents ... others will have other suggestions ...

Backups first ... right?  Minimla would be code/DB and filedir of moodledata.

Issues ...
all begins with how one updates/upgrades core.
Strongly recommend git.  Code directories stay in place.
No renaming, moving, etc.
Depending upon whether it's an update ... like 3.7.0 -> 3.7.highest
or an upgrade ... like from 3.6.x -> 3.7.highest ... git acquisition
of code is literally a matter of minutes.

The plugins are still a problem *IF* one wants to update/upgrade everything
at once.   Hmmmm .... seems to me, one had better have a dev server for testing
doing all at once.   A single plugin ... or in the most recent upgrades to 3.7 the
theme can cause major disruption until resolved.  Even if one had an addplugins directory
for them all.

So you have the same 50 plugins for all of your X sites?

Updates to plugins might a major change of the plugin or it might be only a version
change.

Am gonna stick my neck out and say that plugin updates might be best done via Admin GUI
and in some cases one at a time - depending upon how massive the update/upgrade is and
what it is (theme has potential of total disruption).

Use command line?
Have found that updating plugins can be done quickly and in some cases (depending upon
the plugin) be done while site is being used - case in point ... plugin that is
an admin report or some admin tool teachers/participants can't and don't access.

There is some relief ... https://moosh-online.com/commands/
plugin-install
Download and install plugin. Requires plugin short name, and plugin version. You can obtain those data by using `plugin-list -v' command.

Example:

moosh plugin-install mod_quickmail 20160101

Have a sandbox server with 3.4,3.5,3.6, and 3.7 installed.
For each I build a plugins list txt file from the shortnames of the plugins.
Example of the plugins installed in the 3.4 called addons.txt:

mod_hvp
mod_questionnaire
mod_customcert

A bash shell script called checkaddons uses addons.txt and checks only those
via moosh.

#!/bin/bash
#
echo 'Add-on listing: ';
cat ./addons.txt;
echo '---------------------';
for i in `cat ./addons.txt`
do
   echo "Addon in que: $i";
moosh -n plugin-list |grep $i
done

Renders:

Add-on listing:
mod_hvp
mod_questionnaire
mod_customcert
---------------------
Addon in que: mod_hvp
mod_hvp,2.7,2.8,2.9,3.0,3.1,3.2,3.3,3.4,3.5,3.6,3.7,https://moodle.org/plugins/download.php/20122/mod_hvp_moodle37_2019081600.zip
Addon in que: mod_questionnaire
mod_questionnaire,1.9,2.0,2.2,2.3,2.4,2.5,2.6,2.7,2.8,2.9,3.0,3.1,3.2,3.3,3.4,3.5,3.6,3.7,https://moodle.org/plugins/download.php/19726/mod_questionnaire_moodle37_2018110101.zip
Addon in que: mod_customcert
mod_customcert,2.9,3.0,3.1,3.4,3.5,3.6,3.7,https://moodle.org/plugins/download.php/19798/mod_customcert_moodle37_2019052001.zip


Note the plugins have version number in their filenames.

And with a little more scipting one could build a loopoing bash shell
that would install

mod_hvp_moodle37_2019081600.zip

moosh -n plugin-install mod_hvp 2019081600


Catch 22's ... directory exist moosh won't erase soooo a mv to a hidden safe.

[root@server moodle34]# mv mod/hvp mod/.hvp;moosh -n plugin-install mod_hvp 2019081600
Installing
    name:    mod_hvp
    version: 2019081600
PHP Warning:  rmdir(/var/www/moodle34data/cache/cachestore_file/default_application): Directory not empty in /var/www/html/moodle34/lib/moodlelib.php on line 9357

But, if cron job/task running as they should, that would be cleared very soon.

'SoS', Ken

評点平均:Useful (1)
Ken Task への返信

Re: Moodle updates and Plugins :(

- Jez H の投稿
The issue as I read it was having to put 50 plugins back into the codebase for the latest Moodle version you were using.

The way that would typically be done on the file sysem is to download the version of Moodle you want form Moodle.Org and then copy all the plugin directories back in. I guess you could write a script to do that if you are doing it frequently that coudl save some time though I am not sure I would trust that.

A better approach is to use GIT to merge all your plugins / core changes in more easilly. I am no expert in GIT but know there are a couple of differnt ways to handle this and know this is how Moodle Partners tend to manage code bases for clients.

That gives you better version control and it is easier to see what changed when in addition to being a timesaver, but only addresses the issue of rebuilding your codebase, the other steps such as backup, testing on staging etc. still need to be done.
評点平均:Useful (1)
Jez H への返信

Re: Moodle updates and Plugins :(

- Niall Sheehan の投稿
My typical plan of attack to ensure I can go backwards fast is to: 
  1. Stop servers
  2. run manual backups of the databases, 
  3. and of the moodledata folders. 
  4. I 'stage' a new moodle folder with the latest version
  5. All sites have the same plugins, manually copy additional plugins to staged folder
  6. Rename existing moodle folder to OLD
  7. Create new folders
  8. Copy staged version to all folders
  9. Copy config from OLD to new folders for each site
  10. Bring servers back online one at a time
  11. Go to site, complete Moodle update.

The version repository option is valid and I'll take a look at that. I lack the dev background, however I've got a few here that can assist with SVN or GIT.

We are in a Windows/IIS environment, the script idea may be looking at as well.

Thank you!

評点平均: -
Niall Sheehan への返信

Re: Moodle updates and Plugins :(

- Jez H の投稿
Hi Niall,

The way we approached this was to rebuild the entire code-base with plugins and do dry runs of the upgrade on another test instance, once we were happy with that then at the point we renamed the folder it already had all plugin updates in it, so there was no need to copy them over whilst the system was down.

An alternative to renaming is to point Apache to a different folder, though I am not sure how easy that is in IIS.

To create a test instance like that you are either going to need a separate test domain, then rename all entries in config.php and your database from "livemoodle.domain.edu" to "testmoodle.domain.edu"

Another option is to set up another server with the same code (which believes it is your live Moodle domain) and add a hosts entry on your PC for that IP address. This avoids faffing with renaming all your domain info but means anyone testing needs to update their hosts file on their PC to point at your test IP which makes it difficult to do larger scale testing with end users.

Something else we did was to run multiple Moodle instances from a common codebase, so there is only one codebase to update, not one for each Moodle site. The main constraint around this is around things like themes. If you have hardcoded changes in different versions of a theme with the same name this would be an issue, in that instance you would have to create renamed copies of the theme. However that is less of an issue these days as most themes have admin settings to control colors, override css which resides in the database and caching should all be in the Moodledata directory... there maybe other considerations in current versions of Moodle, it is years since I did this, but if you are interested there is an old thread I posted here:

https://moodle.org/mod/forum/discuss.php?d=241901

In short you read in URL being called and use that to determine which moodledata and database to point at, so you can have a single Moodle codebase that switches between different moodledata / databases depending on the site being accessed.

I have to say if I were doing this now (we outsourced hosting to a Moodle partner) I would be looking at using GIT to manage / pull down changes to multiple sites rather than running a single copy of the codebase.
評点平均: -