Beiträge aus der Kategorie: TYPO3 CMS

Hashtag TYPO3Flag

Dank Oliver Klee bin ich nun stolzer Besitzer einer TYPO3-Flagge. Mit dem alten Logo!
Ich muss mir jetzt nur noch eine Wand freischaufeln, an der ich sie befestigen kann. Das wird eine Aufgabe werden, befindet sich doch mein Home-Office im Dachgeschoss, dessen Wände alle komplett verputzt sind. Ich glaube, ich werde rausgeschmissen, sollte ich die Flagge mit Reiszwecken oder ähnlichem befestigen wollen.

Nichtsdestotrotz möchte ich die Flagge nicht für immer behalten. Mir schwebt vor, dass die Flagge alle drei Monate zu einem weiteren TYPO3-Begeisterten wandert und ich die Reise hier festhalten werde (wenn der Empfänger damit einverstanden ist). Ich bin gespannt, ob überhaupt jemand Interesse an der Flagge und an der Idee hat. Ich schlage vor, dass sich auf allen Wegen bei mir gemeldet werden kann: als Kommentar in diesem Artikel, als Reply von diesem Mastodon-Tröt (ich mag dieses Wort überhaupt nicht) oder auch per E-Mail. Ich werde alles sammeln und Ende Januar den hoffentlich glücklichen Gewinner bekannt geben, der die Flagge Anfang April von mir zugeschickt bekommt (Adresse erfrage ich dann noch).

Ajax-Request über dedizierten Page-Type

Weil in diesem Internet so viele alte Seiten mit einem mittlerweile fehlerhaftem Beispiel herumgeistern, wie man über einen dedizierten Page-Type in TYPO3 Ajax-Requests behandelt und ich da heute im Rahmen eines Code-Refactorings auch wieder drüber gestolpert bin, möchte ich meinen Teil dazu beitragen mit der Annahme aufzuräumen, dass das damit verbundene PAGE-Objekt per config.no_cache = 1 misshandelt werden muss. Muss es nämlich nicht. Und sollte es auch nicht, denn wenn man mal in sein Log schaut, wird man ganz viele Warnings der Form "$TSFE->set_no_cache() was triggered. Reason: config.no_cache is set. Caching is disabled!" finden.

Und das wollen wir doch nicht. Es reicht vollkommen den Inhalt der Seite dann als COA_INT oder USER_INT zu integrieren. Denn diese Objekte werden definitiv nicht gecached!

ajaxPage = PAGE
ajaxPage {
    typeNum = 123456789
   
    config {
        disableAllHeaderCode = 1
        admPanel = 0
        debug = 0
    }
   
    10 = COA_INT
    10 < plugin.tx_extensionname_pluginname
}

Oder auch von mir aus auch mit

ajaxPage = PAGE
ajaxPage {
    typeNum = 123456789
    
    config {
        disableAllHeaderCode = 1
        admPanel = 0
        debug = 0
    }
   
    10 = USER_INT
    10 {
        userFunc = TYPO3\CMS\Extbase\Core\Bootstrap->run  
        extensionName = ExtensionName  
        pluginName = PluginName  
        vendorName = VendorName  
        controller = ControllerName  
        action = ajax  
    }
}

TYPO3-Backend anpassen in fünf Minuten

In der Entscheidungsphase zur Wahl eines Content Management Systems hört man zu TYPO3 oft, dass das Backend für den Redakteur nicht intuitiv und viel zu überladen ist. Dass es zu viele Optionen und Felder gibt, die man beim Erstellen von Inhalten gar nicht verwenden würde und zu einer Überforderung der Redakteure führen.

Auch habe ich schon viele Backends gesehen, in denen für die Redakteure das Backend nicht angepasst oder sogar gar keine Benutzergruppen mit entsprechenden Rollen verwendet wurden. Und somit alle Benutzer mit Adminstrationsrechten im Backend unterwegs waren.

Das hat in meinen Augen mit der steilen Lernkurve von TYPO3 zu tun, die dem Anfänger entsprechende Steine in den Weg legt. Wenn man aber das Konzept der Konfiguration von TYPO3 verstanden hat, stehen einem alle Türen offen, das Backend so einfach wie möglich zu gestalten. Und zwar lediglich mit den Feldern und Optionen, die man zum Erstellen von Inhalten benötigt.

Um das zu erreichen gibt es einen ziemlich einfachen Weg: das Ausblenden von Feldern mittels TCEFORM, dem Setzen von Default-Werten für Felder mit TCAdefault und dem konsequenten Einsatz von Benutzergruppen. Administratoren sind wirklich nur Administratoren und nicht für das Erstellen von Content zu verwenden. Bei einem ordentlich aufgesetzten TYPO3 sollte man sich also eigentlich nie mit einem Administrator-Account anmelden müssen. ;-)

Weiterlesen

Remote Pair Programming

Video-Calls. Wer kennt sie nicht. Mal abgesehen von Team-Meetings, Stand-Ups und so weiter, muss man diese Kommunikationsform verwenden, wenn man mit seinen Kollegen im Home-Office zusammen ein Problem lösen möchte. Dann teilt einer am besten noch seinen Bildschirm mit der IDE und alle schauen zu, wie dort nach der richtigen Stelle in der Datei gesucht wird und dann mit etlichen Vertippern der zugerufene Code angepasst wird.

So ging es mir auch heute, wobei ich mich dann auch während des Meetings dauernd dabei erwischt habe, auf dem geteilten Bildschirm scrollen zu wollen. Aber dabei gibt es mit Tool wie "Code with me" innerhalb von PhpStorm eine hervorragende Lösung für dieses Problem. Ich hatte mir vor zwei (?) Jahren, als die erste Version des Tools erschienen ist, das ganze zwar schon mal angeschaut, aber damals stand das noch auf wackeligen Beinen und war nicht sonderlich performant.

Das heutige Meeting habe ich aber zum Anlass genommen und mir "Code with me" eben erneut angeschaut und ausprobiert. Und: es funktioniert einwandfrei. Und vor allem einfach. Der, der das Problem hat, stellt den Host und kann in PhpStorm in einem einfach gehaltenen Dialog einen Einladungslink generieren. In einer anderen Instanz kann man diesen Link dann entsprechend aufrufen oder im PhpStorm-Plugin eingeben und schon wird die Instanz gespiegelt. Und je nach den Berechtigungen können mehrere Leute dann direkt im Code zusammen arbeiten.

Ich habe keine Ahnung, warum ich das bisher einfach nicht genutzt habe.

Bloggen mit TYPO3

Vergleiche zwischen Content Management Systemen gibt es wie Sand am Meer, da möchte ich jetzt keinen weiteren aufstellen. Vor allem, weil ich es schwer finde, ohne ein bestimmtes Problem eine ansprechende Gegenüberstellung zu erstellen.

Von daher nehmen wir an, dass wir schon eine TYPO3-Installation haben und der Wunsch entstanden ist, in einer Seite auch ein Blog zu integrieren. Vereinfachend und um es besser nachvollziehen zu können, verwendet diese Installation bk2k/bootstrap-package mit einer eigenen Template-Extension (wo kommt eigentlich der Begriff SitePackage her? In der ext_emconf gibt es doch "template" im Parameter "category"?).

Nach der Installation der Blog-Extension der TYPO3 GmbH folgt man einfach dem Setup-Wizard aus der Dokumentation integriert durch ein bißchen TypoScript und TsConfig das Ganze in seiner Template-Extension. Das alles dauert nicht mehr als eine Viertelstunde, wenn man ein wenig firm mit dem Backend ist. Und ist auch nicht schlimmer als die Installation und Konfiguration einer anderen Blogsoftware.

Man bekommt danach eine Seitenstruktur, in der man sich austoben kann. In der man wie man es mit TYPO3 gewohnt ist, Seiten und deren Inhalte bearbeiten kann. Inhalte, die man auch mehrsprachig verwenden kann, eine Instanz, in der man neben diesem Blog auch weitere Seiten/Domains mit ganz anderen Inhalten pflegen kann. Mit ganz vielen anderen Usern zusammen, wenn man möchte. Aus dem Fundus von tausend anderen Extensions schöpfen kann, um seine Inhalte aufzubereiten und zu präsentieren.

Klar, vielleicht bin ich voreingenommen, da ich seit anderthalb Jahrzehnten mit diesem System arbeite, aber ich weiß nicht, was daran schwer sein soll, sich per composer TYPO3, von mir aus das bootstrap-package und die Blog-Extension zu installieren, um dann per Assistent sich die Seitenstruktur erstellen zu lassen. Eine WordPress-Installation dauert genauso lang und stellt mir erstmal auch nicht mehr Funktionen zur Verfügung. Klar, sobald ich mir dann irgendwoher ein Theme mit so einem Seiteneditor reingeklickt habe, was zugegeben wirklich jeder technisch Unbedarfte schafft, hat WordPress vielleicht seine Vorteile was die Gestaltung angeht. Sieht man ja auch an dieser Seite (bin halt kein Pixelschubser ;-) ).

Und jetzt habe ich doch noch einen Vergleich reingebracht...

Erste Hilfe für Open Source

Alexander Kellner hat die provokante These in den Raum geworfen, dass Open Source kaputt sei und aufgefordert, an der Reparatur mitzuwirken. Dies ist bestimmt überspitzt gemeint und bezieht sich im Artikel dann in erster Linie auf die Wahrnehmung, aber vor allem auf die Wertschätzung von Open Source.

Open Source lebt nicht allein von der Verbreitung, sondern von der aktiven Unterstützung durch deren Nutzer. Diese kann auf verschiedenen Ebenen passieren: manch einer ist in der Lage selber Code beizusteuern, andere verbessern die Dokumentation und wiederum andere können das Projekt finanziell unterstützen. Denn Entwicklung kostet Zeit. Zeit, die die Entwickler nicht mit ihrer regulären Beschäftigung zum Geld verdienen nutzen können oder von ihrer Freizeit abziehen müssen.

Alex´ Idee ist es mit Blick auf TYPO3 und der großen Vielfalt der Extensions, dass die Association eine zentrale Funktion für die Verteilung von Spenden einnehmen könnte. So eine Art Patreon/Steady für Community-Extensions. Es gibt ja selbst auf GitHub die Möglichkeit über das Sponsoring einzelnen Entwicklern etwas in den Topf zu werfen, was ich auch ein wenig mache.

Ich habe mir vor ein paar Jahren einen gewissen Rahmen gesetzt, den ich pro Jahr in Form von Spenden entbehren kann. Der größte Teil geht in Form von Fördermitgliedschaften bei so Projekten wie Sea-Watch oder der Gesellschaft für Freiheitsrechte drauf. Eine Bronze-Mitgliedschaft in der TYPO3 Association finde ich auch bezahlbar. Aber ich unterstütze auch über Plattformen wie Patreon/Steady/GitHub Sponsoring Entwickler und Podcaster, die sonst über keine anderen Wege für ihre Projekte an Geld kommen.

Aber ich muss bis jetzt über mehrere Kanäle schauen, dass mein Geldkontingent "klug" verteilt ist und ich ändere auch alle paar Monate meine Unterstützungen, um das Ganze breiter zu streuen. Einen zentralen Pool für TYPO3 und all seiner Extensions würde ich also begrüßen. 

Und ich habe vor auch auf anderen Wegen meinen Obolus beizutragen. Und mich erkenntlich für all das zu zeigen, was mir andere Entwickler möglich gemacht haben. Danke schon mal dafür!

AusgeFLoCkt

Ich habe noch keine Nachricht der ganzen Browser neben Chrome gesehen, die Googles Cookie-“Ersatz” FLoC zum Tracken des Userverhaltens integrieren wollen. Aber nur um auch wirklich sicherzugehen, dass die eigene Website bei der ganzen Sache nicht mitmacht, sollte man per Permissions-Policy das ganze unterbinden. Da es zur Zeit nur den OptOut mittels des HTTP Response Headers gibt, muss man entweder direkt über die Serverkonfiguration, der htaccess-Datei oder dem Setzen der Header mittels TypoScript dem Ganzen einen Riegel vorschieben:

config {
    additionalHeaders {
		10.header = Permissions-Policy: interest-cohort=()
    }
}

Die Reihenfolge im additionalHeaders-Array natürlich bitte anpassen, ich gehe doch davon aus, dass da noch ein paar weitere Header wie Content-Security-Policy usw. gesetzt sind.

Alles muss raus

Im letzten Jahr, das man nicht beim Namen nennen darf, hatte ich so viel vor und echt mal wenig davon geschafft. Irgendetwas mache ich nämlich falsch (oder anders) als alle anderen, die auch im HomeOffice waren und gefühlt dauernd Freizeit hatten oder wenigstens sowas von tiefenentspannt waren, dass ich im Spätsommer mit Meditation angefangen habe, um auf das gleiche Level zu kommen. Das mit der Meditation habe ich dann schnell wieder verworfen, das klappt bei mir einfach nicht. Da muss man scheinbar genauso wie bei Homöopathie dran glauben und dafür ist mein Gehirn einfach nicht gemacht.

Zum Bloggen bin ich dann nämlich auch nicht gekommen, wie ich mir das so vorgenommen hatte. Einfach mal Texte schreiben. Für mich. Und die ins Internet stellen. Warum auch immer. Weil man das im frühen Internet auch so gemacht hat. Wo das Internet noch nicht ganz so kaputt war wie heute.

Vielleicht werde ich sogar demnächst hier eine Blogroll veröffentlichen, denn es gibt sie immer noch! Die kleine Blogosphäre und auch die Tech-Blogger. Anfangen werde ich aber mit einer Auswahl von Artikeln und Websites, die ich im letzten Jahr in Pocket abgespeichert und mit Vergessen gestraft habe. Von den knapp 300 Einträgen habe ich diese mal hier gelassen, vielleicht findet der ein oder andere ja noch was, was ihn weiterbringt.

Webdesign

TYPO3

DevOps

PHP

Programmierung allgemein

Surf mal anders

Update: Mit Erscheinen von TYPO3 10.4.8 hat sich das Problem erledigt, da hier die Dependencies angepasst wurden. Scheinbar gab es nicht nur mit Surf, sondern auch mit Solr und Abhängigkeiten zu PHP 7.2 Probleme. Ich werde trotzdem Surf nicht mehr per composer in das Projekt installieren, sondern global in den DDEV-Container.

Gestern wurde ein geplantes Maintenance-Release von TYPO3 veröffentlicht. Version 10.4.7. Vom besten Content Management System, das ich kenne. Und natürlich sollten gleich alle Projekte auf die neue Version gezogen werden. Was bisher ohne Probleme mit einem herzhaften 'composer update' auch ohne weitere Anstrengung möglich war. Nur gestern nicht.

composer weigerte sich partout die neue Version in die Projekte zu integrieren. Gut, kein Problem, gehen wir das Ganze mal systematisch an. Erstmal mittels

composer clear-cache && composer update

composer zwingen, alles zu vergessen, die ganzen Quellen abzugrasen und es erneut zu versuchen. Dies brachte aber auch kein neues TYPO3 auf die Festplatte.

Dann wollte ich mal schauen und mit der Frage

composer why-not typo3/cms-core:10.4.7

kristallisierte sich dann auch heraus, dass typo3/surf eine Dependency über symfony/console enthielt, die dann schlussendlich eine Dependency auf symfony/event-dispatcher-contracts hatte, die verhinderte auf eine Version größer 2.0 zu gehen. Was aber typo3/cms-core unbedingt voraussetzt. npm, ick hör dir trapsen!

Heute morgen dann nochmal versucht, selber eine Lösung zu finden, aber vielleicht sollte ich doch im gehobenen Alter über eine Umschulung nachdenken. Somit blieb nur noch Twitter übrig, mein Leid geklagt und Minuten später, kamen schon die beiden Retter @t3easy_de und @chriwode um die Ecke. 

Der erste Versuch, Surf lokal auf einem Windows laufen zu lassen, scheiterte kläglich. Ja, Windows. Möchte ich hier nicht drüber reden. Das Ganze scheitert daran, dass unter anderem Windows awk nicht kennt und selbst wenn man dieses nachinstalliert, werden einem weitere Fehler um die Ohren gehauen.

Um jetzt mal so langsam auf den Punkt zu kommen: bisher habe ich Projekte mittels DDEV aufgesetzt und per composer nicht nur TYPO3 und die verwendeten Extensions installiert, sondern auch Surf. Um dann zum Beispiel per Kommandozeile ein Projekt deployen zu können, wenn kein entsprechendes CI/CD-System zur Verfügung steht. Meine Lösung sieht jetzt so aus, dass Surf aus diesem composer.json rausgeflogen ist und global per DDEV Start-Hook installiert wird:

hooks:
  post-start:
  - exec: composer global require hirak/prestissimo
  - exec: composer global require typo3/surf:^2.0

So lässt sich TYPO3 10.4.7 installieren und ich kann per Surf das Projekt auf ein anderes System schieben.

Geschwindigkeit ist alles

Es gibt ja für alles Untersuchungen. Auch dafür, wie sich die Ladezeit einer Website auf die mögliche Absprungrate der Besucher auswirkt. Und man mag es kaum glauben, aber die Erkenntnis ist, dass je länger eine Website zum Laden benötigt, desto höher ist die Chance, dass der Besucher den Tab schließt. Unglaublich.

Man sollte also alles daran setzen, dass eine Website so schnell wie möglich ausgeliefert und vor allem angezeigt wird. Mal abgesehen, dass man dafür sorgen sollte, dass Elemente im sichtbaren Bereich zuerst gerendert werden und schon gar nicht während des Ladens hin- und herflippen sollten, ist ein weiterer Faktor, den man ganz gut beeinflussen kann, die Anzahl und vor allem die Größe der Ressourcen wie Stylesheets und JavaScript so gering wie möglich zu halten.

Mit TYPO3 10.3 ist hierfür der AssetCollector integriert worden. Mit diesem können Skripte und Stylesheets in Fluid-Dateien mit den Viewhelpern f:asset.script und f:asset.css dem Renderingprozess hinzugefügt werden. Und das ähnlich dem schon in 8.6 hinzugefügten renderAssetsForRequest, mit dem man über die beiden Fluid-Sections HeaderAssets und FooterAssets entsprechenden Code rausrendern konnte.

Der entscheidende Unterschied ist, dass, wie der Name schon vermuten lässt, der AssetCollector die Stylesheets und Skripte erstmal sammelt und dann nur einmal im Rendering inkludiert. Heißt, ich kann in diversen Fluid-Dateien mit dem gleichen Namen auf die gleiche JavaScript-Datei referenzieren, die ich zum Beispiel für einen Slider benötige, die dann aber am Ende des Dokuments nur einmal per Script-Tag im Dokument hinterlegt wird.

Ein weiterer Vorteil ist, dass man auf diese Art und Weise dafür sorgen kann, dass nur benötigte Ressourcen an den Browser gesendet werden und nicht ein JavaScript-Plugin für ein Akkordeon, welches gar nicht auf der Seite vorhanden ist. Natürlich hebelt das ein wenig das Konzept aus, dass man eigentlich immer die gleichen Ressourcen an den Browser sendet, damit dieser diese auf der zweiten Seite gar nicht mehr anfordert, weil er sie dann aus seinem Cache nimmt.

Aber mit der gleichzeitigen Verwendung von HTTP/2, das dafür sorgt, dass die Ressourcen zum Rendern der Website an den Browser ausgeliefert werden, bevor dieser überhaupt weiß, dass er sie benötigt, wird in Verbindung mit der geringen Datengröße trotzdem ein Geschwindigkeitsvorteil erzielt, der sich vor allem in einem schnelleren Rendering der Seite bemerkbar macht. Dabei ist es gar nicht schlimm, dass die Ressourcen nicht im Concatenate- oder Komprimierungs-Prozess von TYPO3 integriert werden, wie man das ja bisher gewohnt war, wenn man seine Ressourcen mittels TypoScript eingebunden hat.

Und schon hat man wieder ein paar mehr Besucher seiner Website glücklicher gemacht.
Und ja, ich weiß, hier auf der Seite habe ich leider noch kein HTTP/2 aktiviert. Liegt nicht an mir. Tut mir leid.