Sonderbare Meldung im Modal beim Löschen der Seite

Es ist ein sehr spezieller Fall, den wahrscheinlich kaum jemand kennen wird, aber mir hat es nochmal etwas neues über die Konfiguration in TYPO3 beigebracht.

Mir wurde gemeldet, dass beim Löschen einer Seite aus dem Kontext-Menü im Seitenbaum folgende Meldung im Modal erscheint:

No content provided, please check your Modal configuration.

Ich wusste nicht direkt, welche Modal-Konfiguration gemeint ist, und habe mich durch den Code gehangelt. Erstmal die Meldung suchen – der Locallang-Key ist “mess.delete”. Dann suchen, wo diese Meldung generiert wird – das war im \TYPO3\CMS\Backend\ContextMenu\ItemProviders\RecordProvider in der Funktion getDeleteAdditionalAttributes. Dann rausgefunden, dass die Funktion nicht die korrekten Attribute liefert und dass es an if ($this->backendUser->jsConfirmation(JsConfirmation::DELETE)) { ... } scheitert.

Schaut man sich die Funktion jsConfirmation genaue an, dann bekommt sie als Parameter eine Bitmaske. Diese Bitmaske steht in User TSconfig unter options.alertPopus. Ich hatte in meinem Fall diesen Wert gesetzt auf 250. Vergleicht man es mit der Dokumentation, ist dort 255 für “Alle Popups” angegeben.

255 steht für die Bitmaske 11111111 und
250 steht für die Bitmaske 11111010

Das erste Bit von hinten steht für “On Type Change”, das dritte Bit von hinten für “Löschen”. Das ergibt sich aus den Angaben der Werte in der Dokumentation. 1 entspricht der Bitmaske 1, 4 entspricht der Bitmaske 100. Wenn man nun die Zahlen vergleicht, dann unterscheidet sich 255 und 250 genau an diesen zwei Stellen.

Es wäre natürlich besser, wenn das Modal gar nicht erst angezeigt wird, wenn in der Bitmaske das Löschen-Bit 0 ist. In diesem Fall habe ich es einfach dadurch “gelöst”, dass ich den Wert für options.alertPopups auf 255 gesetzt habe. Dann kommt zumindest keine verstörende Meldung 🙂

Weiterleitung auf mit www und https

Meiner Meinung nach war das die beste Lösung für eine Weiterleitung von ohne www auf mit www. Gefunden bei Stackoverflow.

RewriteCond %{HTTP_HOST} !^www\..+$ [NC]
RewriteRule ^ https://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Es enthält keinen Domain-Namen und kann damit überall eingesetzt werden.

TCA für Image Manipulation (crop) in eigener Extension

Es gibt ein paar Beispiele im Netz, wie man Bild-Manipuation für tt_content aktiviert und Crop-Varianten (cropVariants) definiert. Ich habe kein Beispiel gefunden, wie man in seiner eigenen Extension direkt einem Bild-Feld Crop-Eigenschaften mitgeben kann. Nach langer Suche und viel rumprobieren ist das mein Ergebnis, das funktioniert.

'stage_image' => [
    'exclude' => true,
    'label' => 'LABEL',
    'config' => \TYPO3\CMS\Core\Utility\ExtensionManagementUtility::getFileFieldTCAConfig(
        'stage_image',
        [
            'appearance' => [
                'createNewRelationLinkTitle' => 'LLL:EXT:frontend/Resources/Private/Language/locallang_ttc.xlf:images.addFileReference'
            ],
            'overrideChildTca' => [
                'types' => [
                    '0' => [
                        'showitem' => '
                        --palette--;;imageoverlayPalette,
                        --palette--;;filePalette'
                    ],
                    \TYPO3\CMS\Core\Resource\File::FILETYPE_IMAGE => [
                        'showitem' => '
                        --palette--;;imageoverlayPalette,
                        --palette--;;filePalette'
                    ],
                ],
                'columns' => [
                    'crop' => [
                        'config' => [
                            'cropVariants' => [
                                'default' => [
                                    'title' => 'Desktop',
                                    'allowedAspectRatios' => [
                                        'default' => [
                                            'title' => 'Rechteckig 22:9',
                                            'value' => 2.4
                                        ],
                                    ],
                                ],
                            ],
                        ],
                    ],
                ],
            ],
            'foreign_match_fields' => [
                'fieldname' => 'stage_image',
                'tablenames' => 'xxx',
                'table_local' => 'sys_file',
            ],
            'maxitems' => 1,
        ],
        $GLOBALS['TYPO3_CONF_VARS']['GFX']['imagefile_ext']
    ),
],

Redirect von URLs mit .html auf /

Vor TYPO3 9 und dem Routing im Core war RealURL sehr gnädig, was URLs anging. So konnte eine Seite mit .html Suffix und auch mit / aufgerufen werden (mein Empfinden). In TYPO3 10 funktioniert diese Verhalten nur in eine Richtung. Konfiguriert man eine .html Endung über den PageSuffix, ist die Seite weiterhin mit Trailing Slash aufrufbar. Es ist eigentltich gut, dass entweder das eine oder das andere geht. Wenn sie jemand die URL mit .html Endung gebookmarked hat und dann statt der Seite 404 bekommt, ist es ärgerlich.

Dank dieses sehr guten Beitrags auf stackoverflow hier mein Redirect-Schnipsel für die htaccess-Datei.

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)\.html$ /$1/ [L,R=302]

Als Tipp stand in dem Beitrag, dass man während des Testings den Fehlercode 302 verwenden sollte (found) und erst wenn es final ist, dann 301, weil dieser vom Browser gecached wird.

TYPO3 Meldung bei gesperrten Records im Backend

Ich arbeite ja fast immer in der englischen Version, daher ist mir dieser Fehler nicht aufgefallen. Wenn ein anderer Benutzer einen Datensatz (z.B. eine Seite) zum Bearbeiten geöffnet hat, dann wird im TYPO3 Seitenbaum eine Meldung angezeigt. Im Englischen lautet die Meldung wie folgt:
“The user ‘%s’ began to edit this record %s ago.” Dann wird der Benutzertyp und das Datum eingesetzt, passt soweit.

Ist das Backend auf deutsch eingestellt, sieht diese Meldung etwas komisch aus.

Die Anführungsstriche werden mit HTML-Entities dargestellt.

Die Suche im Netz gab diesen wertvollen Beitrag aus der TYPO3-Doku aus: https://docs.typo3.org/m/typo3/reference-coreapi/9.5/en-us/ApiOverview/Internationalization/ManagingTranslations.html

Die Übersetzungen fürs Backend können also in einer eigenen Extension überschrieben werden.

Das in die ext_localconf.php einer eigenen Extension:

$GLOBALS['TYPO3_CONF_VARS']['SYS']['locallangXMLOverride']['de']['EXT:core/Resources/Private/Language/locallang_core.xlf'][] = 'EXT:my_extension/Resources/Private/Language/de.locallang-core.xlf';

Dann unter dem angegebenen Pfad die xlf-Datei anlegen und folgendes rein:

<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<xliff version="1.0">
    <file source-language="en" datatype="plaintext" date="2013-03-09T18:44:59Z" product-name="examples">
        <header/>
        <body>
            <trans-unit id="labels.lockedRecord" resname="labels.lockedRecord" approved="yes">
                <source>The user '%s' began to edit this record %s ago.</source>
                <target state="translated">Der Benutzer '%s' hat mit der Bearbeitung dieses Datensatzes vor %s begonnen.</target>
            </trans-unit>
            <trans-unit id="labels.lockedRecord_content" resname="labels.lockedRecord_content" approved="yes">
                <source>The user '%s' began to edit content on this page %s ago.</source>
                <target state="translated">Der Benutzer '%s' hat mit der Bearbeitung dieser Seite vor %s begonnen.</target>
            </trans-unit>
            <trans-unit id="labels.lockedRecordUser" resname="labels.lockedRecordUser" approved="yes">
                <source>The %s '%s' began to edit this record %s ago.</source>
                <target state="translated">Der %s '%s' hat mit der Bearbeitung dieses Datensatzes vor %s begonnen.</target>
            </trans-unit>
            <trans-unit id="labels.lockedRecordUser_content" resname="labels.lockedRecordUser_content" approved="yes">
                <source>The %s '%s' began to edit content on this page %s ago.</source>
                <target state="translated">Der %s '%s' hat mit der Bearbeitung dieser Seite vor %s begonnen.</target>
            </trans-unit>
        </body>
    </file>
</xliff>

Klappt! Hab ich schon erwähnt, dass ich TYPO3 toll finde 😀

Sport

Dieser Blogbeitrag beschäftigt sich mit meiner zweiten Leidenschaft neben TYPO3 – dem Sport. Ich beschreibe meine Sport-Karriere und wie sich das ganze im letzten Jahr pandemie-geschuldet verändert hat.

(mehr …)

TYPO3 – Domain Property als Boolean validieren

Ich habe lange gesucht und kein Beispiel gefunden, daher hoffe ich, dass ich damit jemandem die Sucherei und das Quellcode-Lesen ersparen kann.

Möchte man eine Property als Boolean validieren, dann lautet die Annotation wie folgt:

use TYPO3\CMS\Extbase\Annotation as Extbase;
 
/**
 * @var boolean
 * @Extbase\Validate(validator="Boolean", options={"is": "1"})
 * @Extbase\ORM\Transient
 */
protected $privacy;

Die Begründung ist, dass für die Abwärtskompabitilität nicht per Default validiert werden kann. Denn alle Properties vom Typ Boolean werden damit validiert.

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.