Kategorie: Extensionentwicklung
Ausgangssituation In einem Projekt waren in einer TYPO3-Instanz über den Seitenbaum mehrere Marken in verschiedenen Ländern mit jeweils eigenen (Teil-)Seitenbaum abgebildet. Die einzelnen Websites waren inhaltlich-strukturell sehr ähnlich, und es waren viele spezifische Plugins im Einsatz. Insgesamt entstand so für die rund 100 Einstiegseiten eine (via realURL-Autoconfiguration erzeugte) rund 4,5 MB große Konfiguration. Die war uns ein Dorn im Auge.
Manchmal könnte man fast verzweifeln. Die neue Extension für den Kunden ist endlich fertig, es soll nur noch schnell ein Textchen mehr an einer Stelle rein. Kein Problem, locallang.xml ergänzt und im Fluidtemplate auch noch eine Zeile ergänzt – im Frontend bleibt die Stelle jedoch leer. Eine Überprüfung, ob der Key denn auch korrekt ist, bestätigt: ja, ist korrekt 🙁 Ursache ist (wie leider so oft) der Cache, der es (zu) gut meint. Lösung: Seit TYPO3 4.6 cacht der l10n-Parser (basierend auf dem Caching Framework) die Übersetzungen. Ein Löschen dieses Caches bringt dann den neu hinzugekommenen Wert auch zum Vorschein....
Anforderung war, dass aus einem Scheduler-Task heraus korrekte sprechende URLs erzeugt werden. Der einfachste Weg hierfür ist eine der typolink-Methode des cObjects. Leider steht ein solches aber in Tasks von Haus aus nicht zur Verfügung. Anleitung, wie man sich ein solches erzeugen kann, finden sich im Internet viele – leider aber auch zahlreiche, die nicht (mehr) funktionieren oder riesen woodoo treiben. Nach einigen Recherchen und Tests kann ich nun einen Weg zur Problemlösung festhalten.
Einige Zeit hat es mich heute gekostet, um festzustellen, warum meine Erweiterung der realurl-Konfiguration via Hook zur Autoconfiguration fehlerhaft in der Konfiguration ankommt. Ursache ist ein Fehlverhalten der PHP-Funktion array_merge_recursive(). array_merge_recursive() Zunächst, die Beschreibung der Funktion aus der Dokumentation: array_merge_recursive() merges the elements of one or more arrays together so that the values of one are appended to the end of the previous one. It returns the resulting array. If the input arrays have the same string keys, then the values for these keys are merged together into an array, and this is done recursively, so that if one of...
Wer des öfteren mal die Funktionalität von TYPO3 mit eigenen Extensions erweitert, wird des Öfteren auf das Problem stoßen, dass bei der Erweiterung von Tabellen oder beim anlegen von Extension-spezifischen Datenbanktabellen bei der hauseigenen Suche außen vor bleiben. Hier ist es sinnvoll, der Suche mitzuteilen, es möge doch bei der Suche auch zusätzliche Felder berücksichtigen. Dies lässt sich einfach und – im Gegensatz zu IF-Abfragen – einfach über TypoScript lösen. Um der Suche die neuen Datenbank-Tabellen und/oder Felder mitzuteilen, geht man folgendermaßen vor. Standard-Wert für „Überschriften und Schlagwörter“: tt_content.search.30.dataArray.20.valueArray.10.value = pages.title-subtitle-keywords-description Standard-Wert für „Seiteninhalt“: tt_content.search.30.dataArray.20.valueArray.20.value = pages.title-subtitle-keywords-description : tt_content.header-bodytext-imagecaption Zur...
Seit TYPO3 4.3 können Klassen automatisch beim Laden einer Extension eingebunden werden (z.B. rund um die Scheduler Tasks nützlich). Eigentlich kein Hexenwerk, aber als kleine Gedankenstütze trotzdem ein paar Zeilen Code und die Rahmenbedingungen: ext_autoload.php: <?php $extensionPath = t3lib_extMgm::extPath(‚myext‘); return array( ‚tx_myext_myclass‘ => $extensionPath . ‚Classes/class.tx_myext_myclass.php‘, ); ?> Rahmenbedingungen der Key muss immer kleingeschrieben sein, auch wenn die Klasse im CamelCase-Stil benamt ist der Key muss mit tx_ (oder ux_) beginnen bzw. derart sein, dass mittels t3lib_extMgm::getExtensionKeyByPrefix($prefix) der Extension-Key ermittelbar ist ($prefix ist hierbei der Substring des Keys bis zum zweiten Unterstrich) die Datei ext_autoload.php liegt im Hauptverzeichnis der Extension...
Zuviele Dateien in einem einzelnen Verzeichnis können zu einem Flaschenhals werden, der in seltenen Fälle auftritt, und schwer zu aufzuspüren ist. Eintreten kann dies durch sehr große Fotogalerien (z.B. Disco-/Szene-Websites mit hunderten Fotos pro Abend), große Shops mit zig Varianten pro Bild – oder durch Programmierfehler/Logikfehler. TYPO3 generiert hier brav die skalierten Bilder und speichert sie defaultmäßig in typo3temp/pics/. Sind hier irgendwann sehr viele Dateien gespeichert – in einem Fall bei uns ca. 500.000 – leidet das Betriebssystem darunter und baucht ggf. etwas länger, um einen Dateiaufruf beantworten zu können, da die zu durchsuchende Menge (zu) groß ist. Weiß man...
Newsmeldungen werden mit tt_news wunderbar kategorisiert, verwaltet,… – aber auch archiviert??? Meine Antwort ist: Jain. Eine Archivierungsfunktion hat die Extension, doch so ganz wunderbar ist diese leider nicht. So wird das gesetzte Archivierungsdatum ignoriert, falls es größer als das aus datetimeDaysToArchive errechnete Datum ist. Für eine Verkürzung der Archivierungszeit funktioniert es hingegen. Eine Lösung lässt sich jedoch über das User TSconfg bauen.
Da in einem ViewHelper per $this->settings nicht auf das TS zugegriffen werden kann, wird folgende Zeile zum Auslesen benötigt: $settings = $this->templateVariableContainer->get(’settings‘);
Typischer Fall bei eigenen Datenbankrecords: es ist eigentlich nur ein kurzes zwei-/dreizeiliger Text vorgesehen, aber es sollten Links, Fettschrift usw. möglich sein. Nun steht man vor der Enstcheidung: Plaintext-Feld oder großen, üppigen RTE. Im standardmäßgen RTE-Feld gehen die zwei Zeilen Text fast unter, und das Feld „blockiert“ viel Platz im BE-Formular. Die Anordnung wirkt zerrissen,… Auf ganz einfache Weise lässt sich das bereits beim Erstellen der Extension beeinflussen: pageTSconfig.txt anlegen und einbinden in der ext_localconf.php via: t3lib_extMgm::addPageTSConfig(‚FILE:EXT:meine_extension/pageTSconfig.txt‘); Im pageTSconfig kann dann der RTE vorkonfiguriert werden. Zum Beispiel mit: RTE.config.tx_meineextension_tabelle.shortdescription.RTEHeightOverride = 140 Quellen: Höhe und Breite für den RTE (als PDF-Backup)
