Nutzern von Chrome oder Firefox dürfte in der letzten Zeit aufgefallen sein, dass der RTE (Rich Text Editor) seit dem Update auf Chrome 73 im TYPO3-Backend nicht mehr richtig lädt und lediglich ausgegraut bzw. mit der Meldung „Der Editor wird geladen. Bitte warten…“ dargestellt wird. Das Problem betrifft alle älteren TYPO3-Versionen (7.6 und abwärts).
Bei der Arbeit mit VueJS in Kombination mit jQuery kommt es häufig zu dem Problem, dass VueJS das DOM oder sogar das data-Attribut eines Elementes ändert, aber jQuery noch per jQuery.data() auf alte Daten zugreift.
Hintergrund: Beim Initialisieren der Elemente cached jQuery die data-*-Attribute und speichert sie in einer internen Variable, um später schneller darauf zugreifen zu können. Eine Änderung der data-*-Attribute über VueJS – oder bereits eine Änderung der Reihenfolge der Elemente im DOM – führt zu einer falschen Zuordnung zwischen Element und dem data-Cache von jQuery.
Dieses kleine Plugin löst das Problem: Nach einer Änderung des DOM über VueJS kann einfach $('.element').rebuildData(); aufgerufen werden, um alle data-Attribute des Elementes und rekursiv aller Unterknoten erneut zu parsen und in jQuery.data() zu speichern.
Wer eine eigene Domain besitzt, steht vor der Entscheidung die E-Mails auf ein Konto bei Anbietern wie Google Mail, GMX oder Web.de weiterzuleiten oder ein sich beim Hoster ein eigenes Konto für die E-Mail-Adresse einzurichten. Für letzteren Fall bieten Hosting-Provider wie Host Europe in der Regel einen eigenen Mailserver an, der bereits über eine entsprechende vorgefertigte Konfiguration verfügt. So werden auch passende DNS-Einträge der Domain beim Hoster automatisch gesetzt. Ganz bequem also. Doch sobald ein eigener Server im Einsatz ist, wird es möglicherweise schon etwas kniffeliger, um mit versendeten E-Mails nicht im Spam-Order des Empfängers zu landen. Wie ist dies also einzustellen?
Folgendes Szenario:
Wir besitzen zwei verschiedene Server und möchten Daten via FTP von Server A auf Server B transferieren. Die einfachste und herkömmliche Methode wäre hierbei die Daten von Server A herunterzuladen und sie anschließend bei Server B wieder hochzuladen. Dieser Umweg kann insbesondere bei einer Vielzahl an Daten sehr langwierig sein.
Abhilfe für dieses Problem schafft das sogenannte File eXchange Protocol (FXP), welches einen Site-to-Site-Transfer von zwischen zwei Servern herstellt und eine direkte Datenübertragung ermöglicht.
Während der Entwicklung von Typo3-Extensions ändert, erstellt und erweitert man häufig Klassen in seinem eigenen Namespace. Durch das (sinnvolle) Typo3-Caching werden diese Klassennamen und Pfade in einer PHP-Datei gecached (typo3conf/autoload/autoload_classmap.php).
Leider greift der Klick auf den „Typo3 Blitz“ mit der Option „Alle Caches leeren“ nicht, um auch diese Dateien neu aufzubauen. Typo3 zwingt den Entwickler ins Install-Tool und dort zu der Option „Create autoload information for extensions“. Dieser Wechsel ist relativ nervig – und eine klassische Frustrations-Quelle, wenn im Frontend mal wieder das „striped Zebra of death“ mit einem Fatal Error erscheint.
Spickzettel für verschiedene Problem, die bei der Installation von Typo3 8 unter AMPPS (Mac OSX El Capitan) mit PHP 7.1 entstanden sind. Als SMTP-Server diente ein externer Server bei HostEurope, der als SMTP-Zieladresse für die lokale postfix Konfiguration angegeben wurde.
Vor einigen Tagen haben wir einen Beitrag veröffentlicht, wie man ein die Typo3 Core Extension tx_form um ein eigenes Formularelement erweitern kann.
Die Typo3 Extension tx_form ist zwei Dingen vorbildlich: Der modularen und konsequent objektorientierten Architektur. Und im bisher unerreichten Verwirrungsfaktor für Normalsterbliche. Ich weiß nicht, wie viele Stunden wir im Ordner sysext/form verbracht haben, um zu verstehen, welches mixin von welchem übergeordneten mixin per __inheritances welche Konfigurations-Häppchen erbt.
Genauso unverständlich und eine echte Motivationsbremse ist es für viele Typo3-Entwicklern, dass tx_form auf eine weitere Konfigurationssprache setzt. TypoScript, TCA und FlexForm-XML? Alles alte Hasen, da geht noch einer. Also jetzt noch YAML dazu. Zwei spaces statt tab. Unlesbare Dateien und kaum brauchbare Editoren. Und was die Erweiterbarkeit angeht noch ziemlich buggy. Na dann, lasst uns mal einsteigen.
Falls man ein Custom Form Element erstellen möchte, haltet euch an das How-To. Für detaillierte Informationen und die Dokumentation zur ext:form besucht: https://docs.typo3.org/typo3cms/extensions/form/Index.html
Außerdem haben wir eine „Anleitung für Dummies und Normalsterbliche, die einfach einen Job zu erledigen haben“ erstellt – eine Kurzfassung mit farblicher Kennzeichnung und einem simplen Online-Generator.
Zum Upload einer Datei im Backend oder Frontend von Typo3 8+ hilft die ExtendedFileUtility mit ein paar schönen Methoden.
Für Suchmaschinen: Upload einer Datei in eigenem Backend-Module von Typo3. Upload file in typo3 backend module. File-Upload Typo3 backend, move_uploaded_file() in Mod-Controller. Typo3 ExtendedFileUtility upload example. TYPO3\CMS\Core\Utility\File\ExtendedFileUtility::init(). Upload files in TYPO3 from Frontend. Datei vom Frontend hochladen und im Controller an Ort bewegen. Typo3 upload file data. f:form.upload nutzen zum Upload einer Datei aus dem Backend oder Frontend.
Die schöne Typo3-Extension „mask“ erlaubt das komfortable Anlegen eigener Inhaltselemente im Backend. Per Drag & Drop können die Formularfelder des Inhaltselementes definiert werden und die Extension generiert automatisch das passende TCA. Leider erlaubt die Extension aber nicht, einen eigenen renderType anzugeben, um z.B. ein eigenes Icon-Selector im Backend darzustellen.
Da mask technisch gesehen nichts Anderes macht, als die tt_content-Tabelle um neue Spalten/Felder zu erweitern und das TCA für tt_content zu generieren, lässt sich der eigene renderType relativ leicht angeben.