Exkurs: Die Gretchenfrage beim Modulupdate

"Never change a running system!" - Diese Binsenweisheit ist nicht ganz unberechtigt, aber spätestens wenn es um Sicherheitsupdates oder Funktionserweiterungen geht, muss dann eben doch mal ein Modul aktualisiert werden. Und da kommt die unscheinbare Checkbox ins Spiel, die unterhalb der "Durchsuchen"-Schaltfläche beim Modul-Installieren-Dialog hängt.

Während es bei der Neuinstallation eines Moduls logischerweise wurscht ist, ob die Checkbox aktiviert wird oder nicht,  ist sie bei der Aktualisierung eines bereits installierten Moduls von elementarer Bedeutung.

• Bei nicht aktivierter Checkbox (Vorgabe) werden nur die Dateien des Moduls auf dem Server installiert, die noch nicht vorhanden sind und ältere vorhandene Dateien des Moduls werden überschrieben.
• Bei aktivierter Checkbox werden stumpf alle Moduldateien, die vorhanden sind, überschrieben.

Klingt erstmal trivial - wo ist also das Problem? Nun, abhängig von der Konfiguration des Servers, des FTP-Programmes und mithin der Art und Weise, wie ursprünglich die Moduldateien auf den Server übertragen worden sind, kann es sein, dass diese nicht mehr das ursprüngliche Veröffentlichungsdatum des Moduls aufweisen, sondern das Datum, zu dem sie auf den Server übertragen worden sind.

Beispiel gefällig? Die view.php des Moduls "Wurstkäsespinat 1.0" ist im Installer vom 30.06.2011, aber da das Modul Wurstkäsespinat erst am 25.08.2014 installiert wurde, hat auch die view.php auf dem Server auf einmal das Datum 25.08.2014.
Nun gibt es eine Version 2.0 des Moduls Wurstkäsespinat vom 15.07.2013. Was passiert beim Update? Wird die Checkbox nicht aktiviert, denkt sich der Installer: "Oh je, da ist schon eine neuere Datei. Na, die lass ich mal lieber so, wie sie ist.", orgelt trotzdem in der Datenbank herum und kopiert aber nur irgendwelche Scripte oder sonstigen PHP-Dateien auf den Server, die da vorher nicht waren. Weiterhin denkt sich der Installer, da das ja genau das war, was der User bezweckt hat, und zeigt also fröhlich "Update erfolgreich" an. Nur dass im Frontend dann nur noch Kraut und Rüben oder gar nichts erscheint.

Also, Häkchen bei "Überschreibe usw." grundsätzlich setzen? Auch nur bedingt hilfreich. Denn wenn z.B. an der frontend.css über die bei etlichen Modulen zu findende Schaltfläche "Bearbeite CSS-Datei" in liebevoller Handarbeit Änderungen vorgenommen wurden, würde der mittels aktivierter Checkbox in den Dampfwalzenmodus versetzte Installer diese mal eben ins digitale Nirvana schicken. Ebenso gingen Anpassungen an anderen Moduldateien (egal ob Code, Template, Bild oder Javascript) verloren, wenn auch in der neueren Version Dateien gleichen Namens vorhanden sind - was i.d.R. der Fall ist. Auch nicht schön!

Letztlich muss individuell abgewogen werden.

• Brauche ich das Update überhaupt? Oder kann ich auch darauf verzichten? Nicht jedes Update muss zwingenderweise eingespielt werden - wenn es nicht gerade um das Stopfen von Sicherheitslücken geht.
• Kann ich die Features der neuen Version von Hand nachrüsten? Oft ist es einfacher, ein paar Zeilen Code z.B. an die Erfordernisse von >= PHP 5.6 anzupassen, als ein Modul zu aktualisieren und hinterher vor den Trümmern seines Customizings zu stehen.
• Muss ich das Update einspielen, habe aber Änderungen an der existierenden frontend.css oder sonstigen Dateien vorgenommen? Dann diese vor dem Einspielen des Updates via FTP oder den cwsoft-addon-file-editor sichern, Checkbox "Überschreibe neuere Dateien" aktivieren, Update einspielen und hinterher so weit es geht, die zuvor getätigten Anpassungen von Hand wieder vornehmen. (Nicht einfach die view.php oder die frontend.css überbügeln!)

Am besten dran ist, wer solche Änderungen erst einmal in einer Testinstanz der Website vornehmen kann, also keine Operation am offenen Herzen, sprich der produktiven Seite, erfolgen muss. So kann ohne Not geprüft werden, wie beim Updaten verfahren werden muss und welche Anpassungen erforderlich sind.