Wir haben heute unseren Server auf PHP 8.3.36 umgestellt. Laut Recherchen im Netz können unter Shopware 5 zahlreiche Probleme auftauchen. Mir ist bisher noch nichts aufgefallen, obwohl wir ca. 80 Plugins im Einsatz haben. Mich würde es interessieren ob Jemand dieses Update ausgeführt hat und Störungen irgendeiner Art auftreten.
Das solltest du eigentlich einfach kontrollieren können, indem du deinen gesamten Quellcode auf Funktionen durchsuchst, die in 8.3 entfernt wurden.
Ich habe heute einen SW5 Shop mit PHP 8.4.x getestet. Zumindest der Bestellprozess mit Vorkasse verlief ohne Fehler. Problem sehe ich eher bei diversen Plugins.
Danke für die Info. Die nächste Sicherheitslücke kommt bestimmt. 
Max_Shops Ansatz stimmt: Was mit 8.3 entfernt wurde, lässt sich im Code finden. Der erste Schritt ist für mich aber ein Blick in die Logs. R4Ms Test mit Vorkasse ist ein gutes Zeichen für den Core, und die Plugins sehe ich auch als das größere Risiko.
Da ich alle von mir betreuten Shops schon auf Shopware 6 umgezogen habe, kann ich nicht aus Erfahrung sagen, wie sich Shopware 5 mit PHP-Versionen über der unterstützten 8.2 verhält. Ich würde aber so vorgehen:
- Die Logs auswerten, statt auf sichtbare Fehler zu warten. Das meiste kündigt sich zuerst als Deprecated oder Warning an. Ich würde ins PHP-Fehlerlog des Hosters sowie in
var/logschauen und zählen, welche Dateien am häufigsten auftauchen:
grep -oE "in /[^ ]+\.php on line [0-9]+" php_error.log | sort | uniq -c | sort -rn | head -20
Dann sieht man schnell, ob es um ein, zwei Plugins geht oder um mehr. - Kommandozeile und Cronjobs prüfen. Bei vielen Hostern läuft die Konsole mit einer anderen PHP-Version als der Webserver.
php -vauf der Konsole und die PHP-Pfade in der Crontab zeigen, ob Cronjobs, Exporte und Shopware-Befehle wirklich schon unter 8.3 laufen. Sonst ist dieser Teil noch gar nicht getestet. - Die Stellen durchklicken, an denen Fehler nicht im Frontend auffallen. Nach PHP-Updates treten Fehler oft hier auf:
- Zahlungsarten mit externem Anbieter: Die Rückmeldung des Anbieters läuft im Hintergrund. Die Bestellung kommt an, der Zahlstatus bleibt aber offen. Das deckt ein Test mit Vorkasse nicht ab.
- Backend-Module von Plugins: Fehler zeigen sich dort oft nur als leeres Fenster oder Ladefehler.
- Rechnungs-PDF, Lieferschein, Versandlabel, Produktexporte und die Anbindung an die Warenwirtschaft.
- Plugins, die schon länger kein Update bekommen haben.
- Die Plugins statisch prüfen, wenn man es genau wissen will. Das ist Max_Shops Suche nach entfernten Funktionen, nur automatisch: alle Plugins auf einmal, auch Code, der selten läuft. PHP_CodeSniffer mit PHPCompatibility, für PHP 8.x in Version 10, die bisher als Alpha erschienen ist:
phpcs -p custom/plugins engine/Shopware/Plugins --standard=PHPCompatibility --runtime-set testVersion 8.3
Bei 80 Plugins würde ich mit den Logs anfangen. Die zeigen am schnellsten, wo man genauer hinschauen sollte.
Eine Frage interessehalber: Was hält euch bisher bei Shopware 5? Die Plugins, für die es unter Shopware 6 erst Ersatz bräuchte, der Aufwand oder etwas anderes? Ich helfe gern weiter und gebe auch unverbindliche Einschätzungen.
Ende 2027 endet der Support von PHP 8.3 und dann: PHP | endoflife.date
Mittlerweile empfinde ich Shopware 6 als gut. Natürlich gibts Sachen die man verbessern kann.
Also gibts wirklich noch handfeste Sachen bei Shopware 5 zu bleiben und nicht auf Shopware 6 zu wechseln oder gleich zu einem anderen Anbieter zu wechseln?
Der bisherige Grund für mich nicht zu wechseln, ist die Geschäftspolitik von Shopware. Wir sind vor ca. 10 Jahren mit der Community Edition gestartet und haben im Laufe von SW5 ca. 100 Plugins getestet, zum größten Teil auch gekauft und versucht den Shop stetig zu verbessern. Mit der aktuellen Community Edition ist aber, soweit ich das richtig verstanden habe, eine Anbindung an den Shopware Store nicht mehr möglich. Wir arbeiten dazu mit einer geringen Marge, da der Konkurrenzdruck enorm hoch ist. Mit dem Kauf eines Plugins blieben somit in der Vergangenheit die Kosten überschaubar. Nun bezahle ich für ein durchschnittliches Plugin den Kaufpreis gefühlt jeden Monat in Form einer Miete neu. Mit der Community Edition ist aber auch selbst das nicht mehr möglich. Ich soll demnach mind. 600,00 Euro jeden Monat für eine Rise-Edition bezahlen, die im Grunde genommen nichts kann und wenn ich den Bewertungen glauben darf auch keinen wirklichen Support bietet.
Irgendwo möchte man vielleicht auch noch ein wenig Marge übrig haben, was aber mit SW6 für uns eher nicht möglich ist.
Das stimmt so leider nicht. Du kannst selbstverständlich auch mit einer Community Edition die Plugins aus dem Shopware Extension Store mieten. Du brauchst dafür nur zwingend einen Shopware Account - und je nach Größe deines Shops bzw. je nach deinem Umsatz „kann“ daraus eine Pflicht entstehen in einen kostenpflichtigen Plan zu wechseln.
Viele Grüße
Das mit den Kosten kann ich gut nachvollziehen, gerade bei kleiner Marge. Ein paar Sachen lassen sich aber klären.
Store und Community Edition
Eike hat recht, es hängt an einer Zahl: Unter 1 Mio. Euro Jahresumsatz braucht ihr für Account und Store keinen kostenpflichtigen Plan. Gerechnet wird netto mit Versandkosten, Rabatte zählen raus, Retouren nicht. Erst darüber will Shopware Rise oder höher.
Und die Regel gilt nur für Account und Store. Die Community Edition bleibt Open Source (MIT), ein Plugin das ihr selbst installiert braucht also weder Store noch Plan.
Miete
Stimmt leider, im Store gibts seit Ende 2023 nur noch Miete. 80 Plugins einfach eins zu eins zu mieten würde ich aber auch nicht.
Vieles ist in SW6 schon drin
Einiges, wofür man unter SW5 ein Plugin brauchte, kann Shopware 6 von Haus aus, auch in der Community Edition:
- Regeln: Bedingungen nach Kundengruppe, Warenkorb, Land, Zahlungs- oder Versandart, z.B. für Versandkosten, Zahlungsarten, Preise und Aktionen
- Flow Builder: Automatisierungen bei Bestellung, Registrierung oder Statuswechsel, also Mail schicken, Tag setzen, Status ändern, Kundengruppe zuweisen, Dokument erzeugen usw.
- Rabatte & Aktionen: Gutscheincodes (einer für alle oder Einzelcodes), Rabatte auf Warenkorb, einzelne Produkte oder Versand, auch „3 kaufen, 2 zahlen“
- Dynamische Produktgruppen: z.B. fürs Cross-Selling
- Zusatzfelder: eigene Felder an Produkten, Kategorien usw. (für die Anzeige im Frontend braucht es eine kleine Template-Anpassung)
- Erlebniswelten: Landingpages und Kategorieseiten zusammenklicken
Mein Vorschlag
Ich würde die aktiven Plugins mal durchgehen und bei jedem kurz notieren, was ihr davon eigentlich nutzt. Oft ist das nur ein kleiner Teil von dem, was das Plugin alles kann. Dann grob sortieren:
- kann der Standard: fällt weg
- Kleinigkeiten (ein Feld hier, eine Anzeige da, eine angepasste Mail, ein Export, eine Prüfung im Checkout): die würde ich in ein oder zwei eigene Plugins zusammenfasen
- große Sachen wie Zahlungsanbieter, Versand oder ERP-Anbindung: da bleibt man meist besser beim Plugin vom Anbieter
Für die Kleinigkeiten hat ein eigenes Plugin ein paar Vorteile:
- weniger Abos: die Entwicklung zahlt ihr einmal, nicht jeden Monat 20 oder 30 Mieten
- leichter zu pflegen: bei jedem Update schaut man auf ein, zwei Plugins statt auf 30 von verschiedenen Herstellern mit jeweils eigenem Update-Rhythmus
- passt genau: gekaufte Plugins bringen jede Menge Einstellungen und Funktionen mit, die ihr nie nutzt. Das ist Code, der mitläuft und bei der Fehlersuche im Weg ist. Ein eigenes Plugin macht nur das was ihr braucht, und zwar so wie ihr arbeitet.
- unabhängig: wie man gerade im Thread zur Differenzbesteuerung sieht, kann ein Hersteller auch einfach aussteigen. Ein eigenes Plugin gehört euch.
Anpassen muss man so ein Plugin bei größeren Shopware-Updates natürlich auch. Aber das ist dann eine Stelle statt vieler, und ihr entscheidet selbst, wann. Und vorallem hängt ein Core-Update nicht mehr an einem veralteten Plugin, dessen Hersteller noch nicht nachgezogen hat.
Bei der Plugin-Prüfung helfe ich gern, meldet euch einfach.
Ich schreib mir meinen eigenen Shop mit Claude, bis dann verwende ich definitiv noch immer 5.6. Mein Hoster hat bei dem PHP Bug ziemlich rasch reagiert. Weiters sehe ich keinen Grund, auf SW6 zu wechseln.
Vielen Dank für die Hinweise. Ehrlich gesagt ist es bereits etwas länger her, dass ich mich mit den unterschiedlichen Shopware Plänen auseinandergesetzt hatte. Vom Umsatz her sind wir (leider) knapp über der Community Edition. Klar könnte man jetzt künstlich dagegen steuern, in dem man Preise / Versandkosten erhöht oder weniger Geld fürs Marketing ausgibt. Aber letztendlich möchte man ja doch irgendwo etwas mehr vom Kuchen. Einen Teil der ehemalig gekauften Plugins habe ich bereits deaktiviert. Deinstallieren lassen sich leider nicht alle. Der ein oder andere Crash beim Deinstallieren in der Testumgebung zeigte uns, das manche Plugins sehr tief ins Geschehen eingreifen. In den nächsten Monaten werde ich aber mal grob aussortieren und nur noch die für uns wichtigen Tools arbeiten lassen.
Einfach nochmal ausprobieren. Der Funktionsumfang von Shopware 6 ist mittlerweile gut, vielleicht brauchst du nicht so viele Plugins wie damals.
Rechnet doch mal durch ob ihr noch Gewinn macht, wenn ihr 600 Euro/Monat für die Rise ausgebt (mit ein paar Plugins vielleicht 700 Euro insgesamt).
Aber schonmal gut das ihr eine Testumgebung habt: wenn dort Fehler auftreten oder der Shop wegen des Plugins stillsteht dann debuggen und den Pluginanbieter einbinden (diese ggf. Benutzer erstellen und dann loggen die sich auch ein). Oder wenn das alles nicht hilft anderes Plugin(-anbieter) nutzen. Bei uns funktioniert ersteres aber ganz gut.
Ich habe gerade mal im SW6 Forum gestöbert. Ist es tatsächlich in SW6 immer noch so, dass es kein eigenständiges Feld für die Hausnummer gibt ? Als wir vor ca. 10 Jahren von XT auf SW5 gewechselt sind, war das für uns erst einmal ein Problem. XT hatte dieses Feld bereits vor 15 Jahren standartmäßig gesetzt. Unter SW5 wurde häufig von den Kunden vergessen die Hausnummer anzugeben. Das ständige Nachfragen hat uns Zeit und Nerven gekostet. Dafür mußten wir ein Plugin kaufen, haben Paypal Express eingeschränkt und das sieht mir bei SW6 jetzt auch wieder so aus, als wenn es nicht ohne das geht oder alternativ gebastelt werden muß. Falls ich mich irre, lasse ich mich gerne belehren.
Ja, das ist korrekt. Shopware pflegt Straße und Hausnummer immer gemeinsamen in einem Feld. Im Store findest du aber Lösungen ab bereits 2,50 EUR im Monat.
Viele Grüße
Ja ist es. Aber schaut man sich die nachgelagerten Systeme an wie ERP: hier gibt’s oftmals auch nur ein Feld Straße. Wäre dann etwas komplizierter später 2 Felder auf eins zu mappen. Ich jedenfalls finde es gut dass es nur ein Feld weiterhin gibt.
ABER: Hier steuert endlich Shopware nach laut Roadmap: https://www.shopware.com/en/roadmap/
„Validate shipping addresses for missing house numbers to prevent failed deliveries“