Hallo.
Unser Webserver ist kürzlich umgezogen. Nun besteht die Möglichkeit mit PHP 8 und aktueller MariaDB auch die moodle-Version auf einen aktuellen Stand zu bringen. Da wir moodle per git installiert haben, wäre nun ein Versionssprung von 3.11 direkt (?) nach 4.3 möglich. Kann dazu jemand Erfahrungswerte beisteuern?
Wenn ich nach Anleitung vorgehe, erhalte ich bei git status diese Ausgabe:
git status
On branch MOODLE_311_STABLE
Your branch is up to date with 'origin/MOODLE_311_STABLE'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: filter/algebra/algebra2tex.pl
Untracked files:
(use "git add <file>..." to include in what will be committed)
admin/tool/uploadenrolmentmethods/
blocks/sharing_cart/
course/format/grid/
course/format/onetopic/
course/format/tiles/
enrol/openlml/
filter/html5avtomp4/
lib/setuplib.php-old
local/cohortbulkdelete/
local/ldap/
local/profilecohort/
local/ws_enrolcohort/
mod/attendance/
mod/bigbluebuttonbn/
mod/board/
mod/collaborativefolders/
mod/geogebra/
mod/hvp/
mod/jitsi/
mod/pdfannotator/
mod/publication/
mod/questionnaire/
mod/scheduler/
mod/unilabel/
mod/vpl/
question/behaviour/adaptive_adapted_for_coderunner/
question/type/coderunner/
report/coursesize/
theme/archaius/
theme/base/
webservice/restful/
no changes added to commit (use "git add" and/or "git commit -a")
Für mich klingt das so, als seien das lauter Dateien/Ordner, die wir selbst nachträglich verändert haben und die daher von git nicht beachtet werden können. Daher weiß ich auch nicht, welches weitere Vorgehen nun sinnvoll oder ratsam ist.
Ich habe unser produktives moodle geklont und kann daher problemlos alles möglich ausprobieren … aber wenn jemand gute Tipps diesbzgl parat hat, würde ich mich freuen.
Hallo Michael,
bei den Ordnern handelt es sich um Ordner der Plugins, die nicht teil der Core-Installation sind.
Wie installiert ihr den Plugins? Via Git-Submodule, via manuellem Reinkopieren, via der Weboberfläche?
Zu beachten ist, dass manche der Erweiterungen in 4.3 evtl. nicht mehr dabei sind, oder aber mittlerweile Teil der Core Installation sind. Letzteres betrifft z.B.:
Außerdem würde ich auf dem Server zunächst prüfen, ob dieser die Anforderungen von Moodle 4.3 erfüllt. Bei mir hatte der Server z.B. keine passende MariaDB-Version, wohl aber eine passende Postgresql-Version. Also habe ich vor dem Update erst mal die Datenbank gewechselt.
Hi, die Plugins haben wir immer über die Weboberfläche installiert. Ich wusste gar nicht, dass das auch per git möglich ist?!
In Sachen mariaDB und aller weiteren Requirements dürfte das kein Problem sein — es ist ein Ubuntu 22.04 Server mit Plesk. Notfalls kann man alles nachinstallieren, was fehlt.
Dann ist es vermutlich am besten, diese ganzen Plugins zu notieren, runter zu werfen und dann das Upgrade zu versuchen, oder?
Das Design und die Bedienung haben sich ja teilweise schon etwas verändert. Wie haben denn die Kollegen reagiert, wenn plötzlich „alles wieder völlig anders aussieht“??
Ich habe moodle via git installiert.
Dafür habe ich ein lokales repo (nicht vom web erreichbar) angelegt, in das ich mir immer den aktuellen Stand hole.
Ich habe eine csv Datei, in der ich die Plugins, welche ich installiert haben möchte notiert habe, mit dem Link zu dem jeweiligen git-Repo.
Ein Script bindet mir dann jedes Plugin als submodule ein.
Vom lokalen repo pushe ich dann in andere repos auf dem selben Server (vom Web erreichbar). Ich pushe zunächst in eine Staging Umgebung und wenn alles läuft in eine Production Umgebung.
Ja, genau. Die Ordner im Dateisystem löschen, aber nicht via Weboberfläche (sonst werden die Plugin-Infos aus der Datenbank gelöscht). Dann den Branch wechseln und das Update in der Weboberfläche ausführen, dann sollten die Plugins auch wieder installiert werden.
Für die meisten war das kein Problem. die Version 4 ist schon deutlich besser!
Hallo.
Ok, das werde ich ausprobieren.
Das bedeutet aber auch (sofern die Server-Requirements stimmen), dass ich ohne irgendeinen Zwischenschritt direkt von 3.11 auf 4.3 gehen kann, richtig?
Und dann habe ich noch gesehen, dass git sich über eine weitere Datei beschwert:
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: filter/algebra/algebra2tex.pl
Gilt da das gleiche wie für die Plugins? Datei lokal im Dateisystem löschen?
Hallo.
Ok – ich habe es so gemacht wie von Dir vorgeschlagen und im Wesentlichen lief das durch. Die Testumgebung hat den Sprung von 3.11 mit PHP 7.4.x auf 4.3 mit PHP 8.2.x also direkt gemacht
Ich habe die o.g. Ordner einfach verschoben habe, damit git überhaupt loslegen kann. Daher beschwert sich moodle nun, dass diese Quellen fehlen. Man kann die Ordner nach dem Upgrade scheinbar alle wieder zurückkopieren … ist vielleicht nicht der eleganteste Weg aber scheint zu funktionieren.
Nun bleibt die Frage, ob die ganzen Funktionen, wie z.B. die PDF-Annotationen (die wir während der Corona-Zeit eingerichtet hatten) alle noch funktionieren…
Am Rande, wenn Du ein Git Verzeichnis hast und Sachen veränderst, die von Git getrackt werden, dann wirst Du Probleme haben, weil Du dann mergen musst. Das wird ein Dauerbrenner sein. Am besten diese Änderungen rausnehmen. Ansonsten habe ich seit ca sechs Jahren mein Moodle als Git und wechsle nach jedem Update auf den neuen Branch, das ist problemlos möglich. Ich verzichte auch auf alle Plugins, weil die erfahrungsgemäß nur Probleme machen, nicht aktualiisert werden etc. Es lohnt nicht. Moodle kann fast alles von alleine, Plugins würde ich wenn, dann nur in einem eigenen Verzeichnis laufen lassen, was das Git-Verzeichnis überhaupt nicht berührt. Selbstverständlich kann man auch Anpassungen machen, aber dann muss man sie in Git ignorieren.
Hallo.
Ja, genau das merke ich gerade – denn wie schon oben erwähnt, ist H5P jetzt Bestandteil von moodle und ich hatte es vorher manuell installiert. Das Verzeichnis hvp hatte ich weggeschoben aber nach dem Plugin-Update hat sich v4.3 natürlich trotzdem beschwert, dass die Quellen von h5p fehlen. Ich wollte es deinstallieren und habe das Verzeichnis daher (kurzzeitig) wieder an den ursprünglichen Ort zurück geschoben … und siehe da: Nichts geht mehr. Jetzt erhalte ich leider nur noch die Meldung:
Fehler: Class "core_h5p\local\library\autoloader" not found
Gut, dass es nur eine Testumgebung ist … aber ich wüsste natürlich trotzdem gerne, wie ich das wieder zum Laufen bekomme.
Was die eigenen Änderungen angeht: das meiste davon ist im Laufe der Zeit aus irgendwelchen Notwendigkeiten heraus entstanden. Ich kenne mit mit git nicht gut genug aus, als dass ich diese ganzen Änderungen mal kurz in das .gitignore schieben könnte … aber das dürfte der richtige Weg sein??
Der einfachste Weg, moodle neu per git clonen und dann mit Deinen Infos, z.B. die settings.php ergänzen. Mein Update Script sieht dann so aus und man muss zum Upgrade zwischen den großen Versionen nur noch den Branch wechseln:
#
# switch to moodle source directory
cd /usr/share/nginx/html/moodle;
# put moodle into maintenance mode
sudo -u www-data php /usr/share/nginx/html/moodle/admin/cli/maintenance.php --enable;
# pull changes
sudo git pull;
# run the moodle upgrade script to which you will have to answer: y
sudo -u www-data php /usr/share/nginx/html/moodle/admin/cli/upgrade.php;
# Put moodle into regular mode again
sudo -u www-data php /usr/share/nginx/html/moodle/admin/cli/maintenance.php --disable;
# run the cron script to clean up
sudo -u www-data php /usr/share/nginx/html/moodle/admin/cli/cron.php;
# and switch back to your original directory
cd -;
Ich fürchte, dass sie weg sind, denn beim Deinstallieren wurde gewarnt, dass x Inhalte aus y Kursen entfernt werden. Aber wenn man das Plugin nicht deinstalliert, läuft man imho in den Fehler von oben. Das konnte ich nur dadurch wieder gerade ziehen, dass ich nochmal neu angefangen habe. Vielleicht geht’s ja auch eleganter/einfacher?!
Gerade entdeckt … möglicherweise kann man die Inhalte retten, wenn man unter 3.11 das hier installiert???
Hi.
Ich will unser produktives moodle in den kommenden Tagen nun endlich von 3.11 nach 4.3 bringen – ging leider nicht schneller.
Das Verfahren per git pull und dem Wechsel auf 4.3 hat beim letzten Mal mit ein paar Klimmzügen auf dem Testserver ja bereits funktioniert doch jetzt komme ich nochmal auf die Sache mit den excludes zurück. Du schreibst, dass man sich die settings.php vornehmen soll aber ist nicht die Datei .../your-moodle/.git/info/exclude eigentlich der bessere Ort, um Dateien direkt vom git pull auszuschließen
Auf der Moodle-Doku-Seite werden beide Wege (via exclude aber auch via submodule) beschrieben: https://docs.moodle.org/311/en/Git_for_Administrators#Updating_your_installation
Ich bin nun nicht sicher, welcher Weg der bessere oder einfachere ist? Die Sache mit den Submodules lohnt sich doch nur dann, wenn die eigenen Änderungen selbst auch über ein git-Repo verfügen — oder sehe ich das falsch?
Danke nochmals für etwas git-Nachhilfe,
Michael
(X-Links: die Moodle-selber-hosten-Diskussion wird ja gerade parallel auch in diesem >>> Thread und auch in diesem >>> Thread geführt. Hier geht’s mir aber ganz speziell um unsere Installation via git.)
Dort ist die config.php sowieso schon vermerkt, dass sie nicht mit aktualisiert wird. Da muss nichts mit exclude oder submodule gemacht werden. Exclude habe ich noch nie genutzt, trage ich immer alles in die .gitignore ein und submodules ist eher lästig und macht unvorhergesehene Probleme.
Wie gesagt, mit meiner Methode habe ich seit 10 Jahren keine Probleme gehabt und jedes Update, auch über die Versionen hinweg, durchführen können. Manchmal war ich sogar auf master unterwegs, wenn ich aus bestimmten Gründen keine aktuelle Stable nutzen konnte, auch das war kein Problem. Moodle ist extrem stabil und sehr gut getestet. Das sind richtige Profis!
Mir ist noch nicht ganz klar ist, warum es dann zusätzlich zu .gitignoreauch noch das .../.git/info/exclude gibt … reicht nicht eins von beiden?
Oh – gerade erst gesehen:
"# This file specifies intentionally untracked files that all Moodle git
# repositories should ignore. It is recommended not to modify this file in your
# local clone. Instead, use .git/info/exclude and add new records there as
# needed."
Aber wie auch immer: Dann werde ich die Verzeichnisse, die nicht mehr beachtet werden sollen, nun einfach in eine der beiden Dateien mit eintragen und hoffen, dass git pull dann nicht mehr meckert. Das Upgrade schiebe ich aber noch ein paar Tage nach vorne … im heißen Betrieb mache ich das lieber nicht.
.gitignore wird mit auf einen git-Server gepushed und gilt damit für alle lokalen Instanzen des git-repos.
/.git/info/exclude gilt nur für die eine Kopie und ist z.B. für spezielle Anpassungen die nur ein Nutzer benötigt gedacht.
