Call to undefined method named __set_state

[Andreas13]

Hallo Forum,
ich habe ein Update auf die Version 5.0.8 CC/CE durchgeführt, um ein anderes Problem zu lösen, dabei haben wir jetzt aber ein neues Phänomen.
Nach einer gewissen Zeit kann man sich nicht mehr im Contao-Backend anmelden. Ich habe noch nicht herausgefunden, wann genau das passiert, aber die Fehlermeldung, die dann erscheint lautet:

[2024-07-05T10:21:46.942547+00:00] php.CRITICAL: Uncaught Error: Call to undefined method Closure::__set_state() {"exception":"[object] (Error(code: 0): Call to undefined method Closure::__set_state() at /.../system/modules/pct_customcatalog_cc_cases/dca/cc_cases.php:560)"} []
[2024-07-05T10:21:46.945504+00:00] request.CRITICAL: Uncaught PHP Exception Symfony\Component\ErrorHandler\Error\UndefinedMeth odError: "Attempted to call an undefined method named "__set_state" of class "Closure"." at /.../system/modules/pct_customcatalog_cc_cases/dca/cc_cases.php line 560 {"exception":"[object] (Symfony\\Component\\ErrorHandler\\Error\\Undefine dMethodError(code: 0): Attempted to call an undefined method named \"__set_state\" of class \"Closure\". at /.../system/modules/pct_customcatalog_cc_cases/dca/cc_cases.php:560)"} []

Nachdem ich dann die jeweiligen dca-Dateien gelöscht habe, geht die Anmeldung wieder und alle Dateien werden neue erzeugt.
Ich stehe da gerade etwas auf dem Schlauch.
Kann damit jemand etwas anfangen?

Contao 4.13.44
PHP 8.2

Gruß Andreas

[Tim]

Hi Andreas,
die Methode kenne ich nicht und wird meines Erachtens auch nirgends von CC selbst gesetzt, jedenfalls tat sie das bislang auch nicht oder es ist noch nie vorgekommen. Erweiterst du den DCA durch eigene Methoden?

Schick hier einmal bitte das gesamte obengenannte DCA File aus deinem CC Cases Katalog. bzw. die Zeile 560 der Datei.

[Andreas13]

Hi Tim,

die Datei hat nur 540 Zeilen, bzw. diese neu angelegte Datei. Die andere, auf die sich die Fehlermeldung bezog, habe ich leider einfach nur gelöscht.
Ich habe noch ein Backup, das aber auch älter ist als der letzte Vorfall. Diese Datei hat tatsächlich 623 Zeilen. Wir warten jetzt also auf den nächsten Vorfall und dann poste ich die in der Fehlermeldung erwähnte Zeile, oder den Abschnitt.

Gruß Andreas

[Andreas13]

Hi Tim,
der Fehler ist jetzt wieder aufgetreten. Der besagte Bereich befindet sich am Ende der Datei:

 'createdByCustomCatalog' => true,
'isPrivateCustomCatalogDCA' => true,
'select' =>
array (
'buttons_callback' =>
array (
'xlft' =>
\Closure::__set_state(array(
)),
),
), 

Kannst du damit etwas anfangen?

Gruß Andreas

[Tim]

Hab ich noch nie gehört.

Auch ein seltsamer callback "xlft". Das sagt mir auf Anhieb auch nichts. Ich würde sagen da hängt sich eine Erweiterung hinten an.

Die Flagge "isPrivateCustomCatalogDCA" setzt CC ein, wenn es zu einer mit CC erstellten Tabellen-Konfiguration bereits vorab eine DCA-Konfiguration gibt. Damit handelt es sich nicht mehr um den Standard-Aufbau.
Also CC muss hier irgendwas erweitern. Es ist kein von CC selbst erstellter DCA mehr. Der bestehende DCA Array wird mit dem mandatory/Pflichtgrundgerüst- DCA-Array von CC zusammen gelegt.

Hier kommt jetzt von irgendwo eine Definition für einen Operations-Button rein, würde ich sagen. buttons_callback dient in Contao als Definition einer Callback-Funktion zur Erstellung eines Operations-Button -> das sind die Buttons wie Löschen, Kopieren, Verschieben usw.

[Andreas13]

Nachdem ich die Datei(en) gelöscht habe, werden sie neu angelegt.
Die cc_cases.php hat dann nur noch 555 Zeilen und die letzten Zeilen sehen so aus:

 'BE_ATTRIBUTES' =>
array (
0 => 2,
1 => 11,
2 => 3,
3 => 6,
4 => 7,
5 => 5,
6 => 8,
7 => 9,
8 => 15,
9 => 13,
10 => 14,
11 => 149,
12 => 10,
13 => 1,
),
'createdByCustomCatalog' => true,
'isPrivateCustomCatalogDCA' => true,
); 

Der 'select' Part ist dann noch nicht vorhanden. Ich weiß aktuell nicht welche Erweiterung das im Verlauf von einiger Zeit tun sollte. Zumal es ja alle dca-Dateien von CC-Katalogen betrifft. Das sind aktuell 5 Stück.
Dieses Verhalten tritt auch erst nach dem CC/CE Update auf. Wir haben von einer CC-4.4.x / CE-4.5.x auf die CE/CC 5.0.8 aktualisiert.

[Tim]

Dieser DCA Array sieht korrekt abgeschlossen aus. - weiterhin als isPrivate... geflaggt. (siehe oben)

Dieses Verhalten tritt auch erst nach dem CC/CE Update auf. Wir haben von einer CC-4.4.x / CE-4.5.x auf die CE/CC 5.0.8 aktualisiert.

Unter Contao 5 wird eine vollständig generierte DCA Datei benötigt, damit Contao bzw. das Symphony Caching diese vollständig berücksichtigen kann, auch im Manager.

Nichts desto trotz ändert anscheinend eine Erweiterung den vorherigen DCA in einer Form, dass es zu den oben genannten Problemen kommt. Wann dieser Zeitpunkt ist, hängt wohl durch irgendeine Aktion zusammen, sonst wäre der Aufruf direkt im Array und nicht erst zeitversetzt.
---
Der DCA Array kann natürlich manipuliert werden - sowohl Contaos eigene DCA Callbacks greifen - als auch konkret Hooks aus dem System heraus.

Auch schaut CC sogar noch nach einer /system/config/dcaconfig.php Datei und schiebt diese an.

[Andreas13]

Ich habe jetzt mal nach xlft gesucht und die Erweiterung Contao2Xliff gefunden, die wir mal zum Testen eingebunden hatten. Diese Erweiterung ist dafür zuständig, dass das DCA erweitert wird. Es scheint ja bei den meisten Standard-DCA's auch gut und problemlos zu funktionieren, nur eben bei den dynamisch angelegten CC-DCA's nicht.
Da wir diese Erweiterung nicht mehr brauchen, habe ich sie einfach entfernt und seitdem scheint Ruhe zu sein.

Evtl. müsstet Ihr Euch mal darüber austauschen und klären, wo die Schwierigkeiten genau herkommen und wie man sie vermeiden könnte.

Abgesehen davon, vielen Dank für Deine Unterstützung.
Gruß Andreas

[Tim]

Diese Erweiterung ist dafür zuständig, dass das DCA erweitert wird.

Das ist eine Ãœbersetzungs-Erweiterung, die ggf. DCAs erweitert (offensichtlich nicht direkt mit dynamischen DCAs von CC kompatibel).

CC stellt den "prepareDataContainer"-Hook zur Verfügung, um den DCA-Array entsprechend zu bereinigen oder kompatibel zu erweitern, bevor dieser geschrieben wird.