Frontedit: Reader bleibt bei Kindtabelle leer

[wortberge]

Hej,

ich habe in meinem CC das FE in der 1.5 dev implementiert.
Es sind 3 Tabellen miteinander verknüpft:

- Unternehmen als Parent
-- Kontakte als Child
-- Messestände als Child

Bis auf ein paar Kleinigkeiten (siehe https://forum.premium-contao-themes....4225#post24225 ) funktioniert die Liste/ Reader Konstellation bei den Unternehmen.

Nun habe ich in meinem Seitenbaum eine Seite für die Kontakte angelegt. Diese werden mit dem Listenmodul sauber ausgegeben. Alle Buttons sind ebenfalls vorhanden. Einen Listeneintrag zu löschen funktioniert. Das Modul leitet bei allen anderen Aktionen, wie konfiguriert, auf die Readerseite (/edit) weiter. SwitchToEdit ist im Listenmodul aktiv, im Reader nicht.

Hier die Probleme:

• Link "Weiterlesen" führt zu messekontakte/edit/2 -> 404er
• "Neues Element" fuhrt zu messekontakte/edit?do=cc_i_contacts&table=cc_i_contacts&jumpto=2 927&switchToEdit=1&act=paste&mode=create&rt=CsbInu vQ6SDZTlln7w9IHDdYvUBbl9WmVEdB91FdZyk -> leere Seite, Modultemplates werden nicht geladen
• "Bearbeiten"-Button führt zu messekontakte/edit?act=edit&do=cc_i_contacts&table=cc_i_contacts &id=2&pid=11&items=2&rt=CsbInuvQ6SDZTlln7w9IHDdYvU Bbl9WmVEdB91FdZyk -> 404er
• Klick auf "Veröffentlichen" zeigt in der Developer-Console -> /unternehmensbereich/messekontakte?tid=2&state=0&table=cc_i_contacts -> 400 Bad Request

@Tim: mir ist klar, dass ich Dich zum Thema Frontedit diese Tage schon sehr beansprucht habe, hoffe aber dennoch sehr auf weitere Unterstützung.

Ich müsste dann noch die ID des Unternehmens (pid) in einem Readonly oder Hidden-Field übergeben. Klappt das irgendwei?


Vielen Dank vorab!

[Tim]

Hi,

Ich müsste dann noch die ID des Unternehmens (pid) in einem Readonly oder Hidden-Field übergeben. Klappt das irgendwei?

Die ID des Eltern-Eintrags ist die PID des Kind-Eintrags. Die wird in den Datensatz des aktiven Kind-Eintrags normal ausgeliefert.

Allein die Grundkonfiguration dieses Aufbaus übersteigt den Rahmen des Supports, den wir hier leisten können - unabhängig des zusätzlichen Editings.

[wortberge]

Hi,


Die ID des Eltern-Eintrags ist die PID des Kind-Eintrags. Die wird in den Datensatz des aktiven Kind-Eintrags normal ausgeliefert.

Allein die Grundkonfiguration dieses Aufbaus übersteigt den Rahmen des Supports, den wir hier leisten können - unabhängig des zusätzlichen Editings.

Hi Tim,

sorry, aber Deine Antwort verstehe ich nicht!

Wenn ich mir die Produktbeschreibungen des Custom Catalogs ansehe, finde ich Eltern-Kind Beziehungen von Tabellen.
Wenn ich mir die Beschreibung und die Forenbeiträge zum Frontend-Editing ansehe, finde ich die Unterstützung Eltern-Kind-Tabellen.

Die Version im Master-Branch des Frontedit ist unter den letzten Contao und CC-Versionen im LTS-Zweig offenbar nicht mit allen Attributen lauffähig und man wird von Euch auf die DEV verwiesen, die vollkommen nachvollziehbar nicht Fehlerfrei sein kann. Kein Vorwurf.

Die Readonly-Variante meines Aufbaus funktioniert ohne Probleme. Ich hole mir hier, wie in der Vergangenheit von Dir angeraten die einzelnen Daten der Kindtabellen im Reader-Template des Parents mit einzelnen SQL-Queries rein, weil ich keine weiteren Listen brauche. Alles kein Stress.

Das einzig in meinen Augen "Besondere" ist, dass ich für eine bessere UX beim Editing nicht vom Listenmodul des Parents starte.

Ich arbeite als Freelancer für Agenturen, die das Eclipse Theme und den CC doch relativ regelmäßig beziehen. Meine Kalkulationen und Einschätzungen gegenüber unseren gemeinsamen Kunden muss ich auf die Funktionsbeschreibungen und Dokumentationen von Zulieferen, also in diesem Fall Eurer Website, stützen. Eine vorergehende Evaluierung im vollen Umfang ist aud Kostengründen schlicht unmöglich, aber genau deshalb setzt man auf kommerzielle Produkte und nicht die frei verfügbaren Pendants. Wenn sich heute eine Applikation für mich unerwartet verhält und ich improvisieren oder mit dem Support kommunizieren muss, ist das auch für mich sehr unangenehm. Es bedeutet nämlich, dass ich Geld verbrenne. Entschuldige also bitte meine Wortwahl.

Nachdem die Doku zum Frontedit recht dürftig ist und auch zum CC im Hinblick auf Eltern-Kind Beziehungen, eine abschließende Frage:

Wie muss der Aufbau Deiner Meinung nach aussehen, damit mein Vorhaben - im von PCT kommunizierten Umfang - funktioniert?
Bearbeiten von Kinddatensätzen mit allen Attributen...

Danke für Deine Mühe!

[Tim]

Die Readonly-Variante meines Aufbaus

Wie sollen wir solche eigenen Konstrukte testen und prüfen? Wir versuchen wirklich alles erdenkliche auch die wildestens Eigenkompositionen noch zu prüfen und mitzuarbeiten. Ich weiss nicht mal was in deinen Augen eine "Readonly" Variante ist. Baut das ganze auf einer unserer Demos auf?

Ich gebe Dir gern einen Zugang zu einer unserer Testumgebungen, wo das Problem eingekreist werden kann.

Eltern-Kind-Aufbauten sind ein Bordmittel von CustomCatalog, korrekt. Laut deiner Aussage, ist dieser Aufbau fertig.
Es ist damit aber nicht automatisch über das additive Editing abdeckbar. Auch die Beispiele zum Editing sind nicht aufgebaut auf Kind-Tabellen-Bearbeitungen.

[wortberge]

Vielen Dank, dass Du Dich der Sache nochmal annimmst. Wenn wir das Händlerverzeichnis ansehen, wird FE so wie ich das sehe auch funktionieren. Wenn wir nun aber den einzelnen Händler gleichrangige Kindtabellen anfügen (z.B. Mitarbeiter, Fahrzeuge Produkte im Lager) wird es problematisch. Ich halte das auch nicht für zu weit hergeholt. Wenn das Listen- und Lesermodul ggf auf den übergebenen Tabellennamen reagieren könnten, müsste das gelöst sein, oder? Vielleicht gültige Tabellen als Multi-Select in den Moduleinstellungen setzen.

[Tim]

So, ich habe jetzt dieses Konstrukt nachgebaut.

Eltern-Kind-Tabellenkonfiguration. Grundaufbau alles mit Bordmitteln, default Templates - wie in Demos oder auch dokumentiert.

• Von Hauptliste zu Kind-Eintrag wird der "Einträge ansehen... " Button gesetzt für die Weiterleitung auf die Kindliste.

• Kind-Liste mit aktiven Edting-> Kind-Einträge haben Bearbeiten-Button zu Detailseite inkl. PID des Haupteintrags.

• Detailseite beinhaltet Leser für Kind-Tabelle mit aktiver Bearbeitung. PID wird über die Url gegeben.

• Titel geändert in Hallo Welt:

• Backend-Bestätigung:

[wortberge]

Danke für Deine Erläuterungen. Auf meinem DEV bekomme ich aktuell bei Nachbau Deines Konstrukts einen Token-Error. Sehr seltsam. Ich teste das lokal nochmals in einer nackten Installation und gebe Dir Feedback.

[wortberge]

Hi Tim ,

wie ich sehe, ist das Problem mit dem Request Token in der DEV gefixt. Super, danke!

Dank Deines Aufbaus konnte ich nun auch das grundlegende Problem verstehen und ich denke, ich kann es lösen. Wenn man die Parent-Child Tables ineinander verschachtelt, ist es wohl kein Problem.

Sobald man gleichrangige Kindtabellen hat, läuft man gegen eine Wand, weil das Listenmodul des Parents eine Weiterleitung benötigt und alle Links zu den Listen der Kindtabellen auf ein und die selbe Zielseite generiert. Spätestens bei einem abweichenden Tabellennamen ist es dann aus.

Nach meinem Verständnis müsste ich doch jetzt "nur" auf der obersten Ebene die Links sei es mit Listenmodulen und eigenständigen Templates oder einer SQL-Query die Links zu den Seiten mit den passenden Listenmodulen selbst "montieren". Ein Link á la /liste-child-modul-1/table/cc_childtabelle-1/pid/alias-parent.html und /liste-child-modul-2/table/cc_childtabelle-2/pid/alias-parent.html sollte es dann sein, oder?

Einen Bug habe ich noch gefunden:
Wenn man einen bestehenden Datensatz editiert, funktioniert das ohne Probleme, soweit ich das in meinen Tests sehen konnte. Wenn man einen bestehenden Eintrag löscht oder kopiert geht beim Reload der Seite die pid verloren und es werden alle Einträge angezeigt (oder keine je Einstellung im Listenmodul).

Wenn man einen neuen Datensatz anlegen möchte, fehlt im Formular das hidden field mit der (siehe Screenshots)



Vielen Dank für Deinen Support!

P.S. konntest Du hier schon einen Blick darauf werfen? Auch in meiner neuen Installation ist das Label des "Abbrechen" Buttons nicht vorhanden.
https://forum.premium-contao-themes....4225#post24225

[Tim]

Wenn man die Parent-Child Tables ineinander verschachtelt, ist es wohl kein Problem.

So ist der Grundaufbau. Andere Konstellationen werden standardmäßig nicht unterstützt. Die Anzahl an Kind-Tabellen ist egal. Hauptsache es ist immer strikt Eltern-Kind ineinander, wie auch im Backend.

Am Ende ist alles ein großes Formular, das in die DB geschrieben wird. Du kannst es mit Input Feldern bespielen, wie du magst. In anderen Threads sind Beispiele dafür bzw. ist es allgemeines HTML-Formular-PHP Aufbau.

[wortberge]

Hallo Tim ,

ich habe die ganze Sache nun soweit am Laufen. Tatsächlich hat sich bei der Konfiguration ein ziemlicher Knoten gebildet, obwohl allen Einstellungen und Einbindungen der jeweiligen Moule gepasst haben. Ich musste in den CC Konfigurationen die Relationen der 3 Tabellen auflösen, die Module neu anlegen und einbinden und dann ging es. Ich habe jetzt noch eine Exception und die kleinen Bugs mit der fehlenden PID und den Pickern. Soll ich Dir das alles gesammelt ins Gitrepo schreiben?

[2022-01-27 12:05:23] request.INFO: Matched route "tl_page.2928". {"route":"tl_page.2928","route_parameters":{"_toke n_check":true,"_controller":"Contao\\FrontendIndex ::renderPage","_scope":"frontend","_locale":"de"," pageModel":"[object] (Contao\\PageModel: {})","parameters":"","_route":"tl_page.2928"},"req uest_uri":"https://.../edit?act=edit&do=cc_stands&id=9&items=9&pid=11&rt= dbGBLVzOGyta67haxeGCU3l5rWSOkM9Ag9KH9pKD-38&table=cc_i_fairstands","method":"GET"} []
[2022-01-27 12:05:23] request.CRITICAL: Uncaught PHP Exception TypeError: "Argument 1 passed to Contao\CoreBundle\Picker\PickerBuilder::addProvide r() must implement interface Contao\CoreBundle\Picker\PickerProviderInterface, null given, called in .../system/modules/pct_customelements_plugin_cc_frontedit/PCT/Contao/Picker/PickerBuilder.php on line 102" at .../vendor/contao/core-bundle/src/Picker/PickerBuilder.php line 47 {"exception":"[object] (TypeError(code: 0): Argument 1 passed to Contao\\CoreBundle\\Picker\\PickerBuilder::addProv ider() must implement interface Contao\\CoreBundle\\Picker\\PickerProviderInterfac e, null given, called in .../system/modules/pct_customelements_plugin_cc_frontedit/PCT/Contao/Picker/PickerBuilder.php on line 102 at .../vendor/contao/core-bundle/src/Picker/PickerBuilder.php:47)"} []

Auslöser:

[wortberge]

Tim
- Guten Morgen,

den 500er konnte ich inzwischen auf den Seitenwähler eingrenzen. Macht ja Sinn

Ansonsten drehe ich mich leider immer noch im Kreis. Ich konnte mit neuen CC-Tabellen, neuen Seiten und Modulen ein lauffähiges Modell erzeugen. Mit den bestehenden CCs, die im Prinzip identisch miteinander verknüpft sind, funktioniert der das Editing nur beim Elternelement. Bei den Kindelementen ist die Liste zwar korrekt, aber der Reader springt nicht auf die übergebene URL an. Daraus resultiert ein 404er.

Ich habe auch versucht, die Eltern-Kind Beziehungen aufzulösen und hier also nur noch mit Tabellen erster Ebene (Eltern) zu arbeiten. Nach unseren bisherigen Theorien hätte das ja eigentlich eine Veränderung zur Folge haben müssen. Leider kein Erfolg.

Was mich regelrecht in den Wahnsinn treibt ist die Tatsache, dass die nackte Contao Instanz nur mit dem Custom Catalog + FE sich wie erwartet verhält. Hier fehlen nur beim neu Anlegen die PIDs beim Speichern des Datensatzes. Bis dahin alles ok!

Die Probleme treten bei Contao Installationen (live & dev) auf, bei denen zusätzlich noch Eclipse X, Notification Center und contao-mailusername installiert sind.

Lokal habe ich testweise auch die Sourcen komplett neu installiert und ein Update auf Contao 4.9.24 durchgeführt. Leider ebenfalls ohne Erfolg.
Auch habe ich testweise versucht, die betroffenen Tabellen mit den dazu gehörenden Konfigurationen zu löschen und neue anzulegen. Dabei kam es immer wieder zu 500ern, weil bei einem SQL-Query (Aufruf BE) die gelöschten Tabellen mit abgefragt wurden (SHOW ALL TABLES...). Cache geleert, Installtool ohne DB-Änderungen.

Wo setze ich nun am Besten an?

Danke für Deine Zeit.

[Tim]

Dabei kam es immer wieder zu 500ern, weil bei einem SQL-Query (Aufruf BE) die gelöschten Tabellen mit abgefragt wurden (SHOW ALL TABLES...). Cache geleert, Installtool ohne DB-Änderungen.

Richtig. Das kann nicht verhindert werden, weil Contaos Symfony-Cache nicht im Live-Betrieb tiefenrein geleert werden kann. Für einen Moment wird der Server in PHP Fehler laufen, nach einem Refresh der Seite baut der Cache wieder auf.

[wortberge]

Danke für den Tip! Dann macht mich das schon mal weniger nervös. Dachte, der Cache liegt komplett in var/cache und das lösche ich eigentlich bei solchen Aktionen immer, oder baue den Cache mit Composer neu auf.