Is there any excepted system or way of managing plugins on multi-node Moodle application
There process seems a little outdated, insofar as we have to check that a particular plugin is compatible with a version of Moodle and then download the plugin from the moodle site and replace the current plugin with the new updated version
I normally just manage the server infrastructure and leave the plugins to developers
Cheers
I would suggest that you should do that anyway. I'm not a big fan of the web version of plugin management as it means you have to leave your Moodle site incredibly insecure.
I assume you are also going to test prospective plugins before they get anywhere near the live server.
What I'm coming round to is that this is easy if you use Git for deployment. Load your plugin on the test system (use the web interface if you like). Test it. Push the changes to your git repo. Then on the live system just run 'git pull' on each front end. Then run the update. Easy
"I'm not a big fan of the web version of plugin management"
Where does this manifest itself ?
Cheers
...as in installing or upgrading your optional plugins through Moodle's web interface. As opposed to getting dirty on the server.
I thought that's what you were talking about.
2 cents worth ... from personal experience ...
The web based update of plugins can bite ... depending upon what plugins you are updating/upgrading .... size of plugin (got one that is absolutely necessary [auth] and it's 22 Megs in size all the time). Had to increase php settings to get that one to complete.
Case two ... themes ... some themes are very heavy processing wise ... Essentials is an example. There are over 600+ settings to that theme. You upgrade a moodle and one of the first things one will notice is a notice from Essentials saying you must upgrade ... period.
Then there is Case three ... when updating via Web, the suggestion is made to install all upgrades. Catch 22 *IF* Essentials is one of those and it introduces some new dialog boxes/settings that's massive ... compared to the other addons one has upgraded.
Lethal combo for me ... the auth plugin that is large all the time + Essentials .... I do all other updates first, then the auth plugin and I save Essentials for last.
Yes ... could acquire the zips and do it manually ..... and yes, if I could find the proper git url for 'stable' and not experimental ... could do the git thing for all of them.
Mdeploy, which is what the web based updates are called, also changed where/what it did in the middle of a series (about 3.3 or so). At one time, the downloaded files and work area was in code directory. Has since been moved to moodledata ... which should mean it's safer in light of moodle security standards.
Me ... am a little lazy ... still use the Web based but it's nice to know, that If I had to, could complete a putzzed update/upgrade to a plugin via command line ... just have to figure out at what stage it hickup'd ... and have had to do that very thing with that auth plugin and Essenntials ... more than once! :\
So ... pick your poison! ;)
'spirit of sharing', Ken
I just wanted to second Ken's advice here in regards to plugin size and php settings. Most plugins tend to be relatively 'small' but you do get the occasional one that is far larger than the average. I didn't know that [auth] was so large but similarly, Poodll filter is around 50mb (possibly it has gotten smaller since ) and this caused me some headaches with failed upgrades/fatal errors a couple years ago until I realized that the plugin size and php settings were somewhat at odds (needed to read the documentation better...). Like Ken, I increased it the max_execution time (per documentation) and never had any problems since. Of course, always having backups and prior testing go a long way too .
Also doing plugin upgrades in sequence is a decent idea that I've borrowed from Ken in the past as well in regards to the size of Poodll .
I don't use the command line for upgrades (I've got it fine on a MAMP server but let's just say I need a better walkthrough first on the command line before I go that route live), but I've spent the last 3 years cleaning up a Moodle site that also included removing as many plugins as possible. Many were unused, some no longer compatible, others not supported. I'm down from a high of around 60 to current 10 to a soon-to-be 7. Could probably get it down to 4 but I use some of those plugins regularly while faculty or students typically do not.
I think I will Winscp the uncompressed zip to its correct directory from my windows machine and do it that way. I dont really trust the plugins overview page or process
Cheers
I have two objections...
1. Your Moodle installation has to be given permissions such that it's writeable by the web server. If you get one of those PHP worms on your server (and it may not be your fault if the box is in any way shared) then you are hacked. I would simply not have program code on a live box left writeable.
2. As Ken alluded - it leads to laziness. You just click the install button without bothering to read the release notes or consider the consequences.
"I have two objections...
1. Your Moodle installation has to be given permissions such that it's writeable by the web server. If you get one of those PHP worms on your server (and it may not be your fault if the box is in any way shared) then you are hacked. I would simply not have program code on a live box left writable. "
Sorry would you elaborate on this as I am not sure what you mean? I am have 6 x webs and just need a way of managing the updates for plugins and Moodle updates? I suggested that I just make sure they are compatible, test them on our dev then I need to move them to production by WINSCP
Thanks
