unter PHP 8 wurde die Array key undefined Meldung ja von einer Notice zu einer Warning hochgestuft. Das macht nun gravierende Probleme im Zusammenhang mit Smarty. Ich hab teilweise nicht mit “isset” gearbeitet, sondern diretkt z.B. mit if $meinevariable geprüft, ob Inhalt gesetzt ist oder nicht. Okay, nachlässig von mir. Das wird in Smarty kompiliert zu if ($this->_tpl_vars['meinevariable]). Wurde die Template-Variable nicht in einem Controller gesetzt, führt das zur Array key undefined Warnung.
Aber: Es betrifft auch OXID-Standard; bspw. sind auch Standard-Smarty-Funktionen wie capture betroffen. capture wird kompiliert zu $this->_smarty_vars[‘capture’][‘meincapturename’]. Beispiel aus dem Standard: loginErrors. Gab es keine Login-Errors, ist smarty.capture.loginErrors leer, und es wird wieder die Array key undefined Warnung geworfen.
Wie geht ihr damit in eurem Projekt um? Das sorgt bei uns gerade dafür, dass das Fehlerlog täglich auf mehrere hundert MB anwächst. Es handelt sich um ein großes Enterprise-Projekt, das Theme jetzt auf Twig umzustellen bspw. würde Wochen dauern, bzw. generell auch das manuelle korrigieren aller Vorkommen in den OXID-Standardteilen.
Dort hilft bei produktive Projekte nur das Error-Logging für Warnings auszuschalten.
Die Warnings werden Dir auch unter Twig angezeigt.
Dies wird der langfristigste Weg sein, die ganzen Vorkommen im OXID eShop Framework zu beseitigen. Dort könntest Verbesserungsvorschläge über Pull-Request einreichen, dies würde auch Community Edition betreffen.
vielen Dank für die ausführliche Antwort. Auch wenn es nicht ganz das ist, was ich mir erhofft habe
Glaub, das wird unserem Kunden nicht gefallen. Wir haben das Angebot zum Update unter der Annahme gemacht, dass OXID in der neuesten Version (wie angegeben) kompatibel mit PHP 8 ist. Gewissermaßen wird man zum Update der PHP-Version gezwungen, einerseits von PHP selbst durch die kurzen Lifetimes und dadurch wiederum durch die eingesetzte Software (Wegfall des 7.3er Supports von OXID). Dass es jetzt gar nicht PHP 8 kompatibel ist, ist natürlich ärgerlich. Der Kunde zahlt schon extrem viel Geld für Lizenzen und darf jetzt nochmal dafür blechen, die Software kompatibel zu machen.
Aufgrund von Monitoring-Prozessen können wir die Warnings auch nicht einfach abschalten.
Gibt es dazu von OXID selbst irgendwo eine Stellungnahme oder eine Empfehlung?
auf einer produktiv Umgebung schaltet man die Fehlermeldungen ab dies normaler Vorgang. Das Fehlerlogging könnt Ihr beeinflussen, indem Ihr Warnings nicht mitloggt.
Dies trifft auch zu, dass OXID mit PHP 8 kompatibel ist. Aber wenn dem Kunde wichtig ist, dass keine Warnings auftauchen, dann prüft man dies vorab als IT-Dienstleister ob man die Zusage auch einhalten kann.
Willkommen im 21. Jahrhundert, dies ist der “normale” Life-Cycle. Das Problem ist hier nicht die Software sondern die fehlende Einpreisung in der Kalkulation/Planung.
Nein, Produktverbesserungen und Feature-Wünsche kannst per E-Mail an [email protected] kommunizieren.
OXID eSales arbeitet an der ständigen Verbesserung seines OXID Frameworks. Daher gehe ich davon aus, dass in zukünftigen Versionen die Warnings behoben sein werden.
Wenn ich Dich richtig verstanden habe, dann könntest noch auf PHP Version 7.4 wechseln um Eure Monitoring Prozesse weiter laufen lassen zu können.
sehe ich ein wenig anders. Wir schalten das Fehlerlogging im Produktivmodus nie ab; das bleibt in hoch individualisierten Projekten nicht aus, dass da im Livebetrieb Dinge im Log auftauchen, die in Testphasen oder lokalen Umgebungen nicht auftreten.
Okay, das heißt ich plane demnächst in meine Schätzungen 20 Personentage Puffer ein, weil ich nicht weiß, ob OXID seine Releases vorab testet nein, Spaß beiseite, natürlich beachten wir solche Dinge auch bei unseren Aufwandsschätzungen und kalkulieren Eventualitäten mit ein. Aber eigentlich eher für unsere eigenen Anpassungen und nicht, dass die Standardsoftware das Log so schnell füllt. Man kann den kompletten Code nicht vor Angebotsabgabe testen; das wäre Wochenlange Arbeit und wenn man damit fertig wäre, wären 90% der Arbeit schon erledigt. Deswegen müssen wir mit Annahmen arbeiten; zum Beispiel, dass das PHP-Fehlerlog nicht MB-weise mit jedem Request ansteigt das sind ja keine Sonderfälle; das ist einfach schon beim Aufruf der Startseite eines Mandanten. Der Kunde zahlt heftige Preise für mehrere B2B-Lizenzen und die Lösung von OXID ist “schaltet euer Logging aus” oder “ja macht’s halt selbst”.
Den Zwischenschritt über PHP 7.4 würde auch unnötig Mehrkosten verursachen.
Ich werd’s dem Kunden jetzt so mitteilen und die Kompatibilisierung selbst vornehmen. Bei anderen Projekten weiß ich dann, was ich den Kunden zu empfehlen habe.
Dazu kann ich nichts schreiben, dafür kenne ich die Verträge und Hintergründe nicht. Würde aus OXID eSales Sicht argumentieren, dass wenn man die Warnings nicht haben möchte man noch PHP Version 7.4 nutzen kann in der Übergangsphase Server und Systemvoraussetzungen — OXID eShop 6.4 | Anwenderdokumentation
Daher wäre aus meiner Sicht das Kernproblem im Einzelfall, dass Euer Kunde über den Hoster oder andere Gründe auf PHP Version 8.0 angewiesen ist. Dies ist aber auch abdeckt, nur halt das noch die Warnings auftauchen, was ja keine Fehler sind.
Wenn man diese Beschreibung in Deinem Einzelfall noch einbezieht würde ich auch prüfen ob das verwendete Theme noch aktuell, weil neuere Theme Versionen diese Art von Warning ggfs. bereits abfangen könnten. In der Regel handelt es sich noch um ein Child bzw. Custom Theme, dann liegt es komplett in der Verantwortung des Dienstleister bzw. Händlers.
danke für die Ergänzung. Beim Theme handelt es sich um Custom Themes, die vom OXID-Standard erben. Die Fehler sind definitiv auch noch in den Standard-Teilen enthalten.
Ich hab mir gerade einmal die Mühe gemacht, eine “blanko” 6.4.1 Installation anzulegen, um das Ausmaß ein wenig zu verdeutlich und zu schauen, wie viel “auf unseren Mist” gewachsen ist und wie viel des Problems der OXID-Standard bereits verursacht. Eingesetzt wird OXID 6.4.1 mit Demodaten unter PHP 8.
Im Folgenden handelt es sich jeweils um einen einzigen Request, anschließend habe ich das Error Log wieder gelöscht.
Aufruf Frontend, Kategorieseite mit Artikeln (Kiteboarding > Kites): 9,8 MB
Aufruf Frontend, Artikeldetailseite: 45,5 MB (!!)
Die Ladezeiten der einzelnen Seiten sind entsprechend lang, weil die Schreiboperationen ins Log so intensiv sind. Arbeiten im Admin fast nicht möglich, weil die Verzögerung der Frames und des Menüs extrem ist.
Habe mittlerweile auch gemerkt, dass nicht nur das Theme problematisch ist, sondern tatsächlich auch Core-Klassen, die sich teilweise auch nicht durch Plugins überschreiben lassen, weil es bspw. private Methoden sind. Hier kommt man also um Patches nicht drumherum.
Nur als “Warnung” oder Hinweis an potentiell Update-willige. Keine weitere Rückmeldung nötig.
Ich muss übrigens ein wenig demütig zurückrudern: Es gibt einen entsprechenden Hinweis auf der Systemvoraussetzungsseite. Ich habe dem Support geschrieben, dass der Hinweis ggf. direkt nach der Erwähnung von PHP 8.0 mit einem Asterisk versehen wird.
Auch wenn dir der Support bereits geantwortet hat, hier für alle anderen noch die Information:
Unsere Entwicklung arbeitet bereits an dem Thema. Da jedoch Lösungen in OXID eShop 6.x zu BC Breaks führen, wird dies voraussichtlich erst in OXID eShop 7.0 behoben.
Zusätzlich wurde das hier beschriebene Verhalten von uns auf einem Referenzsystem (OXID eShop EE 6.4.1, installiert mit Demodaten und PHP 8) geprüft. Dabei erhalten wir nach Aufruf der Artikeldetailseite ein error.log von ca. 56 kB. Die genannten Ladezeiten konnten nicht reproduziert werden und wurden von anderen Kunden nicht zurückgemeldet.
nein, Spaß beiseite, natürlich beachten wir solche Dinge auch bei unseren Aufwandsschätzungen und kalkulieren Eventualitäten mit ein. Aber eigentlich eher für unsere eigenen Anpassungen und nicht, dass die Standardsoftware das Log so schnell füllt. Man kann den kompletten Code nicht vor Angebotsabgabe testen; das wäre Wochenlange Arbeit und wenn man damit fertig wäre, wären 90% der Arbeit schon erledigt. Deswegen müssen wir mit Annahmen arbeiten; zum Beispiel, dass das PHP-Fehlerlog nicht MB-weise mit jedem Request ansteigt 
das sind ja keine Sonderfälle; das ist einfach schon beim Aufruf der Startseite eines Mandanten. Der Kunde zahlt heftige Preise für mehrere B2B-Lizenzen und die Lösung von OXID ist “schaltet euer Logging aus” oder “ja macht’s halt selbst”.