Je nach Shopgröße und eingesetzter Plugins ist ein Shopware Update ein Klacks oder eine große Herausforderung. Hier ein paar Eindrücke und Tipps zum Thema Update.
Vorbereitungen für das Update
Ihr solltet, je nach Traffic, euer Update immer zu Zeiten durchführen in denen Ihr wenig Traffic habt:
Wir versuchen es meist um 05:00 Uhr zu starten – wenn viel am ganzen hängt wacht man auch teilweise schon nervös um 03:00 Uhr auf 😉
Ich denke das bis auf wenige Ausnahmen die meisten Shops von 01:00 – 07:00 Uhr am wenigsten Traffic haben. Daher bietet sich die Zeit um 05:00 Uhr an, da man noch Zeit hat über den Tag Dinge glatt zu ziehen und im Notfall auch noch um 06:00 Uhr ein Rollback machen kann.
.htaccess (Apache2.4)
Damit auf eurem Shop während des Updates niemand mehr drauf kommt, solltet Ihr den Shop via .htaccess von der Außenwelt trennen. Das ganze kann Shopware auch von Haus:
// Check for active auto update or manual update
if (is_file('files/update/update.json') || is_dir('update-assets')) {
header('Content-type: text/html; charset=utf-8', true, 503);
header('Status: 503 Service Temporarily Unavailable');
header('Retry-After: 1200');
if (file_exists(__DIR__ . '/maintenance.html')) {
echo file_get_contents(__DIR__ . '/maintenance.html');
} else {
echo file_get_contents(__DIR__ . '/recovery/update/maintenance.html');
}
return;
}
Ich klemme den Shop aber gerne selbst vorher vom Traffic ab.
<IfModule mod_authz_core.c>
Require all denied
Require ip 13.37.x.x
</IfModule>
ErrorDocument 403 /custom_error.html
Wichtig dabei ist das Ihr mod_authz_core aktiviert habt (seht Ihr in eurer phpinfo) und das Ihr eure IP Adress eintragt. Legt euch einfach eine HTML File im Rootverzeichnis ab.
.conf (NGINX)
Falls Ihr NGINX nutzt könnt Ihr keine .htaccess File nutzen. Ihr müsst dann über euren Config File des V-Hosts gehen (unter /etc/nginx/sites-available/deineconffile)
Dort suchst du nach der Zeile
location / {
}
und fügst deine Adresse mit Allow ein und alle anderen mit deny – like so.
location / {
allow 13.37.x.x;
allow 127.0.0.1;
deny all;
Für eine Error Page braucht Ihr noch folgenden Inhalt:
error_page 403 /error403.html;
location = /error403.html {
root /var/www/shopware ;
}
Das ganze erfordert einen restart des nginx service:
sudo service nginx restart
Backup anlegen
Sichert euch immer den Pre-Update Stand eures Shopsystems. Auch wenn es nur ein Minor Update ist, lokal lief alles super und Ihr seid euch sicher das nichts schief geht. Backup muss IMMER sein.
Wenn Ihr SSH Zugriff auf euren Server habt nutzt einfach 2 einfache Befehle. Legt euch dafür am besten einen Backup Ordner im Home Verzeichnis an.
mkdir ~/BACKUP
rsync
Grundsätzlich würde ich die Ordner media, var und web ausschließen.
rsync -avz --exclude /media/ --exclude /var/ --exclude /web/cache/ /var/www/DEINPFADZUMDOCROOT/ /home/UNIXUSER/BACKUP/shopware/docroot/
mysqldump
mysqldump -h SERVERIP -uUSER -p --lock-tables --default-character-set=utf8 shopware > /home/UNIXUSER/BACKUP/shopware/db/live_backup.sql
Update Rollback
Sollte es zu gravierenden Fehlern kommen, muss eine schnelle Lösung des Rollbacks verfügbar sein. Ich empfehle euch parallel zum Update des Shops einen Import des gesicherten Dumps zu starten, so habt Ihr schnell eine saubere Instanz zu Hand.
mysql -h SERVERIP -uUSER -p --default-character-set=utf8 shopware_rollback < /home/UNIXUSER/BACKUP/shopware/db/live_backup.sql
Das gleiche könnt Ihr natürlich auch mit eurem Docroot machen – je nach Hoster könnt Ihr V-Host Einstellungen selbst vornehmen, falls dies nicht der Fall ist schiebt eure gesicherten Daten mit rsync und –delete zurück.
rsync -avz --exclude /media/ --exclude /config.php --exclude /.htaccess --exclude /var/ --exclude /web/cache/ --delete /home/UNIXUSER/BACKUP/shopware/docroot/ /var/www/DEINPFADZUMDOCROOT/
Tipp: Bevor Ihr das ganze macht – führt einen dry run mit -n aus um zu schauen ob auch alles richtig gesynct wird.
rsync -avzn --exclude /media/ --exclude /config.php --exclude /.htaccess --exclude /var/ --exclude /web/cache/ --delete /home/UNIXUSER/BACKUP/shopware/docroot/ /var/www/DEINPFADZUMDOCROOT/
Update über das Backend
Wie jedes Update gilt es auch hier vorab ausreichend zu testen. Entweder auf einem Staging System oder lokal. Bestenfalls mit dem gleichen Setup (DB Version, PHP Version, Webserver etc.).
Kleine Shops mit wenig Artikeln und Bildern können das auch ohne Probleme so machen, bei größeren Setups bietet sich allerdings die Variante über die Konsole an. Warum? Shopware hat einige Methoden in seinem SwagUpdate Plugin welche bei größeren Ordnern LAAAAANGE dauern bis Sie durchgelaufen sind.
public function isUpdateAllowedAction()
{
$fs = new \ShopwarePlugins\SwagUpdate\Components\FileSystem();
$result = $fs->checkDirectoryPermissions(Shopware()->DocPath(), true);
if (!empty($result)) {
$wrongPermissionCount = count($result);
$this->container->get('corelogger')->error(
sprintf('SwagUpdate: There are %d files without write permission. FTP credentials are needed.', $wrongPermissionCount),
$result
);
$this->View()->assign([
'success' => true,
'ftpRequired' => true,
'wrongPermissionCount' => $wrongPermissionCount,
]);
return;
}
$this->View()->assign([
'success' => true,
'ftpRequired' => false,
]);
}
Hier wird geprüft ob alle Permissions richtig gesetzt wurden. Bei einem Media Ordner > 10GB und keine SSD kann das eine ganze Zeit dauern. So lange ist der Shop natürlich im Wartungsmodus und nicht erreichbar.
Update über die Konsole
Solltet Ihr eine Menge an Media Files haben, habt Ihr sicherlich auch einen eigenen Server auf den Ihr über SSH zugreifen könnt. In diesem Fall empfehle ich euch auf jeden Fall das Update über die Konsole. Zieht euch dafür einfach das entsprechende Update Zip File HIER und entpackt es mit
unzip DEINESWVERSION.zip
in eurem Shopware Root Verzeichnis. Danach sind es nur noch 2 Befehle oder einer zusammen (siehe HIER)
php recovery/update/index.php
Danach folgst du einfach den Anweisungen – im Endeffekt ist das einmal Enter für das starten und danach werden die Snippets etc. in die Datenbank geschrieben. Schlussendlich nur das aufräumen/löschen der Files
rm -r update-assets/
Das ganze kannst du auch einfach in einem Einzeiler machen:
php recovery/update/index.php --no-interaction --quiet && rm -r update-assets/
Post Update
Oft wird das vergessen, aber Ihr solltet wirklich euren Browser Cache leeren 😉 – das kann nämlich zu einem komischen Verhalten führen. Loggt euch im Backend ein und führt falls notwendig Plugin Updates durch. Diese sind teilweise nötig nach einem Update (besonders bei 5.x Updates) – Ihr solltet auch direkt den Cache leeren. Entweder über das Backend oder über die Konsole mit:
php bin/console sw:cache:clear
Denkt daran das noch kein Kunde auf euren Shop kommt. Ihr könnt euren Shop durch die .htaccess oder Conf File vom NGINX schon testen. Geht ins Frontend und schaut euch an ob alles soweit passt. Wenn Ihr Frontend Tests habt, lasst diese laufen, damit Ihr euch sicher seid das In den Warenkorb, Checkout, Register und andere kritische Dinge auch funktionieren.
Passt alles könnt Ihr euren Shop wieder Live nehmen. Denkt daran das Ihr den Shop je nach Traffic die ersten 24 Stunden genau monitored. Teilweise schleichen sich fiese Dinge ein, welche so einfach nicht getestet oder schlichtweg vergessen wurden.
Ich wünsche euch viel Erfolg beim Update! Mit Shopware 5.4 soll das ganze ja einfacher werden, sobald die Version 5.4.1 kommt werde ich darüber berichten (in dieser Version soll ein Update im Livebetrieb möglich sein – pro Appserver bei einem Clustersetup).
Warum dieser Artikel?
Unser letztes Update auf Shopware 5.3.7 war sehr aufwendig und komplex (einige Subshops, komplettes Refaktoring des Themes, Wegfall von Plugins etc.) und es kam zu einigen Sonderfällen. Unter anderem auch wegen der unterirdischen Performance des PriceSortingHandlers (siehe HIER) war das ein turbulentes Update. Aber Ende gut, alles gut – zur Feier gab’s dann noch einen Kuchen 🙂
