Php 8.0, 404 für Artikeldetailseiten

Ahoi,
habe heute einen aktuellen Produktivklon in einer Entwicklungsumgebung testweise auf php 8.0 angehoben. Lief auf den ersten Blick soweit geschmeidig. Testkäufe gingen problemlos durch.
Also php8.0 kurzerhand im Produktivshop aktiviert. Auch hier auf den ersten Blick alles schick. Allerdings fielen mir nach einiger Zeit im Weblog vermehrt 404-Meldungen für Artikeldetailseiten auf. Und bei näherem Hinsehen waren das gar nicht so wenig. Die Artikel werden in den Übersichtsseiten korrekt dargestellt, nur die Detailseite funktioniert nicht und es wird „Dieser Artikel ist leider nicht mehr verfügbar!“ zurückgemeldet. Weiter nachgeforscht betraf dies alle Artikel einer speziellen Kategorie UND neu gegründete Artikel, egal in welcher Kategorie. Leider konnte ich außer im Weblog in allen weiteren zur Verfügung stehenden Protokollen (nginx-scripts, php-fpm, shopware-core) keine weiteren oder detaillierteren Fehlermeldungen oder auch nur einen Hinweis auf das Problem erspähen. Die Suchmaschinen blieben auch ratlos. Also habe ich das System jetzt nach 2h Suche wieder auf php 7.4 zurückgedreht und alles funktioniert wieder schick. Die Umstellung auf php 8.0 lasse ich also vorerst bleiben. Mein Eintrag ist also hauptsächlich für diejenigen, die per Suchmaschine hier her stolpern und sich 2h Suche ersparen möchten.

debian 11
kernel 5.10.84-1
php 8.0.14
nginx 1.20.2
mariadb 10.6.5
shopware 5.7.6

Besten Gruß!
Wolf

Hallo Wolf,

wäre interessant zu wissen, wie der genau Fehler aussieht. Vielleicht hilft dir dieser Artikel dabei: Shopware 5 - Tutorials & FAQs - Fehlermeldungen in Shopware debuggen

Viele Grüße aus Schöppingen
Michael Telgmann

Grüß Sie Herr Telgmann, vielen Dank für die Antwort mit dem Verweis auf den Debugging-Artikel. Ich lese mich rein und gebe Ihnen Rückmeldung. Besten Gruß! Wolf

1 „Gefällt mir“

Grüß Sie Herr Telgmann,
habe mir heute Zeit genommen dem Fehler auf den Grund zu gehen. Da der Fehler allem Anschein nach im php hockt, habe ich
die FPM-Protokollierung für den www-pool aktiviert. Macht er brav. Und hier zeigt sich nun die Merkwürdigkeit und Beiwerk:

7.4-FPM
shopware.php 200

8.0-FPM / 8.1-FPM
shopware.php 404

php.ini, php-fpm.ini und pool.d/www.conf sind in allen Versionen identisch konfiguriert.
Ich dachte dann zunächst an ein Berechtigungsproblem.

  • phpX.X-fpm laufen alle mit dem u:php g:nginx
  • shopware.php: 400 php.root
    Habe die shopware.php mal auf 770 php.nginx gesetzt, keine Änderung.

Das error_log für php habe ich dann auf ‚debug‘ gesetzt. Keine weiteren Hinweise im Log.
Nun gehen mir die Ideen aus.

Besten Gruß!
Wolf

So sieht es bei php7.4-fpm aus.

Hallo,

und mit der Debug-Config waren keine Einträge in den Logs von Shopware selber zu sehen? :thinking:

Viele Grüße aus Schöppingen
Michael Telgmann

Randbemerkung: Musste kürzlich bei einigen Kunden auch feststellen, dass viele Plugins NICHT mit PHP8 kompatibel sind. Sie zeigen zwar an Kompatibel mit Shopware 5.7.x aber leider nicht auf PHP8. Könnte bei euch eine ähnliche Ursache sein.

Moin!
Habe mir die Sache jetzt in einer dev-Umgebung nochmal angesehen, weil’s mich fuchst und nun ja irgendwann mal php8.x Einzug halten muß. Vorab, weil es noch im Raume stand: alle externen Plugins sind deaktivert, Standard-Theme aktiviert.

Protokollierung:

Mit folgender URL testete ich:
'https://meinshop.de/detail/index/sArticle/148392'

Ergebnis:
php74: 200
php80: 404
php81: 404

Ergebnisse im Log:
shopware: keine Fehlermeldungen (core_production-2022-05-25.log ist leer)
php-fpm: keine Auffälligkeiten bzw Unterschiede zwischen den beiden Aufrufen unter jeweils 74 oder 81
nginx: dadurch, daß ich nur den Socket in der Config ändere, gibt es im Debug-Log nur Unterschiede beim dem was FPM liefert. Der FPM übergibt den 404 an nginx (http fastcgi header: „Status: 404 Not Found“)

Also habe ich die Querys im mariadb-general-log gedifft.
Und hier zeigen sich tatsächlich große Unterschiede. Ich habe nur den Vorgang des Seitenaufrufs mitgeschnitten und verglichen (bin in der DEV-Umgebung der einzige Nutzer).
Nun bin ich zuwenig im sw-Innenleben zu Hause um sofort beurteilen zu können, ob es am php-mysql-Modul liegt, oder aber shopware je nach php-Version die Abfragen anders aufbaut.

Wenn es jemanden interessiert, hänge ich die Logs gerne hier rein.

Habe noch drei andere Shops laufen, werde das ganze auch mal für die in einer DEV-Umgebung austesten und berichten.

Besten Gruß!
Wolf

1 „Gefällt mir“

Guten Abend,
habe das Problem durch das mysql-Log finden können. Sobald ein Artikel keine Cross-Selling-Produkte manuell zugeordnet bekam, schlägt in php8.x die automatische Ermittlung selbiger fehl, was letztlich in einem 404 resultiert. In php7.x ist die Abfrage anders und offenbar toleranter: die Detail-Seite des Artikels wird auch dann angezeigt, wenn keine Cross-Selling-Produkte vorhanden sind. Jetzt habe ich im Backend die automatische Ermittlung ähnlicher Artikel auf 0 gesetzt und die Detailansicht klappt auch unter php8.x, wenn kein Cross-Selling-Artikel manuell zugeordnet wurde. Das ist für unseren Shop kein Problem. Für andere u.U. schon.

Gruß!
Wolf

Nachtrag:
Habe die Einstellung im Backend zur automatischen Ermittlung ähnlicher Artikel jetzt nochmal durchprobiert. Ganze Zahlen funktionieren von shopware-Seite tadellos - und dafür ist das Feld letztlich ja sicherlich auch nur gemacht. Ich hatte aus mir nicht mehr nachvollziehbaren Gründen seit Jahren dort den Wert 0,1 drinstehen, mich auch nicht darum gekümmert, weil nicht benötigt. php7.x nimmt hier keinen Anstoß. Ab php8.x geht das schief.
Gruß!
Wolf