Ddev, neues Modem (FritzBox) und DNS_PROBE_FINISHED_NXDOMAIN

Ich habe mir ein neues Modem (konkret eine FritzBox) zugelegt. Auf den ersten Blick schien alles so zu funktionieren wie vorher. Heute ist Montag, Zeit zu arbeiten: ddev gestartet und festgestellt, dass meine .ddev.site Domain mit der Meldung DNS_PROBE_FINISHED_NXDOMAIN nicht angezeigt wird. Beim ddev start gab es keine Fehlermeldungen, die Datenbank ist da und auf die Seite kann ich mit einer IP-Adresse zugreifen. Damit bleibt nur noch die Vermutung, dass die DNS-Auflösung die Ursache ist.

Nachdem ich die ddev-Troubleshooting-Seite und ein paar Foren durchsucht habe, stieß ich auf den entscheidenden Hinweis.

Die FritzBox hat ein Feature, das DNS-Antworten unterdrückt, die aufs eigene Netzwerk verweisen (DNS-Rebind-Schutz). Man muss die ddev.site dort unter Ausnahmen eintragen, damit die DNS-Auflösung funktioniert. Diese Option findet man unter Heimnetz > Netzwerk > Netzwerkeinstellungen.

FritzBox Einstellungen

Unable to load dynamic library ‘memcached.so’

Ich habe lokal unter Windows 10 ddev mit Ubuntu 20.04. aufgesetzt. Nach dem Login per SSH (ddev ssh) und dem Ausführen fast jeden Befehls (composer dump-autoload) kam die folgende Warnung:

PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/20190902/redis.so' (tried: /usr/lib/php/20190902/redis.so (/usr/lib/php/20190902/redis.so: undefined symbol: igbinary_serialize), /usr/lib/php/20190902//usr/lib/php/20190902/redis.so.so (/usr/lib/php/20190902//usr/lib/php/20190902/redis.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library 'memcached.so' (tried: /usr/lib/php/20190902/memcached.so (/usr/lib/php/20190902/memcached.so: undefined symbol: igbinary_serialize), /usr/lib/php/20190902/memcached.so.so (/usr/lib/php/20190902/memcached.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0

Erstmal hatte ich mich auf den “Unable to load” block fokussiert. Sind die Dateien da? – ja. Ist der Pfad richtig? – ja. Ist das Modul installiert? – ja. Es gab viele “Lösungsvorschläge” im Netz. Und es ist so unglaublich frustrierend, wenn das Problem als gelöst gilt (“That solved it, thanks”) und es bei mir immer noch da ist. Ich habe sogar den ddev Installationsvorgang fast komplett neu gemacht. Immer noch die gleiche blöde Warnung, die mir die Konsole zumüllt.

Dann habe ich eher auf den zweiten Teil der Meldung geschaut und danach gesucht: “undefined symbol: igbinary_serialize”.

Lösung: Die aktuellere Version von redis (wohl auch memcached) setzt voraus, dass die Bibiothek igbinary bereits geladen ist. An einer Stelle stand, dass es theoretisch der Fall sein müsste, denn die Bibliotheken werden alphabetisch geladen und i kommt wohl vor r. Wenn man im Ordner .ddev/php eine Konfigurationsdatei ablegt, dann wird diese beim Starten des Containers geladen. Um das igbinary vor den anderen Bibliotheken zu laden, reicht es aus, wenn man eine leere Datei namens 10-igbinary.ini in diesem Ordner ablegt. Da alle anderen Biblitheken eine 20 als Priorität haben, wird die Datei mit 10- früher berücksichtigt.

Vielleicht ist ja jemand irgendwann genauso verzweifelt wie ich und diese “Lösung” hilft ihm/ihr. Lasst es mich wissen…

TYPO3 auf ohne Composer umstellen

Ich persönlich arbeite mittlerweile sehr gerne mit Composer. Man kann schnell Extensions installieren/aktualisieren und TYPO3 aktualisieren. Bei jeden neuen Projekt arbeite ich mit Composer, außer es ist aus irgendwelchen Gründen doch nicht möglich – fehlende SSH Zugänge oder ähnliches. Manchmal kommt es vor, dass man eine mit Composer installierte TYPO3-Instanz von Composer wieder trennen muss.

Es ist eigentlich einfach – in der Datei vendor/typo3/cms-composer-installers/autoload-include.php nur den folgenden Abschnitt entfernen:

// TYPO3 is installed via composer. Flag this with a constant.
if (!defined('TYPO3_COMPOSER_MODE')) {
    define('TYPO3_COMPOSER_MODE', TRUE);
}

In meinem Fall hatte ich auch den crawler installiert. Nachdem ich den Abschnitt entfernt und alle Caches gelöscht hatte, wurde mein Backend nicht geladen mit der Fehlermeldung:

Warning: Uncaught TYPO3\CMS\Core\Error\Exception: PHP Warning: require([...]/public/typo3conf/ext/ crawler//Resources/Private/Php/ Libraries/vendor/autoload.php): failed to open stream: No such file or directory

In der ext_localconf.php der Extension crawler findet man folgendes:

if (!\TYPO3\CMS\Core\Core\Environment::isComposerMode()) {
require \TYPO3\CMS\Core\Utility\ExtensionManagementUtility::extPath('crawler') . '/Resources/Private/Php/Libraries/vendor/autoload.php';
}

Der angegebene Pfad existiert aber nicht. Ein Ticket beim Crawler-Issue-Tracker und ein paar Stunden später ist die Lösung eigentlich banal: Extension crawler aus dem TER neu installieren. Sobald man das tut, dann werden die erforderlichen Pakete (die bei der Installation per Composer in vendor installiert werden) unter dem entsprechenden Pfad abgelegt.

Gedankensalat zu TYPO3 Umsetzungen

Ich arbeiten ja nun bereits seit mehreren Jahren (seit 2007?) mit TYPO3 und dachte, dass ich schon fast alles gesehen hätte an Implementierungen und Ansätzen. Immer wieder werde ich überrascht von kreativen Ansätzen mancher Entwickler und Agenturen und stelle fest, dass ich auf solche Ansätze nicht gekommen wäre. Es gibt in der Programmierung nicht die eine “Wahrheit” (auch wenn manche gerne so tun als ob), sondern mehrere Lösungsmöglichkeiten für ein Problem. Manchmal denke ich darüber nach, ob in einem bestimmten Fall mein gewählter Ansatz der richtige ist. In der Retrospektive stelle ich dann bei fast allen Projekten fest, dass ich es aus heutiger Sicht anders gemacht hätte – und das ist auch gut so, das bedeutet, dass man sich persönlich weiterentwickelt hat. Als Freelancerin habe ich Einblick in viele Projekte, an denen vorher andere Agenturen oder Freelancer gearbeitet haben und manchmal würde ich (gelegentlich nach stundenlangem Fluchen) diese gerne fragen, warum sie dieses oder jenes so umgesetzt haben und nicht anders.

Das sind grob die Szenarien, die mir bisher begegnet sind

1) Nicht konfigurierbare Zielseiten/Texte/E-Mail-Adressen etc.
Wenn man schon dabei ist, einen Text oder eine E-Mail-Adresse einzugeben, sollte man sie nicht per TypoScript/Flexform/Datenbank-Feld konfigurierbar machen? Natürlich ist es schön, noch etwas Geld zu verdienen, wenn der Kunde eine Textkorrektur haben möchte oder die E-Mail-Adresse sich geändert hat. Habe ich dazu Lust? Nein.

2) Keine Verwendung von TYPO3 (Core) Konfigurationsmöglichkeiten
Man kann sich in TYPO3 mittels TSconfig doch zu Tode konfigurieren – was ich gerne nutze. Wenn das nicht hilft, gibt es doch Hooks und man kann auch direkt in ext_localconf und ext_tables konfigurerieren. Mit Backend Layouts und Content Defender kann man mittlerweile ziemlich genau einschränken, welche Inhaltselemente in welchen Spalten erlaubt sind. Letztens bin ich über eine Extension gestolpert, die den Content Element Browser und die Auswahl der Inhaltselemente (mit Hooks, höhö) kompett umgeschrieben hat. Welche Inhaltselemente erlaubt sind, steht in einer JSON-Datei. Wenn man diese Schema immer wieder verwendet, ist es natürlich gut. Wenn man als Agentur Entwickler ausbildet, dann zeigt man denen einmal, wie es funktioniert und schon können sie Inhaltselemente zusammenkloppen. Ich bezweifle jedoch, dass sie verstehen, was da im Hintergrund passiert. Jemand, der dieses Schema nicht kennt und das Projekt anschließend übernimmt, muss sich in diese Implementierung reindenken und entweder weiter damit arbeiten oder es so umschreiben, dass es näher an den Vorgaben ist.

3) Inhaltselemente nur für eine bestimmte Verwendung implementieren
Das bezieht sich vor allem aufs Frontend. Immer wieder erlebe ich, dass die Inhaltselemente nur genauso wie bisher eingepflegt gut aussehen und anderswo zwar positioniert werden können, aber dann das Layout zerschießen. Ich sehe TYPO3 mehr wie Duplo: verschiedene Bausteine und ich kann sie beliebig einsetzen. Ein Akkordion z.B. kann im Header, Inhalt und Footer eingesetzt werden und funktioniert dort immer wie erwartet. Wenn das nicht möglich sein soll, dann konfiguriere ich ihn in der Spalte weg (siehe Punkt 2) oder ich sorge per CSS dafür, dass er an allen drei Locations gut aussieht. Bei den meisten Implementierung ist es eher Mikado: So steht es gerade, aber bloß nicht anfassen.
Auch prüfe ich, ob ein Element zweimal auf der Seite einsetzen werden kann! Letztens gerade wieder eine Implementierung gesehen, bei der einem solchen Element ein feste HTML-id zugeteilt wurde und dann mit JavaScript irgendwas damit gemacht wurde. Blöd nur, wenn der Kunde das Element zweimal auf einer Seite einsetzt.

Das reicht fürs erste an Gruselgeschichten. Es hat auch Vorteile, dass mir immer wieder unterschiedliche Projekte begegnen. Zum einen werden meine grauen Zellen stimuliert – ich muss mich in andere Ansätze und Lösungen reindenken und arbeite nicht immer nach dem gleichen Schema. Zum anderen hinterfrage und optimiere ich immer wieder meine eigenen Ansätze und kann so das (zu dem jeweiligen Zeitpunkt) beste Ergebnis abliefern. Und diesen Aspekt mag ich besonders an meinem Freelancer-Dasein…

TYPO3 9 – Twitter-/Facebook Meta-Angaben mit Fallback auf Standardfelder

In TYPO3 9 gibt nach der Installation der Core-Extenson seo in den Seiteneigenschaften Felder, um Meta-Informationen für Facebook und Twitter zu hinterlegen. Diese Informationen werden im Quellcode ausgegeben, wenn man die Felder entsprechend ausgefüllt hat. Nun möchte man nicht explizit immer diese Informationen angeben müssen, vor allem weil der Facebook-/Twitter-Beschreibungstext wahrscheinlich eh identisch ist mit dem Beschreibungstext der Seite. Und die Bilder können automatisch aus dem Feld media generiert werden, wenn es denn befüllt ist.

Mit dem folgenden TypoScript lassen sich Beschreibung und Seitentitel in die Facebook-/Twitter-Meta-Angaben der Seite schreiben. Sobald die “richtigen” Felder ausgefüllt werden, dann werden die Angaben daraus ausgegeben.

page.meta {
    og:title.cObject = TEXT
    og:title.cObject {
        field = title
    }
 
    og:description.cObject = TEXT
    og:description.cObject {
        field = description
        # data = levelfield:-1 , description, slide
    }
 
    og:image.cObject = IMG_RESOURCE
    og:image.cObject.file {
        import.data = levelmedia:-1, slide
        treatIdAsReference = 1
        import.listNum = 0
        maxW = 1200
        cropVariant = default
    }
    og:image.cObject.stdWrap.dataWrap = {getIndpEnv:TYPO3_REQUEST_HOST}/
}

Damit es mit dem Levelfield Slide funktioniert, müssen die Felder in addRootLineFields aufgenommen werden. Das kann entweder “global” in der LocalConfiguration.php gemacht werden oder die Extension fügt diese der vorhandenen Liste hinzu.

In meinem Beispiel habe ich weiterehin Crop Varianten für das Media-Feld der Seite definiert und greife auf diese zu. Wenn das nicht gewünscht ist, dann die Zeile mit cropVariants = default einfach weglassen.

Slick Carousel Play/Pause Indikator

Ich bin seit ein paar Jahren großer Fan von Slick. Die Slideshow ist gut konfigurierbar und kann vielseitig eingesetzt werden.

Für mein aktuelles Projekt brauchte ich eine Möglichkeit die Slideshow zu stoppen und einen Indikator, ob die Slideshow im Autoplay läuft.

Ich habe also einen einfachen Button erstellt, ihn dann mit CSS so gestaltet, dass er von Play zu Pause transformiert und dieses JavaScript eingesetzt:

$('#stage-slideshow-playpause').on('click', function() {
    if($(this).hasClass('play')) {
        $(this).removeClass('play').addClass('pause');
        $('#stage-slideshow').slick('slickPause');
    } else {
        $(this).removeClass('pause').addClass('play');
        $('#stage-slideshow').slick('slickPlay');
    }
});
$('#stage-slideshow .slide').on('mouseenter.slick', function () {
    $('#stage-slideshow-playpause').removeClass('play').addClass('pause');
});
$('#stage-slideshow .slide').on('mouseleave.slick', function () {
    $('#stage-slideshow-playpause').removeClass('pause').addClass('play');
});

Im ersten Block kann man die Slideshow mit dem Button steuern, in den nächsten Abschnitten “reagiert” der Button auf externe Veränderung der Slideshow. Voraussetzung ist, dass die Option pauseOnHover aktiviert ist. Es gibt noch die Option pauseOnDotsHover, falls diese Option an ist, müsste man den Code entsprechend erweitern.

Lösung für Bilder im Flexform ohne Alternative-Feld

Für ein Custom Content Element kann in einem Feld Überschrift und ein Text eingegeben werden und ein Bild verknüpfte werden. Die Felder sind alle im Flexform definiert und der Kunde bemängelte (zurecht), dass die Möglichkeit zur Eingabe des Alternative Text beim Bild fehle. Kurz gesucht und einen Eintrag im Bezug auf TYPO3 6 gefunden, der unter TYPO3 9 immer noch funktioniert.

So wird das Bild im Flexform definiert:

<image>
    <TCEforms>
        <label>Bild</label>
        <config>
            <type>inline</type>
            <maxitems>1</maxitems>
            <minitems>1</minitems>
            <foreign_table>sys_file_reference</foreign_table>
            <foreign_table_field>tablenames</foreign_table_field>
            <foreign_label>uid_local</foreign_label>
            <foreign_sortby>sorting_foreign</foreign_sortby>
            <foreign_selector>uid_local</foreign_selector>
            <foreign_selector_fieldTcaOverride type="array">
                <config>
                    <appearance>
                        <elementBrowserType>file</elementBrowserType>
                        <elementBrowserAllowed>jpg,png</elementBrowserAllowed>
                    </appearance>
                </config>
            </foreign_selector_fieldTcaOverride>
            <foreign_match_fields type="array">
                <fieldname>image</fieldname>
            </foreign_match_fields>
            <appearance type="array">
                <newRecordLinkAddTitle>1</newRecordLinkAddTitle>
                <headerThumbnail>
                    <field>uid_local</field>
                    <height>64</height>
                    <width>64</width>
                </headerThumbnail>
            </appearance>
        </config>
    </TCEforms>
</image>

Und folgenden Block muss man einfügen, damit das alt-Feld angezeigt wird:

<image>
    <TCEforms>
        <label>Bild</label>
        <config>
            [...]
            <foreign_types type="array">
                <numIndex index="2">
                    <showitem>title,description,alternative</showitem>
                </numIndex>
            </foreign_types>
            [...]
        </config>
    </TCEforms>
</image>

Das war der Artikel, den ich gefunden habe: https://typo3-english.typo3.narkive.com/0GGddVxh/typo3-6-0-using-fal-image-in-a-flexform-as-an-element

Grundsätzlich würde ich davon abraten, Bilder im Flexform zu referenzieren. Gerade in diesem Fall, wenn die Felder wie Überschrift, Text und Bild bereits in der Tabelle vorhanden sind, wäre es deutlich einfacher gewesen, zwar ein neues Inhaltselement zu definieren, jedoch die vorhandenen Felder zu nutzen. Es hat diverse Vorteile: man kann das Element in Typ Text “konvertieren”, ohne die Inhalte zu verlieren und die Inhalte können besser gefunden werden. Das Projekt habe ich von einem anderen Entwickler übernommen und das Element wird bereits häufig genutzt, so dass ein Umbau nicht mehr so einfach ist.

404 Fehlerseite beim Routing nach Update auf 9.5.20

Für ein selbst-geschriebenes Plugin hatte ich eine funktioniere Routing-Konfiguration umgesetzt. Die Extension ist so eine Art news, aber deutlich abgespeckt. Da die Beiträge alle ein Datum haben, gibt es eine einfache Datumsnavigation. Nach einem Update auf TYPO3 9.5.20 funktionierten die Detail-Links weiterhin, die Links der Datumsnavigation lieferten einen 404-Fehler – Seite nicht gefunden.

Die funktonierende Konfiguration sah so aus.

routeEnhancers:
  Magazine:
    type: Extbase
    extension: MyMagazine
    limitToPages:
      - 18
      - 65
    plugin: Magazine
    defaultController: 'Article::list'
    defaults:
      date-month: ''
      date-year: ''
    routes:
      -
        routePath: '/{article-title}'
        _controller: 'Article::show'
        _arguments:
          article-title: article
      -
        routePath: '/{date-year}-{date-month}'
        _controller: 'Article::list'
        _arguments:
          date-month: overwriteDemand/month
          date-year: overwriteDemand/year
        requirements:
          date-month: \d+
          date-year: \d+
    aspects:
      article-title:
        type: PersistedAliasMapper
        tableName: tx_mymagazine_domain_model_article
        routeFieldName: path_segment
      date-month:
        type: StaticRangeMapper
        start: '01'
        end: '12'
      date-year:
        type: StaticRangeMapper
        start: '2000'
        end: '2030'

Nach dem Update und dem 404-Fehler beim Aufruf der Ansicht mit Jahr-Monat-Parametern hatte ich lange gesucht, unterschiedliches ausprobiert, mich durch den Quellcode gehangelt, es half alles nichts. Ich hatte mich bei der Konfiguration nach der Dokumentation von news gerichtet (Hut ab vor Georg Ringer und dieser Extension). Da ist der Block requirements in dem jeweiligen routePath-Block definiert. Die aktuellste Dokumentation des Core sieht da etwas anders aus: der requirements-Block steht dort an der gleichen Ebene wie aspects und routes. Die Lösung meines Problems war die Angabe von genauen Requirements auf der gleichen Ebene wie routes und aspects, sicherheitshalber habe ich noch einen neuen Konfigurationsabschnitt angelegt (DateMenu).

  DateMenu:
    type: Extbase
    extension: MyMagazine
    limitToPages:
        - 18
    plugin: Magazine
    defaultController: 'Article::list'
    defaults:
      date-month: ''
      date-year: ''
    routes:
      - routePath: '/{date-year}-{date-month}'
        _controller: 'Article::list'
        _arguments:
          date-month: overwriteDemand/month
          date-year: overwriteDemand/year
    requirements:
      date-month: '[0-9]{2}'
      date-year: '[0-9]{4}'
    aspects:
      date-month:
        type: StaticRangeMapper
        start: '01'
        end: '12'
      date-year:
        type: StaticRangeMapper
        start: '2000'
        end: '2030'

Die nicht mehr funktionierende Konfiguration ist wahrscheinlich auf diesen BUGFIX zurückzuführen – es ist jedoch nur eine Vermutung…

TYPO3 Extension und Composer-Packages ohne Composer

Ich bin schon verwöhnt, seit ich Composer nutze. Da gibt es dann andere Problemchen, aber zumindest braucht man sich keine Gedanken um Abhängigkeiten zu machen. Extension per Composer installieren, notwendige Pakete werden geladen – fertig! Gelegentlich kommt es vor, dass auf einem Kunden-Server Composer nicht installiert werden darf oder der Kunde es nicht wünscht. Ich knirsche dann ein bisschen mit den Zähnen und arbeite so wie früher – “classic way”, wie es auf get.typo3.org so schön heißt.

Aktuell habe ich genau so einen Fall. Ich habe eine Extension installiert, die folgende Pakete benötigt:

"geocoder-php/google-maps-provider": "^4.4",
"php-http/guzzle6-adapter": "^1.0",
"php-http/message": "^1.7",
"geocoder-php/nominatim-provider": "^5.1"

Zunächst habe ich angefangen, mit alle Pakete aus den jeweiligen Git-Repos herunterzuladen, die dann wiederum andere Pakete brauchten etc. So hangelte ich mich von Paket zu Paket. Die Dateien der Pakete müssten natürlich nicht nur da sein, sondern auch eingebunden werden. Am Anfang hatte ich jede Datei einzeln mit require eingebunden – da wird man ja bekloppt! Es wurde mir composer-file-loader empfohlen. Es löst zwar das Problem, dass man die Dateien nicht alle einzeln aufführen muss, aber ein Paket benötigt das andere und sich an den Abhängigkeiten entlanghangeln muss man ja selbst.

Etwas später in einer ruhigen Minute hatte ich die Idee: Ich kann auf dem Server kein Composer nutzen, aber ich kann LOKAL Composer nutzen, um mir die notwendigen Pakete zu laden.

Ich habe eine TYPO3 Extension erstellt, die nur aus ext_localconf.php, ext_emconf.php und composer.json besteht. In die composer.json habe ich die benötigten Pakete aufgelistet:

{
    "name": "myvendor/myextension",
    "type": "typo3-cms-extension",
    "description": "Externe Pakete, da sie nicht per Composer installiert werden können",
    "license": "GPL-2.0+",
    "require": {
        "geocoder-php/google-maps-provider": "^4.4",
        "php-http/guzzle6-adapter": "^1.0",
        "php-http/message": "^1.7",
        "geocoder-php/nominatim-provider": "^5.1"
    },
    "config": {
        "vendor-dir": "vendor"
    }
}

Dann auf der Konsole in dem Extension-Ordner composer install laufen lassen. Nicht nur, dass mir composer alle Pakete mit den Abhängigkeiten lädt, er erstellt auch eine autoload.php, die ich einbinden kann. Somit steht in meiner ext_localconf.php nur noch das:

require_once(\TYPO3\CMS\Core\Utility\GeneralUtility::getFileAbsFileName('EXT:myextension/vendor/autoload.php'));

Da merkt man doch wieder, wie schön Arbeiten mit Composer ist…

Plugins in GridElement scheinbar ohne Flexform-Settings

Falls jemand so wie ich einige Stunden (ok, ich übertreibe etwas) an diesem Problem verzweifeln sollte. Ich habe eine 3-spaltiges GridElement, das ich gemäß der aktuellsten Vorgabe mit dem DataProcessor umgesetzt habe. Übrigens ist die Dokumentation an dieser Stelle falsch.

Dort heißt es:

This is the default TypoScript setting provided while including the special Gridelements w/DataProcessing setup in your TS template editor:

lib.gridelements.defaultGridSetup =< lib.contentElement
lib.gridelements.defaultGridSetup {
[...]

Das Objekt lib.gridelements.defaultGridSetup gibt es nicht. Es wird tt_content.gridelements_pi1 hinzugefügt, der Rest der Angaben in der Dokumentation stimmt soweit.

Nun hatte ich also in einer Spalte ein Plugin mit ein paar Einstellungen, die über ein Flexform vorgenommen werden. In der "normalen" Content-Spalte funktioniert alles - meine Einstellungen werden im Frontend entsprechend ausgewertet. In einer Spalte in diesem GridElement hingegeben nicht - ich bekam in meinem Fall gar keine Ausgabe. Zum Glück bin ich zufällig über einen Issue gestolpert. Das Problem ist, dass der GridChildrenProcessor in Standardfall das Feld pi_flexform der Kinder parst und dabei in ein Array umwandelt. Wenn man die Inhalte der Spalte wie folgt ausgibt, dann wird die Eingabe im Feld pi_flexform nochmal verarbeitet.


Da es ja kein String mit XML-Inhalten, sondern ein Array ist, werden die Settings nicht ausgelesen und im Frontend nicht intepretiert. Das liegt an der Einstellung resolveChildFlexformData, die per default 1 ist. In diesem Issue wird vorgeschlagen, den Wert von resolveChildFlexformData per Default auf 0 zu setzen. Um breaking changes zu vermeiden, wird entschieden, diesen Wert wie vorher zu belassen, d.h. auf 1.

In meinem Fall ist die Lösung somit, diese Einstellung auf 0 zu setzen.

tt_content.gridelements_pi1.dataProcessing.10.default.options.resolveChildFlexFormData = 0