I'm working on the free-EOS project and especially in Moodle integration.
All is working fine for several months but I would like to improve this integration by allowing upgrade of existing Moodle instance in a "quick easy and well" way, it's the philosophy of this distribution.
What is the mecanism use to process upgrade especially database upgrade (code upgrade is easily manageable).
Thanks for your explainations.
Didier RAMBEAU
Hi, Didier.
The normal process is to update the files, and then visit the Moodle home page as an admin. Moodle takes care of the rest and leads you through the process, so it's already very easy. Some more details are in the docs.
If you want to completely automate this from the command line it could be a little difficult (and not really recommended because if there are problems in the upgrade they won't be noticed), but the basic procedure is to keep running cvs:/moodle/admin/index.php over and over.
The normal process is to update the files, and then visit the Moodle home page as an admin. Moodle takes care of the rest and leads you through the process, so it's already very easy. Some more details are in the docs.
If you want to completely automate this from the command line it could be a little difficult (and not really recommended because if there are problems in the upgrade they won't be noticed), but the basic procedure is to keep running cvs:/moodle/admin/index.php over and over.
Thanks Martin for your quick answer.
I'm quite familiar with the Moodle's installation procedure (I've automated it in our distribution environnement).
My purpose is to automate the upgrade process, from a particular version to a particular version (it's no very flexible but it's the need in our environnement). I know the web oriented upgrade process, because I'm using it. But I want that, in our web admin interface, the user as just to push a button and then all the upgrade script are executed (silently). I think that in many case there won't be any problem with errors, but if there is, error messages should be stored in the log file instead of the screen.
Our distribution is a Linux based server which provide variety of application and services (whose Moodle). His administration should be done by a non computer specialist (a good user with few netwok knowledge). So file manipulation and file edition must be reduce at a minimum.
A second need is that all embedded application must use a same installation and upgrade mecanism so my purpose is to create an upgrade script (whose can call others) to do the job.
Sorry for my not very good english (I'm french)
I'm quite familiar with the Moodle's installation procedure (I've automated it in our distribution environnement).
My purpose is to automate the upgrade process, from a particular version to a particular version (it's no very flexible but it's the need in our environnement). I know the web oriented upgrade process, because I'm using it. But I want that, in our web admin interface, the user as just to push a button and then all the upgrade script are executed (silently). I think that in many case there won't be any problem with errors, but if there is, error messages should be stored in the log file instead of the screen.
Our distribution is a Linux based server which provide variety of application and services (whose Moodle). His administration should be done by a non computer specialist (a good user with few netwok knowledge). So file manipulation and file edition must be reduce at a minimum.
A second need is that all embedded application must use a same installation and upgrade mecanism so my purpose is to create an upgrade script (whose can call others) to do the job.
Sorry for my not very good english (I'm french)
OK, well, if you examine admin/index.php you'll find all the upgrade code in there. Sometimes functions are called that have pauses in them (print_continue) which may be a problem. You'd have to create a new script that includes all that stuff in one place without pauses.
We should fix this anyway because it would be nice to have an "accelerated all-on-one-page install" for advanced users.
We should fix this anyway because it would be nice to have an "accelerated all-on-one-page install" for advanced users.
I was thinking along some other line recently and came to the same conclusion. The upgrade procedure right now isn't very slick visually. It would be nicer if the feedback wasn't as extensive in case of successes, and a nice "progress bar" was shown instead. Errors should be displayed prominently, and not somewhere in the middle of all messages, even if they are in red.
So the thought was that we could refactor the upgrade code a bit, so that it doesn't disturb the UI but it returns results instead. Then we can make a better UI and experiment with it with impunity. This would also solve the "automated upgrade" problem, as in that case Didier would just use a "non-UI" to get the job done. Or maybe a non-interactive, logging "UI".
Do you think this would be nice? I can't help but think that the upgrade procedure is "unpolished" each time I see it.
So the thought was that we could refactor the upgrade code a bit, so that it doesn't disturb the UI but it returns results instead. Then we can make a better UI and experiment with it with impunity. This would also solve the "automated upgrade" problem, as in that case Didier would just use a "non-UI" to get the job done. Or maybe a non-interactive, logging "UI".
Do you think this would be nice? I can't help but think that the upgrade procedure is "unpolished" each time I see it.
Yes, I think that too. It's one of those low-priority things because only admins see it. I'd certainly like to see a progress bar with perhaps an IFRAME under it containing messages, and perhaps some checkboxes to choose the level of messages one wants to see.
I absolutely agree Jon's opinion about error messages drowned in the middle of other messages. That really lacks of readability.
Jon, you make me hungry with your non-interactive upgrade.
I hope someone could help to do the job (I'm afraid my knowledges are not enought to permit modifications in PHP code at this time).
Didier RAMBEAU
Jon, you make me hungry with your non-interactive upgrade.
I hope someone could help to do the job (I'm afraid my knowledges are not enought to permit modifications in PHP code at this time).
Didier RAMBEAU
Hi Martin!
Wasn't Jon's "Moodle Health" concept suppose to address automatic updates?
WP1
No, it's completely unrelated.
What's up about "accelerated all-on-one-page install" ?
I still interested in that functionnality.
I still interested in that functionnality.
I make a little up for this thread with the hope it will scheduled in the roadmap during the next developper conference.