wo ich auf continue drücken kann und anschließend auf das Wartungsfenster gelang. Das Update wird nicht durchgeführt. Was läuft falsch? könnte es eine fehlerhafte ngnix konfiguration sein?
Das Update von 6.4.19. auf → 6.4.20.2 hab ich manuell über die Konsole problemlos hinbekommen. Beim update auf 6.5 scheitere ich komplett und mir fliegt alles um die Ohren. Schritte in der Doku hab ich natürlich befolgt, composer.json:
…
„require“: {
„php“: „^7.4.3 || ^8.0“,
„composer-runtime-api“: „^2.0“,
„shopware/administration“: „~v6.5.0“,
„shopware/core“: „~v6.5.0“,
„shopware/elasticsearch“: „~v6.5.0“,
„shopware/storefront“: „~v6.5.0“
},
…
PHP Version PHP 8.2.8
Error nach composer update:
Your requirements could not be resolved to an installable set of packages.
Problem 1
- shopware/core[6.5.0.0, …, v6.5.2.1] require league/flysystem-memory ~3.10 → found league/flysystem-memory[3.10.3, 3.13.0, 3.15.0] but it conflicts with your root composer.json require (~1.0.2).
- shopware/core[v6.5.3.0, …, v6.5.3.3] require league/flysystem-memory ^3.10.3 → found league/flysystem-memory[3.10.3, 3.13.0, 3.15.0] but it conflicts with your root composer.json require (~1.0.2).
- Root composer.json requires shopware/core ~v6.5.0 → satisfiable by shopware/core[6.5.0.0, …, v6.5.3.3].
Die Fehler in der Konsole, hab ich probiert manuell nach und nach zu beseitigen, bis ich dann auf deprecated composer packages stoße und nicht mehr weiter weiß, da diese ja im quellcode erforderlich sin… jemand ne idee? Danke!
Ich musste das Upgrade jetzt auch schon mehrfach machen.
Wichtig ist, vor dem Upgrade alle Plugins zu deaktivieren und alle Verkaufskanäle dem Standard-Theme zuzuweisen und das verwendete Theme zu ebenfalls zu deaktivieren.
Dann müsste das Upgrade im Backend korrekt durchlaufen.
Ich musste noch nodejs auf V 18 aktualisieren, aber das ist glaube ich für das Upgrade nicht notwendig.
Danke. Aber leider hab ich die Schritte bereits vorher schon durchgeführt …
Ich habe mir testweise sogar mal eine komplett neue Shopwareinstanz auf dem Server installiert, kein Theme, keine Plugins - das update funktioniert auch da nicht. Das heißt dass das ganze ja irgendwelche Rückschlüsse auf meine Serverkonfiguration schließen muss oder auf eine fehlerhafte Updateversion, wobei es ja bei einigen gut läuft…
Machst du das Upgrade via Composer?
Vielleicht mal Composer updaten, wenn das zu alt ist, oder manchmal auch zu neu, kann es auch zu komischen Fehlern kommen.
Allerdings würde ich empfehlen, das Upgrade direkt in Shopware zu machen, also unter System → Shopware-Aktualisierung.
Falls du es weiter mit Composer versuchen willst, das sind die Pakete die bei mir installiert sind:
Machst du das Update per Composer? Ich würde es über das Installer-/Update-Paket versuchen. „Größere“ Composer-Updates sind manchmal etwas tricky.
Wichtige Frage: Hast du einen Git-Client auf dem Server (einfach mal „git“ auf der Konsole eingeben) - das benötigst du ab 6.5 für die Installation/Updates.
Schritte:
Saubere 6.4 Installation
alle Plugins deaktivieren
Git per Konsole prüfen / PHP >= 8.1?
shopware-installer.phar.php in /…/webroot/public laden
Mit Composer leider keinen Erfolg, auch nicht mit deinen packages.
Your requirements could not be resolved to an installable set of packages.
Your requirements could not be resolved to an installable set of packages.
Problem 1
- Root composer.json requires shopware/core v6.5.2.1 -> satisfiable by shopware/core[v6.5.2.1].
- shopware/core v6.5.2.1 requires league/flysystem-memory ~3.10 -> found league/flysystem-memory[3.10.3, 3.13.0, 3.15.0] but it conflicts with your root composer.json require (~1.0.2).
Problem 2
- Root composer.json requires shopware/storefront v6.5.2.1 -> satisfiable by shopware/storefront[v6.5.2.1].
- shopware/storefront v6.5.2.1 requires symfony/dependency-injection ~6.3.0 -> found symfony/dependency-injection[v6.3.0, v6.3.1] but it conflicts with your root composer.json require (~4.4 || ~5.2.3 || ~5.3.0 || ~5.4.0).
Problem 3
- shopware/core v6.5.2.1 requires league/flysystem-memory ~3.10 -> found league/flysystem-memory[3.10.3, 3.13.0, 3.15.0] but it conflicts with your root composer.json require (~1.0.2).
- shopware/elasticsearch v6.5.2.1 requires shopware/core v6.5.2.1 -> satisfiable by shopware/core[v6.5.2.1].
- Root composer.json requires shopware/elasticsearch v6.5.2.1 -> satisfiable by shopware/elasticsearch[v6.5.2.1].
Über den normalen Updater funktioniert es ja leider auch nicht, da ich auf die Broken Page gelangen und dann nur auf conitnue drücken kann, aber dann der Pfad zu configure also „https://xxxx/shopware-installer.phar.php/configure“ nicht gefunden werden konnte.
Probiere es mal wirklich mit dem Update der direkt im Shop ist, nicht die installer.phar die man herunterladen muss.
Alle Plugins deaktivieren, alle Themes deaktivieren dann unter Einstellungen → System → Shopware-Aktualisierung die Aktualisierung ausführen.
Wenn du eigene Composer Plugins hinzugefügt hast, diese vorher auch deinstallieren.
Wenn das nicht funktioniert, weiß ich auch nicht weiter.
Bei dem Screenshot mit dem ungestylten autoupdater tippe ich darauf, dass du in deiner Konfigurationsdatei noch folgenden Code Block hast, den man in vielen Muster-Konfigurationsdateien findet:
location ~* ^.+\.(?:cur|jpe?g|gif|js|css|ico|png|svg|webp|html|woff|woff2)$ {
expires 1y;
add_header Cache-Control "public, must-revalidate, proxy-revalidate";
[...] und so weiter
Hier muss in der ersten Zeile das „js“ und „css“ raus (zumindest für den autoupdater), dann sieht das auch wieder hübsch aus (–> css) und der Button „continue“ funktioniert (–> js).
Also so:
Danke für deine Antwort, hat leider auch nicht geklappt. Bzw hatte ich diese ganzen Zeilen überhaupt nicht in meiner ngnix config und hab diese nun ergänzt:
gleiches Spiel → broken page → Unsere Website befindet sich gerade in der Wartung…
Wäre ja auch hammer wenn showpare selbst mal irgendwelche Infos dazu preis geben würde…
ach schade. Damit hatte es bei uns funktioniert. Ich poste dir zur Sicherheit mal eine komplette nginx Konfiguration von einer Kundeninstanz, die wir per Webupdater von 6.4.x auf 6.5.3 aktualisiert haben.
Auf den ersten Blick sehe ich aber in deiner Konfiguration nichts auffälliges.
# FORGE CONFIG (DO NOT REMOVE!)
include forge-conf/xxxxxxxxxx/before/*;
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name xxxxxxxxxx;
server_tokens off;
root /home/forge/xxxxxxxxxx/public;
# FORGE SSL (DO NOT REMOVE!)
ssl_certificate /etc/nginx/ssl/xxxxxxxxxx/server.crt;
ssl_certificate_key /etc/nginx/ssl/xxxxxxxxxx/server.key;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;
ssl_dhparam /etc/nginx/dhparams.pem;
add_header X-Frame-Options "SAMEORIGIN";
add_header X-XSS-Protection "1; mode=block";
add_header X-Content-Type-Options "nosniff";
index index.html index.htm index.php;
charset utf-8;
# FORGE CONFIG (DO NOT REMOVE!)
include forge-conf/xxxxxxxxxx/server/*;
# Needed for Shopware install / update
# new for Shopware 6.5
location /shopware-installer.phar.php {
try_files $uri /shopware-installer.phar.php$is_args$args;
}
location /recovery/install {
index index.php;
try_files $uri /recovery/install/index.php$is_args$args;
}
location /recovery/update/ {
location /recovery/update/assets {
}
if (!-e $request_filename){
rewrite . /recovery/update/index.php last;
}
}
location ~* ^.+\.(?:cur|jpe?g|gif|ico|png|svg|webp|html|woff|woff2)$ {
expires 1y;
add_header Cache-Control "public, must-revalidate, proxy-revalidate";
access_log off;
# The directive enables or disables messages in error_log about files not found on disk.
log_not_found off;
tcp_nodelay off;
## Set the OS file cache.
open_file_cache max=3000 inactive=120s;
open_file_cache_valid 45s;
open_file_cache_min_uses 2;
open_file_cache_errors off;
}
location ~* ^.+\.svg$ {
add_header Content-Security-Policy "script-src 'none'";
}
location / {
try_files $uri /index.php$is_args$args;
}
location = /favicon.ico { access_log off; log_not_found off; }
location = /robots.txt { access_log off; log_not_found off; }
access_log off;
error_log /var/log/nginx/xxxxxxxxxx-error.log error;
error_page 404 /index.php;
location ~ \.php$ {
fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_pass unix:/var/run/php/php8.1-fpm.sock;
fastcgi_index index.php;
include fastcgi_params;
}
location ~ /\.(?!well-known).* {
deny all;
}
}
# FORGE CONFIG (DO NOT REMOVE!)
include forge-conf/xxxxxxxxxx/after/*;
Danke dir, leider kein Erfolg. Darf ich fragen wo und wie du deinen Shop hostest?
Langsam hab ich keine Ideen mehr…eine Rechte Problematik kann ich eigentlich auch ausschließen, da das update von 6.4.19 → 6.4.20 ja funktioniert hat…
SensioFrameworkExtraBundle, Enqueue\Bundle und Enqueue\MessengerAdapter\Bundle müssen aus der composer.json entfernt werden (falls überhaupt vorhanden) und scheinbar auch aus der config/bundles.php. Danach läuft das update auf 6.5.3.3
Richtig schwach, dass es hierzu keinerlei infos/dokus gibt und man sich ne Woche nen Wolf absuchen muss.
Danke an alle Lösungsvorschläge
Dieser Workaround funktioniert, ist aber möglicherweise nicht ganz sauber oder vollständig. Um sicherzustellen, dass die verwendeten statischen Dateien, die durch die phar.php-Datei generiert werden, auch von PHP ausgeführt werden, können Sie eine zusätzliche Location hinzufügen. Dadurch funktioniert der Updater vollständig, also auch mit Bildern, und Sie müssen die Bedingungen des tatsächlich statischen Standorts nicht anpassen. Das sieht dann so aus:
Nginx example code
# Enable Shopware 6.5 installer
location /shopware-installer.phar.php {
try_files $uri /shopware-installer.phar.php$is_args$args;
}
# Run static files generated by shopware-installer.phar.php through PHP
location ~ ^/shopware-installer\.phar\.php/.+\.(?:css|js|png|svg|woff)$ {
try_files $uri /shopware-installer.phar.php$is_args$args;
}
location /recovery/install {
index index.php;
try_files $uri /recovery/install/index.php$is_args$args;
}
location /recovery/update/ {
if (!-e $request_filename){
rewrite . /recovery/update/index.php last;
}
}
location ~* ^.+\.(?:css|cur|js|jpe?g|gif|ico|png|svg|webp|htm|woff|woff2|xml)$ {
expires 1y;
add_header Cache-Control "public, must-revalidate, proxy-revalidate";
access_log off;
# The directive enables or disables messages in error_log about files not found on disk.
log_not_found off;
tcp_nodelay off;
## Set the OS file cache.
open_file_cache max=3000 inactive=120s;
open_file_cache_valid 45s;
open_file_cache_min_uses 2;
open_file_cache_errors off;
}
location ~* ^.+\.svg$ {
add_header Content-Security-Policy "script-src 'none'";
}
# Forward any not found file to index.php. Also allows to have beautiful urls like /homemade-products/
location / {
try_files $uri /index.php$is_args$args;
}
# Let php-fpm handle .php files
location ~ \.php$ {
fastcgi_split_path_info ^(.+\.php)(/.+)$;
include fastcgi.conf;
fastcgi_param HTTP_PROXY "";
fastcgi_buffers 8 16k;
fastcgi_buffer_size 32k;
fastcgi_read_timeout 300s;
client_body_buffer_size 128k;
fastcgi_pass unix:/run/php/php8.1-fpm.sock;
http2_push_preload on;
}
