CustomCatalog nicht lauffähig unter PHP 8.1 & Contao 4.13.12 ?

[PROSIS_Marketing]

Hallo Zusammen,

nach dem Kauf von CustomCatalog müssen wir leider feststellen, dass unter PHP 8.1 die verschiedensten Fehler anspringen (z.B. beim Cache leeren) und auch die Integration von internen Tabellen (in diesem Fall die tl_member Tabelle) nicht funktioniert (angelegte Member werden ins nichts gespeichert und sind dann auch weg. Ebenfalls wollte Contao beim Datenbank Update immer die DB-Änderungen die mit CustomCatalogs bereits vollzogen wurden (also z.B. ADD table 'cc_member') doppelt ausführen (siehe Anhänge).

Fehler sind z.B. diese Meldungen:

Prod Cache leeren:

PHP Warning: Undefined array key "CUSTOMCATALOG_HOOKS" in /var/www/prelive.info-arbeitsschutz.de/system/modules/pct_customelements_plugin_customcatalog/PCT/CustomElements/Filters/Hook/dca/tl_pct_customelement_filter.php on line 45
PHP Warning: Trying to access array offset on value of type null in /var/www/prelive.info-arbeitsschutz.de/system/modules/pct_customelements_plugin_customcatalog/PCT/CustomElements/Filters/Hook/dca/tl_pct_customelement_filter.php on line 45


Dev Cache leeren:
In tl_pct_customelement_filter.php line 45:

Warning: Undefined array key "CUSTOMCATALOG_HOOKS"

Ist CustomCatalog für diese PHP Version geeignet? Und wenn ja, wie sind die diversen Fehler zu erklären bzw. muss man separat noch etwas beachten?

Wir haben den Installationsprozess jetzt unter PHP 8.1 dreimal vollzogen und das Ganze nie fehlerfrei zum laufen gebracht.
Das Aufsetzen mit einer früheren PHP 7.4 Backup-Variante (Umzug war zum Glück erst neulich) lief mit gleichem Vorgehen fehlerfrei ab und lässt auch die Integration interner Tabellen zu.

[Tim]

PHP 8.1 verhält sich etwas strikter und sicher gibt es die eine oder andere Stelle, die noch angepasst werden müssen. Wir nutzen PHP 8.0 bis 8.1 quasi in allen Installationen. Ich in meiner Entwicklungsumgebung ausschließlich 8.1
---
PHP Warnings sind nicht gleichzusetzen mit PHP Fehlern. Die Prozesse werden weiter ausgeführt. Der Server sollte mit display_error 0 (Contao Standard) betrieben werden. Alternativ auf PHP8.0 wechseln.

Es sollte weiterhin das Install-Tool oder der interne Datenbank-Updater genutzt werden, um die Datenbank zu aktualisieren.

[PROSIS_Marketing]

Also zum Verständnis - nach anlegen oder aktualisieren von Feldern soll nicht auf den Button, der auch hier beschrieben wurde: https://cc.premium-contao-themes.com...urationen.html geklickt werden, sondern immer der Contao Manager verwendet werden?

Bisher will das DB-Update im Contao-Manager nämlich immer alle Änderungen Rückgängig machen und die neu erstellten felder droppen. Aber wofür ist der Shortcut über das Popup dann da?

Edit: Grade nochmal ein Feld angelegt. Das Popup zur DB-Aktualisierung kommt -> ohne dortiges Ausführen, zeigt das DB-Update im Contao Manager aber KEINE auszuführenden Änderungen an. Danach die Aktualisierung doch über das Popup gemacht und im DB-Update Contao Manager erscheint ein weiteres "Drop".

Noch als Hinweis: Das ist jetzt nur getestet mit Verwendung der existierenden Tablelle "tl_members"

Edit 2: Gleiches vorgehen mit Erstellung einer neuen Tabelle zeigt dieses Verhalten nicht. Die Erstellung der neuen Tabelle wird zwar auch nur über das Popup angezeigt, allerdings will Contao nachträglich nichts wieder löschen über DB-Update per Contao-Manager.

[PROSIS_Marketing]

Wir haben jetzt die Sachen auf 7.4 aufgesetzt und danach auf PHP 8.1 umgestellt - zumindest scheint jetzt die Integration in Contao interne Tabellen zu funktionieren, allerdings informiert CC nicht mehr über notwendige DB Änderungen und vorher angelegte Tabellenspalten (mit funktionierter Abfrage) werden in der SQL Abfrage auf einmal nicht mehr gefunden:


Das mit den Warnungen kann ich nicht nachvollziehen - wie soll ich eigene Sachen Debuggen, wenn der Debug Modus mit Warnungen von CC vollgeladen wird? (Das ist ebenfalls noch der Fall, wenn in php auf display_errors = Off gestellt wurde.)

Ich hatte vorher mal kurz angefangen zu schauen, wo die Sachen herkommen und es ggf. selbst zu fixen:

Warning: Undefined array key "configs" in: system/modules/pct_customelements_plugin_customcatalog/PCT/CustomElements/Plugins/CustomCatalog/Core/CustomCatalogFactory.php:328 - lässt sich mit einem einfachen

isset($GLOBALS['PCT_CUSTOMCATALOG']['configs']) 

klären.

Dann zum nächsten:
Warning: Attempt to read property "newSection" on null in:
system/modules/pct_customelements_plugin_customcatalog/PCT/CustomElements/Plugins/CustomCatalog/Backend/TableCustomCatalog.php:61

Hier ist es schon nicht mehr einfach, weil

$objActiveRecord 

sehr oft in der Klasse verwendet und nie auf null geprüft wird...

Wie setzt du PHP 8.1 zum Entwickeln ein, wenn alles mit Warnungen vollgeladen wird und man wichtige Fehler so gar nicht abfangen und analysieren kann?
PHP 8.0 hat noch einen Monat Active Support und 1 Jahr Security Fixes - nach unseren Unternehmensrichtlinien ist ein Update auf 8.1 also quasi vorgeschrieben.

[Tim]

Ich debugge online auf gleichem Weg, wie Du. Ich nutze dann auch primär den Symphony Profiler. Dort kann das Logging auf Warnings ausgeblendet werden, damit man sich erstmal auf direkt Exeptions konzentrieren kann. Das Problem mit vorherigen Warnungen kenne ich selbst. Contao ist auch nicht vollends davon befreit oder Symphony. Dauernd fehlende Keys in Twig Template...
Das Update der Erweiterungen ist ein stetiger Prozess. Grundsätzlich ist die Verwendung für den produktiven Modus ausgelegt. Ich bin dankbar für jeden Hinweis und schließe offene Enden, in die ich selbst noch nicht gelaufen bin.

Falls unter PHP8.1 bestimmte Features nicht funktionieren, prüfe ich es und gebe auch gern Zugang zu einer Entwicklungs-Installation frei, wo das Problem nachgestellt werden kann. Gerade in CC gibt es viele Wege.
Im Fall einer Inkompatibilität sollte auf die Verwendung von PHP8.1 (oder andere) verzichtet werden, bis ein entsprechendes Update erschienen ist. Die Hauptkompatibilität gilt gegenüber Contao, nicht explizit gegenüber der PHP Version.

[PROSIS_Marketing]

Hilft es dir dann etwas, die ganzen Fehlermeldungen zu Dokumentieren und wenn ja wo?

[Tim]

Unter PHP8.1 arbeitet die php-eigene array_diff_assoc und array_intersect_assoc Funktion nicht mehr wie vorher unter PHP8.0. Das führt zu einem php Fehler, der den DCA array von zuerweiternden Tabellen nicht mehr korrekt in den bestehenden Array merged. -> die Felder werden beim Datenbank update nicht mehr berücksichtigt und werden ggf. zum DROP angeboten. (nicht durchführen).

Ich habe ein Issue erstellt.

[Brubbel]

Evtl. spielt das hier im gleichen Kapitel. Wir haben eine C4.9 (PHP 7.4, EX3) Site gestern auf die aktuelle Version angehoben (C4.13.12, PHP 8.1.10, EX4.1.3).
Dabei gab und gibt es das Problem, das von unseren 9 CCs auf der Seite, nur 4 problemlos migriert wurden. Für 5 CC gibt es das Problem bei der Datenbankaktualisierung, dass Contao immer diese Tabellen neu anlegen möchte. Ich ignoriere diesen Wunsch und inhaltlich ist alles in Ordnung. Die Site funktioniert im Frontend wie sie soll. Aber im Backend haben wir natürlich nun die Anzeige oben mit Hinweis auf Datenbankänderung und Installer, bzw. Contao-Manager, wollen halt diese 5 Tabellen neu anlegen.

Ich habe sie in einer Staging Umgebung schon mal gelöscht und anlegen lassen. Werden auch angelegt aber die Meldung bleibt danach trotzdem.

Auffällig ist, dass genau diese 5 Tabellen anders heißen, als die 4 problemlosen. Bei den problemlosen ist der Aufbau der Tabellennamen:

tbl_cc_xyz

Bei denen, die nun das Problem machen, ist der Aufbau:

tl_cc_xyz

, entspricht also im Prefix den "normalen" Contao Tabellen.

[Tim]

Wenn du tl_ Prefixe nutzt, wird Contao allein die Tabellen managen.

[Brubbel]

Hm, ja, ich weiß auch nicht wieso ich diese 5 entgegen meiner normalen Nomenklatur nicht mit tbl_ habe beginnen lassen . Anyhow ... wie löse ich das jetzt am schlausten? Also eher die Tabellen nachträglich umbenennen, bevor wir da lange auf einen Fix von Contao warten?

[Tim]

Hm, ja, ich weiß auch nicht wieso ich diese 5 entgegen meiner normalen Nomenklatur nicht mit tbl_ habe beginnen lassen . Anyhow ... wie löse ich das jetzt am schlausten? Also eher die Tabellen nachträglich umbenennen, bevor wir da lange auf einen Fix von Contao warten?

Contao wird da nichts fixen, weil es grundsätzlich nichts zu fixen gibt. Contao verhält sich korrekt. tl_ ist schon immer Contaos-hauseigener Tabellenprefix.

Du kannst versuchen in phpmyadmin die Tabellennamen zu ändern und auch in der CC Konfiguration.

[Brubbel]

Aber müsste CC dann (jetzt?) nicht verhindern, dass CC-Tabellen den Prefix tl_ bekommen?

Ich hatte das auf jeden Fall so gelöst, dass ich die Tabellennamen, so wie Du auch schon vorgeschlagen hast, auf tbl_ geändert habe UND das auch in der tl_pct_customcatalog_language nachgezogen habe. Das war ein mehrsprachiger Katalog.

Danach war alles wieder Bingo Bongo. Danke Dir.

[Tim]

Naja, ich sehe am Häuftigsten den Prefix: "cc_", so wie ich bzw. pct ihn auch überall setzt. Das jemand "tl_" genutzt hat, kam in all den Jahren genau 1x vor. Heute

[Brubbel]

Haha, ich hab die nich absichtlich so genannt, muss vertippt sein ... Ich bin ja schon ein alter Sack und "früher" haben wir Datenbankobjekte immer mit einem Präfix nach dem Typ benannt .. Tabellen eben mit tbl_ ;-)

[Brubbel]

Ich habe ein schwerwiegenderes Problem im Zusammenhang mit einer Kindtabelle (für Varianten) gefunden. Es geht um die aktualisierte Contao-Installation von oben. Die Tabellen haben also vorher schon existiert und der Fehler tritt jetzt nach dem Update beim Zugriff im Backend auf die Editierfunktion der Kindtabelle auf. Im Frontend werden die Informationen aus des Kindtabelle normal angezeigt.

Fehlerbeschreibung: Wenn im Backend der Inhalt eines CCs aufgelistet ist und man über das Stift-Symbol die Kindtabelle editieren möchte, kommt ein "Internal Server Error" mit dem Hinweis auf "The arguments array must contain 1 items, 0 given".

Im Debugger wird diese ErrorException angezeigt:



StackTrace:

ErrorException: Warning: Undefined property: PCT\CustomElements\Plugins\CustomCatalog\Core\Cust omCatalog::$table at system/modules/pct_customelements_plugin_customcatalog/PCT/CustomElements/Plugins/CustomCatalog/Core/Maintenance.php:893 at PCT\CustomElements\Plugins\CustomCatalog\Core\Main tenance:urgeFileCache() (system/modules/pct_customelements_plugin_customcatalog/PCT/CustomElements/Plugins/CustomCatalog/Core/SystemIntegration.php:297) at PCT\CustomElements\Plugins\CustomCatalog\Core\Syst emIntegration->initSystem() (vendor/contao/core-bundle/src/Framework/ContaoFramework.php:405) at Contao\CoreBundle\Framework\ContaoFramework->triggerInitializeSystemHook() (vendor/contao/core-bundle/src/Framework/ContaoFramework.php:307) at Contao\CoreBundle\Framework\ContaoFramework->initializeFramework() (vendor/contao/core-bundle/src/Framework/ContaoFramework.php:122) at Contao\CoreBundle\Framework\ContaoFramework->initialize() (vendor/contao/core-bundle/src/Security/User/ContaoUserProvider.php:68) at Contao\CoreBundle\Security\User\ContaoUserProvider->loadUserByIdentifier() (vendor/contao/core-bundle/src/Security/User/ContaoUserProvider.php:87) at Contao\CoreBundle\Security\User\ContaoUserProvider->refreshUser() (vendor/symfony/security-http/Firewall/ContextListener.php:236) at Symfony\Component\Security\Http\Firewall\ContextLi stener->refreshUser() (vendor/symfony/security-http/Firewall/ContextListener.php:137) at Symfony\Component\Security\Http\Firewall\ContextLi stener->authenticate() (vendor/symfony/security-bundle/Debug/WrappedLazyListener.php:49) at Symfony\Bundle\SecurityBundle\Debug\WrappedLazyLis tener->authenticate() (vendor/symfony/security-http/Firewall/AbstractListener.php:26) at Symfony\Component\Security\Http\Firewall\AbstractL istener->__invoke() (vendor/symfony/security-bundle/Debug/TraceableFirewallListener.php:73) at Symfony\Bundle\SecurityBundle\Debug\TraceableFirew allListener->callListeners() (vendor/symfony/security-http/Firewall.php:92) at Symfony\Component\Security\Http\Firewall->onKernelRequest() (vendor/symfony/event-dispatcher/Debug/WrappedListener.php:117) at Symfony\Component\EventDispatcher\Debug\WrappedLis tener->__invoke() (vendor/symfony/event-dispatcher/EventDispatcher.php:230) at Symfony\Component\EventDispatcher\EventDispatcher->callListeners() (vendor/symfony/event-dispatcher/EventDispatcher.php:59) at Symfony\Component\EventDispatcher\EventDispatcher->dispatch() (vendor/symfony/event-dispatcher/Debug/TraceableEventDispatcher.php:154) at Symfony\Component\EventDispatcher\Debug\TraceableE ventDispatcher->dispatch() (vendor/symfony/http-kernel/HttpKernel.php:139) at Symfony\Component\HttpKernel\HttpKernel->handleRaw() (vendor/symfony/http-kernel/HttpKernel.php:75) at Symfony\Component\HttpKernel\HttpKernel->handle() (vendor/symfony/http-kernel/Kernel.php:202) at Symfony\Component\HttpKernel\Kernel->handle() (web/index.php:44)

VG

[Tim]

Wo genau tritt der Fehler auf, nicht die erste Warning?

Ich kann auf die Schnelle keine Probleme mit Eltern-Kind-Konstrukten feststellen.

[Brubbel]

Um diese Meldung zu bekommen, gehe ich ins Backend, und wähle links meinen entsprechenden CC-Katalog aus. Die einzelnen Datensätze werden aufgelistet. Jetzt schalte ich oben den Debug-Modus an und die obige Meldung erscheint.

Ergänzung: Diese Meldung erscheint auch, wenn ich vorher einen anderen CC-Katalog ausgewählt habe, der keine Kindtabellen enthält.