TYPO3 Erweiterungs Wunschliste

veröf­fent­licht am 24 March 2018
zuletzt bearbeitet am 30 July 2018

Eine Sammel­stelle für TYPO3 Erwei­te­rungen die ich unbedingt haben will und irgend­wann vielleicht auch baue.

Ich arbeite jeden Tag mit TYPO3 und stolper daher ständig über Funktionen bei denen ich denke “Ich kann doch nicht der erste sein der so etwas haben will”. Eventuell baue ich diese mal als exten­sion aber zur Dokumen­ta­tion schreibe ich sie hier auf.

Die Reihen­folge hat keinerlei Bedeu­tung, es ist einfach die Reihen­folge in der sie mir ein gefallen sind. Ich aktual­li­siere diese List auch ab und zu.

Internationalization utilities

Es gibt in php die intl exten­sion welche Klassen wie den ‘Number­For­mat­ter’ und den ‘Intl­Da­te­For­mat­ter’ mitbrin­gen. Dies sind Features die Zwingend in ViewHelper verpackt gehören. Ich habe diese ViewHelper bereits (inspi­riert von der Twig Intl Erweiterung), ich muss sie nur noch in eine Exten­sion auslagern.

Mir fallen aber noch mehr Funktio­na­li­täten ein. zB. möchte ich eine Typolink-Er­wei­te­rung ein bauen die tel: unter­stützt und mithilfe von giggsey/libphonenumber-for-php formatiert.

Und wenn wir schon dabei sind, Symfony’s intl polyfill, welcher als Abhän­gig­keit durchaus Sinn ergibt wenn die Erwei­te­rung intl sowieso voraus­ge­setzt ist, enthält auch icu Daten womit ich einen ‘Coun­try­Na­me­View­Hel­per’ und einen ‘Langua­geN­a­me­View­Hel­per’ imple­men­tieren kann.

Kopieren von sys_lanugage in typoscript constanten

Ja, dazu fällt mir kein richtiger Name ein und eventuel gehört das zur Erwei­te­rung oben.

Aktuell muss man in TYPO3 jede Sprache hardco­dieren und mit der Daten­bank synchron halten mit so lustigen Bedin­gungen in typos­cript wie:

[globalVar = GP:L=1]
config.sys_language_uid = 1 
config.language = de
config.htmlTag_langKey = de
config.locale_all = de_DE.utf8
[global]

Das heißt bei neuen sprachen muss man diese in die Daten­bank hinzu­fügen und im typos­cript etwas copy paste arbeit leisten. Viel schöner wäre es doch wenn eine exten­sion einem dieses typos­cript generiert. Im einfachsten fall würde man einfach alle Spalten vom sys_lan­guage record in Typos­crip­t-Kon­stanten kopie­ren. Dann gibt es an jeder Stelle so etwas:

Gutes Logging

Die Logging Situa­tion in TYPO3 ist … unvoll­stän­dig. Es gibt syslog, welches scheinbar nie verwendet wird, und es gibt den LogMa­na­ger. Der LogMa­nager scheint der aktuel­lere Weg zu sein aber kaum jemand verwendet diesen. Auch der core selbst loggt so gut wie nichts außer fehler und diese auch nur indirekt. Die Standard­kon­fi­gu­ra­tion ist ok, Warnungen werden in eine Datei geloggt und Plugin-Ex­cep­tions landen auch darin. Soweit so gut.

Was fehlt sind anstän­dige LogWri­ter. Es gibt keinen Email­Wri­ter, von fortge­schrit­tenden Writern in zB. Slack mal zu schwei­gen. Meine Idee wäre es hier einen ‘Mono­lo­gA­d­ap­ter­Wri­ter’ zu definie­ren. Das würde schlag­artig alle Adapter von Monolog freischalten.

Dann wäre da noch das Problem das extbase nichts loggt. Ich würde mir wünschen, dass Änderungen an extbase Objekten zumin­dest im Logger auftau­chen. Premium wäre natür­lich, wenn Änderungen durch extbase im ganz normalem history modul von TYPO3 auftau­chen würden aber ich hab da mal rein geguckt und das wird glaube ich nicht einfach.

Und da es sich um ein logger mit Gewich­tung handelt… warum nicht einfach alles mit debug loggen. TYPO3 hat Hooks und Signal-S­lots für so ziemlich alles. Plugin­auf­rufe, SQL anfragen etc.. Das könnte einem auch eine grobe Echtzeit­vor­stel­lung geben was TYPO3 eigent­lich die ganze zeit macht, wenn man eine Seite aufruft.

cHash utility

Der cHash Mecha­nismus von TYPO3 wirkt auf mich undurch­dacht. Also Parameter werden alle fürs Caching ignoriert solang es keinen cHash gibt. Ruft man also eine News-De­tail-Seite mit den nötigen Parame­tern auf ohne cHash funktio­niert dies und die Seite wird gecached. Wenn man die Parameter nun ändert passiert nichts da TYPO3 die Parame­ter-Än­de­rung ignoriert.

Ich sehe dort einige große Probleme. Wenn eine Seite kalt aufge­rufen wird, sind die Parameter relevant. Das kann große Debug-Pro­bleme hervor­ru­fen, die sich zwar schnell durch ein Cache löschen beheben lassen aber super nervig sind da man diese meist nicht repro­du­zieren kann. Zum anderen kann es erheb­liche Sicher­heits­pro­bleme geben. Sollte ein Parameter aus irgend einem Grund unescaped auf der Seite ausge­geben werden kann das Ergebnis gecached werden und andere Nutzer, die die Seite später aufru­fen, bekommen dann poten­ziell Scripte untergeschoben.

Folgendes will ich haben: Wenn kein cHash vorhanden ist müssen alle Parameter die nicht explizit aus dem cHash exclu­diert werden aus $_GET entfernt werden.

Was sich dann auch noch anbie­tet, ist einen canonical url utility. Im Endef­fekt will ich eine URL aus TSFE:cHash_array generieren können.

ProcedureCommandController

Häufig, wenn ich einen CommandCon­troller baue, ist dieser nicht einfach nur ein Command, sondern ein Impor­ter, E-Mail Versender etc. Diese Jobs will ich dann im Scheduler ausfüh­ren. Das Problem: es gibt dann keine Dokumen­ta­tion ob der Job gelaufen ist und auch die Ausgabe des Commands läuft ins Leere.

Meine Idee ist es einen spezi­ellen Proce­du­re­Com­mandCon­troller zu bauen welcher kein $this->output hat, sondern nur ein $this->logger. Dies ist dann ein psr Logger­In­ter­face. Dahinter würde ich dann einen spezi­ellen Logger bauen der mehrere Dinge tut.

Natür­lich muss das alles dann auch Fehler­to­le­rant werden und auch TYPO3 typische Vorge­hens­weisen wie exit() unter­stüt­zen. Diese Exten­sion hängt vermut­lich sehr stark mit dem logging zusammen.