MySQL Dump bei Shopware haben manchmal das Problem, dass DEFINER und Datenbanknamen an Triggers mit exportiert werden, die nicht zur neuen Datenbank passen, wenn die Datenbank anders heißt und man einen anderen Benutzernamen hat.
Man kann dann mit einem Texteditor wie nano, vi oder Notepad++ die Datei durchsuchen und es per Hand fixen. Nur doof wenn die Datei 6GB groß ist und keiner der Editoren mehr so richtig performant mit der Datei arbeiten will.
Dafür gibt es dann in der Linux Kommandozeile sed:
mysqldump -u demouser -p demo_webshop > ./dump_for_65_update.sql
sed 's/`demo_webshop`.//g' dump_for_65_update.sql > dump_for_65_update_clean.sql
sed -i 's|/\*!50017 DEFINER=`demouser`@`localhost`\*/||g' dump_for_65_update_clean.sql
mysql --database=demo65_webshop --user=demouser65 -p < ./dump_for_65_update_clean.sql
Man kann da sicher noch allgemeine Ausdrücke für schreiben, aber das lag dieses mal außerhalb dem was der Kunde bezahlt hätte.
Shopware: Update von 6.4 auf 6.5
An sich geht es ganz einfach. In der Administration geht man auf Update, bestätigt alles, die Plugins werden deaktiviert (vielleicht auch das Language-Pack) und dann startet der Installer und .. läuft in einen Fehler und dann läuft garnichts mehr. Scheint jeden Falls öfters mal so zu passieren.
Ich hab mir ein Script gebastelt mit dem man sich eine Kopie des Shops auf die neue Version updaten kann und dann später auf diese Kopie switchen kann.
Man muss nicht alle Plugins deaktiveren, aber einfacher ist es. Also eine Kopie (Dateien und Datenbank) anlegen und da alles Plugins deaktiveren. Per SQL-Statement geht es recht schnell und einfach.
Der original Shop liegt in shop/ und der neue in shop65/. Die .env der Kopie (wegen DATABASE_URL) wird in shop_shared/ abgelegt und um LOCK_DSN="flock" und SHOPWARE_SKIP_WEBINSTALLER=1 ergänzen.
Dann das Script laufen lassen.. oder besser Zeile für Zeile per Hand ausführen.
rm -rf ~/public_html/shop65/{*,.*}
composer create-project shopware/production ~/public_html/shop65 "v6.5.0.0" --no-interaction
rsync -avh ~/public_html/shop/files/ ~/public_html/shop65/files/
rsync -avh ~/public_html/shop/public/bundles/ ~/public_html/shop65/public/bundles/
rsync -avh ~/public_html/shop/public/css/ ~/public_html/shop65/public/css/
rsync -avh ~/public_html/shop/public/fonts/ ~/public_html/shop65/public/fonts/
rsync -avh ~/public_html/shop/public/js/ ~/public_html/shop65/public/js/
rsync -avh ~/public_html/shop/public/media/ ~/public_html/shop65/public/media/
rsync -avh ~/public_html/shop/public/sitemap/ ~/public_html/shop65/public/sitemap/
rsync -avh ~/public_html/shop/public/theme/ ~/public_html/shop65/public/theme/
rsync -avh ~/public_html/shop/public/thumbnail/ ~/public_html/shop65/public/thumbnail/
rsync -avh ~/public_html/shop/public/.htaccess ~/public_html/shop65/public/.htaccess
rsync -avh ~/public_html/shop/var/log/ ~/public_html/shop65/var/log/
rsync -avh ~/public_html/shop/config/jwt/ ~/public_html/shop65/config/jwt
rsync -avh ~/public_html/shop/custom/ ~/public_html/shop65/custom/
rsync -avh ~/public_html/shop_shared/.env ~/public_html/shop65/.env
cd ~/public_html/shop65 && composer update
cd ~/public_html/shop65 && bin/console system:update:finish
cd ~/public_html/shop65/vendor/shopware/administration/Resources/app/administration && npm install && cd ~/public_html/shop65
Ziel ist es wieder in die Administration zu kommen und dort alle Plugins zu aktualisieren. Wenn das gelungen ist, dann alle nach und nach wieder aktivieren und wieder die Themes in den SalesChannels einrichten.
Wenn Fehler auftreten immer mal wieder bin/console aufrufen, weil dann die Exceptions meistens ganz gut dargestellt wird.
So kommt man auch sehr gut ohne den Installer zu seinem aktuellen Shopware und räumt auch direkt noch etwas auf.
Das hat bei mir geholfen. Danach initialisiert er sich einmal wieder sauber neu und due ausstehenden Updates funktionieren ohne Probleme:
killall snap-store
snap refresh
Wer noch auf der 0.4.1 Version ist, kann über diesen weg https://certbot.eff.org/lets-encrypt/ubuntuxenial-apache updaten. Es wird nicht nur Certbot installiert sondern auch eine aktuelle Version "letsencryp"
sudo letsencrypt --version
und alles andere funktioniert danach wie vorher.
Damit ich nicht jedes mal neu suchen muss, hier als Notiz für mich und alle anderen natürlich auch:
define('FS_METHOD', 'direct');
zur wp-config.php hinzufügen und Rechte setzen.
Wenn beim Versuch Shopware zu updaten, der Prozess-Dialog ewig läuft und dann irgendwann das Backenend einfach neu lädt, kann es am media/ Verzeichnis liegen. Ich hab, als das Problem bei meinem lokalen Entwickler-Shop auftrat erst einmal alle leeren Verzeichnisse entfernt mit
sudo find media/ -type d -empty -delete
Dann noch mal die Rechte für die Dateien neu gesetzt (wegen über SCP hochgeladene Plugins oder so) und nachdem das Backend zwei mal neugeladen wurde, lief das Update sofort und ohne Probleme an. Hat mich zwar einige Stunden gekostet, bis alles soweit war, aber endlich wieder Updaten zu können ist es auch wert.
Beim Umstieg von einer alten PHP Version auf PHP7.0 werden viele sicher gleich sich daran machen auch den ganzen Rest mal auf eine aktuelle Version zu migrieren. Dazu gehört dann oft auch eine aktuelle MySQL-Version.
Aber manchmal laufen dann ältere Queries nicht mehr. Das Beste ich dann natürlich das Query anzupassen. Wenn man aber nicht so viel Zeit hat oder sich erst später mit den Problem beschäftigen möchte, hilft es oft die problematischen neuen Modes zu deaktivieren.
Besipiel wäre hier der ONLY_FULL_GROUP_BY-Mode
SET sql_mode=(SELECT REPLACE(@@sql_mode,'ONLY_FULL_GROUP_BY',''));
Bei PDO kann man das Stament direkt als PDO::MYSQL_ATTR_INIT_COMMAND setzen, so dass es bei jeder neuen Verbindung gleich gesetzt wird.
bezahlt von 
Blog: Blog-entries by search-pattern/Tags:
