Prestashop manuell aktualisieren

Technik
Prestashop manuell aktualisieren

Prestashop ist bei weitem nicht mein Liebling-Shop-System. Immerhin steigt es auf das Symfony Framework um, was es mir um einiges sympathischer macht. Nichtsdestotrotz, die Upgrades sind nicht unbedingt spaßig. Besonders wenn man, so wie ich, einen lokalen Entwicklungsserver hat, um Updates zu testen, ist es sehr schade, wenn man alle Schritte auf dem Produktions-Server wiederholen muss. 

Zum Glück gibt es die Möglichkeit, Prestashop auch manuell zu aktualisieren. Die offizielle Dokumentation ist allerdings hierzu etwas spärlich.

Daher zeige ich euch meinen Weg. Ohne Anspruch auf Vollständigkeit, hat dies die letzten Male bei mir sehr gut funktioniert. 

Voraussetzungen 

Backup von Daten und Datenbank machen!

Eine Kopie des Produktionsservers läuft bei mir in meiner lokalen Entwicklungsumgebung. Ich verwende git. Bevor ich mit dem Upgrade auf eine neuere Version beginne, wechsle ich immer auf eine git branch namens upgrade. Mit git merge, git commit und git push bringe ich die Daten dann auf meinen Produktionsserver und synchronisiere dort die geänderten Dateien mittels rsync.

Theoretisch könnt ihr aber gleich alles auf dem Produktionsserver ausführen.

Auto Upgrade aktualisieren

Auch bei einem manuellen Upgrade muss zuerst das Auto upgrade Modul auf den aktuellen Stand gebracht werden um die Datenbank später aktualisieren zu können. Die SQL-Changes sind nämlich hier enthalten. 

Datei Upgrade

Eigentlich müssen ja einfach nur alle Dateien aktualisiert werden, die geändert wurden. Also die aktuelle Prestashop Version als Zip herunterladen, entpacken und einfach überschreiben? Leider darf man natürlich keine nutzergenerierten Daten, wie z.B. hochgeladene Bilder oder Einstellungsdateien, überschreiben. Ich habe mich daher dafür entschieden, Ordner für Ordner durchzusehen und ein rsync darüber laufen zu lassen. Dabei verwende ich den Parameter --checksum. Dieser führt dazu, dass nicht der Zeitstempel verglichen wird, sondern die Checksum. Es werden also nur tatsächlich geänderte Dateien aktualisieren. 

Je nach Ordner wird einmal der Parameter --delete verwendet oder auch nicht. Wird er nicht verwendet, werden vorhandene Dateien nur aktualisiert. Wird er verwendet werden nicht mehr vorhandene Dateien auch gelöscht. 

Also einfach die Datei upgrade.sh anlegen ...

#!/bin/bash
# set -x

TEMP="/path/to/new/prestashop/"
TARGET="/path/to/current/prestashop/"

cd "${TARGET}"

# change target admin name to your name
rsync -trv "${TEMP}/admin/" "${TARGET}/admin_YOURADMINNAME" --checksum --delete

rsync -trv "${TEMP}app/" "${TARGET}app" --checksum --delete --exclude="/config/parameters.php" --exclude="/Resources/translations"
rsync -trv "${TEMP}app/Resources/translations" "${TARGET}app/Resources/translations" --checksum

rsync -trv "${TEMP}bin/" "${TARGET}bin" --checksum --delete

rsync -trv "${TEMP}cache/" "${TARGET}cache" --checksum --delete

rsync -trv "${TEMP}classes/" "${TARGET}classes" --checksum --delete

rsync -trv "${TEMP}config/" "${TARGET}config" --checksum --delete --exclude="/email" --exclude="/themes" --exclude="/xml"
rsync -trv "${TEMP}config/xml/" "${TARGET}config/xml" --checksum

rsync -trv "${TEMP}controllers/" "${TARGET}controllers" --checksum --delete

rsync -trv "${TEMP}docs/" "${TARGET}docs" --checksum --delete

rsync -trv "${TEMP}download/" "${TARGET}download" --checksum #only overwrite existing, keep others

# edit YOUR to your logo files
### image folders ####
rsync -trv "${TEMP}img/" "${TARGET}img" --delete --checksum --exclude="/YOUR-logo_pdf.jpg" --exclude="/YOUR-logo*.*" --exclude="/favicon.ico" --exclude="/favicon-1.ico" --exclude="/c" --exclude="/cms" --exclude="/co" --exclude="/genders" --exclude="/l" --exclude="/m" --exclude="/os" --exclude="/p" --exclude="/s" --exclude="/scenes" --exclude="/st" --exclude="/su" --exclude="/tmp"
rsync -trv "${TEMP}img/c/" "${TARGET}img/c" --checksum
rsync -trv "${TEMP}img/cms/" "${TARGET}img/cms" --checksum
rsync -trv "${TEMP}img/co/" "${TARGET}img/co" --checksum
rsync -trv "${TEMP}img/genders/" "${TARGET}img/genders" --checksum
rsync -trv "${TEMP}img/l/" "${TARGET}img/l" --checksum
rsync -trv "${TEMP}img/m/" "${TARGET}img/m" --checksum
rsync -trv "${TEMP}img/os/" "${TARGET}img/os" --checksum
rsync -trv "${TEMP}img/p/" "${TARGET}img/p" --checksum
rsync -trv "${TEMP}img/s/" "${TARGET}img/s" --checksum
rsync -trv "${TEMP}img/scenes/" "${TARGET}img/scenes" --checksum
rsync -trv "${TEMP}img/st/" "${TARGET}img/st" --checksum
rsync -trv "${TEMP}img/su/" "${TARGET}img/su" --checksum
rsync -trv "${TEMP}img/tmp/" "${TARGET}img/tmp" --checksum

rsync -trv "${TEMP}install/" "${TARGET}install" --checksum --delete

rsync -trv "${TEMP}js/" "${TARGET}js" --checksum --delete

rsync -trv "${TEMP}localization/" "${TARGET}localization" --checksum --delete

rsync -trv "${TEMP}mails/" "${TARGET}mails" --checksum --delete --exclude="/de"

rsync -trv "${TEMP}override/" "${TARGET}override" --checksum

rsync -trv "${TEMP}pdf/" "${TARGET}pdf" --checksum --delete

rsync -trv "${TEMP}src/" "${TARGET}src" --checksum --delete

# exclude manually uploaded themes to prevent deleting
rsync -trv "${TEMP}themes/" "${TARGET}themes" --checksum --delete --exclude="/YOUR_THEME"

rsync -trv "${TEMP}tools/" "${TARGET}tools" --checksum --delete

rsync -trv "${TEMP}translations/" "${TARGET}translations" --checksum

rsync -trv "${TEMP}upload/" "${TARGET}upload" --checksum

rsync -trv "${TEMP}var/" "${TARGET}var" --checksum

rsync -trv "${TEMP}webservice/" "${TARGET}webservice" --checksum --delete

# root folder files
rsync -trv -f"- */" -f"+ *" "${TEMP}" "${TARGET}" --checksum

... und mittels folgendem Befehl ausführen.

bash upgrade.sh > log.txt

In der Datei log.txt findet Ihr, was alles passiert ist. Probeweise könnt ihr in der Datei -trv mit -trvn ersetzen, so läuft das Script im dry-run Modus, es wird also alles nur simuliert. 

Zusätzliche Schritte beim manuellen Upgrade 

Composer

Da es eine bad practice ist, den vendor Ordner über git zu verwalten und auf den Produktionsserver zu laden, habe ich diesen Ordner in obigen Script ausgeschlossen. Entweder fügst du jetzt eine Zeile für den vendor hinzu oder du lädst die entsprechende composer.json vom offiziellen Prestashop Git-Repository herunter (achte auf die richtige Version/Tag) und läufst folgenden Befehl.

composer install --no-dev --optimize-autoloader

Cache

Besonders bei größeren Upgrades, zahlt es sich aus, die Cache hart zu löschen. 

rm -rf var/cache

Datenbank Upgrade 

Das Datenbank Upgrade ist dann eigentlich relativ easy. Einfach die entsprechende Upgrade Datei ausführen und warten. Bei größeren Upgrades zahlt es sich aus, wenn man schrittweise vorgeht. Z.B. ist es nahezu unmöglich in einem Zug von Prestashop 1.4 auf Prestashop 1.7 zu aktualisieren. Wichtiges ist hier, zum Schluss alle Ausgaben zu kontrollieren und auf Fehler und Warnungen zu überprüfen. Manchmal hilft es, nicht die aktuellste mögliche PHP Version zu verwenden.

php install/upgrade/upgrade.php

Weitere Komponenten 

Natürlich müssen jetzt auch noch gegebenenfalls die Themes, die PDF-Dateien oder die E-Mail Dateien aktualisiert werden. Das funktioniert ähnlich, Programme wie WinMerge oder die in PHPStorm eingebaute Vergleichen Funktion helfen hier auch überschriebene Änderungen nicht zu vergessen. 

 

Permalink: https://to.ptmr.io/3m3ed