04. Juni 2014

TYPO3 6.?

in TYPO3

Mit dem Erscheinen der LTS-Version 6.2 wurden wichtige und große Schritte gemacht, damit TYPO3 konkurrenzfähig bleibt. Nach den ersten erfolgreichen Einsätzen der neuen Version stellt sich mir die Frage, welche Schritte für die weitere Entwicklung sinnvoll sein könnten. Ich möchte deshalb einige Anregungen aus meinem TYPO3-Alltag von mir teilen und bin sehr interessiert daran, von Euch zu hören, welche Punkte Ihr gerne auf der Roadmap sehen würdet.

Core oder Extension?

Einige der Punkte auf der Liste lassen sich bereits mit Extensions lösen. Diese Tatsache demonstriert einerseits eindrucksvoll die Möglichkeit zur Erweiterung von TYPO3, andererseits aber auch die Notwendigkeit, zum Teil grundlegende Funktionalitäten zu ergänzen, die vom Core offensichtlich nicht zufriedenstellend abgedeckt werden.

Definition von Contentelementen

Besonders deutlich wird dies am Themenkomplex „eigene Contentelemente“, der mich während der Erstellung dutzender TYPO3-getriebener Internetauftritte immer wieder in TER („Welche Extension kann das?“), Dokumentation („Kann der Core das vielleicht doch?“) und oft auch fast in die Verzweiflung getrieben hat („Wie kann es sein, dass so eine einfache Aufgabe so kompliziert ist?“). Nach teils langjähriger Benutzung habe ich letztlich der Verwendung von Extensions, die mit dieser Aufgabe mehr oder weniger zu tun haben (z.B. Fluid Content, TemplaVoila, Multicontent, DCE, GridElements usw.) abgeschworen, obwohl Sie ihre jeweiligen Aufgaben bestens erfüllen.

Wichtigster Grund dafür: Jede dieser Extensions kocht ihre eigene Suppe. So verwenden viele der Extensions z.B. FlexForm-Felder, was die die TYPO3-Instanz so recht abhängig von der verwendeten Extension macht und aus meiner Sicht eher ein Feigenblatt ist für eine unflexible Datenstruktur der Contents (tt_content). Gleichzeitig wird ein eigenes Bedienkonzept für eine (wenn nicht die) zentrale Aufgabe eines CMS eingeführt, was nicht im Sinne der Erfinder sein sollte.

Ich möchte Contentelemente

  • ohne die Verwendung von Erweiterungen
  • vollständig (Darstellung in BE und FE)
  • dateibasiert (erleichtert die Versionskontrolle)
  • mit Fluid (Templates) und Extbase (Contentmodel)
  • mit einer standardisierten Datenstruktur
  • ohne programmieren zu müssen
  • ohne Umbiegen der Corefunktionen (z.B. für Sprachoverlays)

definieren können. Seit einiger Zeit definiere ich dazu alle verwendeten Contentelement in einer eigenen Extension, die nichts weiter als eine komfortable Ansteuerung der Core-Funktionen ermöglicht; ich finde, das sollte der Core mitbringen und auch als Standard vorgeben.

Steuerung der HTML-Ausgabe

Ausgerechnet beim Rendern ist TYPO3 – im Gegensatz zu seiner sonstigen Flexibilität – recht stur. Für eine saubere HTML5-Ausgabe braucht es meiner Erfahrung nach einiges Know-How und mindestens eine Extension. Im Quellcode vieler TYPO3 Websites (darunter auch Referenzseiten) finden sich Artefakte unsauberer Ausgaben, z.B.

  • QueryString nicht im Dateinamen eingebettet
  • Redundante Attribute von script- und style-Tags in HTML5 Dokumenten
  • Etliche Leerzeilen und -zeichen
  • CSC-Kommentare
  • Unbenutzte CSC-Styles
  • Generator Metatag

All dies lässt sich mit dem nötigen Wissen ändern. Da dies aber Mehraufwand und -wissen erfordert, suggerieren meiner Meinung nach solche Seiten, das TYPO3 keine vollständige Kontrolle über die Ausgabe ermöglicht. Eine Seitenausgabe, die standardmäßig komplett in Fluid erzeugt wird, könnte hier effektiv vorbeugen.

Die Rolle von TypoScript

CSS Styled Content (CSC) ist das Standardwerkzeug zur Ausgabe von Contentelementen und bietet eine breite Palette von Standardelementen in vielen Variationen an. Wer Änderungen an der Ausgabe vornehmen will, braucht ein gutes Verständnis von TypoScript. Überschreibt man das TypoScript Setup vieler Elemente, wird es schnell unübersichtlich, da das Original-TS (aus dem statischen CSC-Template) getrennt von den Modifikationen liegt. TypoScript ermöglicht oft eine sehr kurze Schreibweise komplexer Template-Logiken, ist aber ab einer gewissen Verschachtelungs- und Referenzierungskomplexität nicht mehr leicht zu lesen.

Ich selbst setze Templates am liebsten mit Fluid um – HTML-Code einkopieren, ViewHelper einsetzen und fertig ist ein les- und pflegbares Template.

Trotzdem bleibt TypoScript für viele Aufgaben das Mittel der Wahl – so kann ich mir z.B. kaum eine kürzere Definition komplexer Menüs vorstellen. Mein Vorschlag: TypoScript für die Beschaffung von Daten verwenden und eine Schnittstelle schaffen, mit der die Ausgabe im Fluid-Template erfolgen kann.

Onward

Das war es von meiner Seite – ich bin gespannt auf Eure Beiträge!

Dies ist ein Gast-Beitrag von Rainer Becker.

21 Reaktionen zu “TYPO3 6.?”

Kommentare abonnieren (RSS) oder TrackBack URL

Du listest „Generator Metatag“ als negativen Punkt. Was ist der Hintergedanke?

Markus Klein am 04. Juni 2014 um 21:24

Der Tag gibt unnötigerweise die TYPO3-Versionsnummer (z.B. 4.5) preis, was beim Ausnutzen von Sicherheitslücken behilflich sein könnte, wenn die Version veraltet ist. Ist (wie auch die überflüssigen Script- und Style-Attribute) sicher nichts Gravierendes – ich finde aber den vorgeschriebenen TYPO3-Kommentar im Quellcode völlig ausreichend als Bekenntnis zu TYPO3 (übrigens sind einige TYPO3-Agenturen selbst dazu nicht bereit). Für mich ist die Kontrolle des Outputs (mit Bordmitteln, ohne Funktionsverlust) ein wichtiges Qualitätsmerkmal für ein CMS dieses Kalibers.

Rainer Becker am 04. Juni 2014 um 22:06

Kann ich alles so unterschreiben. Setze mittlerweile auch andere CMS ein, weil der Umstand fehlender FCE unerträglich ist.

Bernd am 04. Juni 2014 um 22:41

Ich kann deine Punkte nicht so ganz nachvollziehen. Es steht dir doch frei, mit 10 TS Zeilen die gesammte Frontend-Ausgabe in eine FLUIDTEMPLATE umzuleiten. CSC ist optional und kann doch komplett ersetzt werden.

Was evtl. noch fehlt, ist dein COA als Array, statt als String an FLUIDTEMPLATE weiterzugeben, dies ist aber auch alles. Das Selber gilt für CONTENT, RECORD und HMENU/TMENU.

FCEs ist ein Thema für sich. Da ist das Core Team auch dran, jedoch hat jede der möglichen Lösungen so seine Nachteile: Speed, DB Rechte oder Einfachheit des Anlegens: XML, Property-Tabellen, Extbase Models, Fully-Normalized, etc.
Dies im Core festzulegen bedeutet einen deutlichen Tradeoff hinzunehmen. Im Moment ist die Ansage halt: Extensions (DCE, Gridelements, TV), Kickstarter oder Extension Builder.
Es gibt hier keinen guten Default. Drupal hat genau das gleiche Problem (Speed, DB Rechte).

Philipp Gampe am 04. Juni 2014 um 23:46

Glaube nicht, dass in der gewünschten Richtung noch etwas kommen wird. Schließlich ist es in den letzten 10 Jahren oder so nicht gelöst worden, warum sollte jetzt, wo langfristig der schleichende Umstieg zu NEOS erfolgen soll, noch so etwas kommen.

Boris Becker am 05. Juni 2014 um 01:21

Hallo,

zum Thema Generator-Tag möchte ich mich gern als Mitglied des TYPO3 Security Teams äußern: Man braucht nicht diesen Tag um zu wissen welche Version installiert ist und automatisierte Angriffe schauen auch nicht zuerst nach was da für eine Version installiert sein mag sondern starten einfach blind los. Daher gibt es auch auf TYPO3-Seiten-Angriffspatterns die nur auf Joomla passen und sicherlich auch umgekehrt.

Zum anderen Thema: Natürlich kann man vieles besser machen und ja FCE fehlt im Core, ist halt einfach nicht trivial. Genau daher gibt es aber ja auch Extensions, die hier ohne Problem zB 50% oder 80% des kompletten Features abdecken das für die meisten auch sicherlich ausreichend sein mag.

@ Boris Becker: Es passiert immer dann was wenn es sich konkret wer darum annimmt. Das muss auch niemand aus dem Core-Team sein.

Georg Ringer am 05. Juni 2014 um 05:59

@Georg: Der Generator-Tag ist für sich genommen nicht gravierend (s. meine Antwort oben), in der Summe mit anderen HTML-Unsauberheiten aber ein möglicher Grund dafür, dass man sich als TYPO3-Laie beim Studieren der Quelltexte von TYPO3-Seiten fragen könnte, ob man mit diesem CMS wohl auch absolut sauberen HTML-Code generieren kann. Für mich als Entwickler kein Problem, ich weiß, wie man das trotzdem hinbekommt – für das Produkt ist es aber schädlich, wenn nicht von Haus aus die Generierung von blitzsauberem Code gefördert wird, wo es nur geht.
Warum ich beim Punkt FCE kein Freund von Extensions bin, habe ich im Artikel ja beschrieben – und wenn viele andere Entwickler der gleichen Meinung sind, dann sollten wir zusammen überlegen, was man wie verbessern könnte.

Rainer Becker am 05. Juni 2014 um 09:45

Also ich bin mit backend_layouts und gridelements bestens bedient. ich sehe da keinen Handlungsbedarf. Stört mich auch nicht, das gridelements keine Core Ext ist.

Pat am 05. Juni 2014 um 15:42

@Pat: Ab Oktober werden nur noch TYPO3 Versionen > 6.2 supported; bis heute gibt es dafür noch keine Grid Elements Version im TER. Stört Dich das wirklich nicht? Du bekommst alle Deine GridElements-Kundenauftritte in der kurzen Zeit noch migriert? Ich wäre da skeptisch.

Rainer Becker am 05. Juni 2014 um 15:50

diese flexiblen CE waren schon beim T3cRR 2013 ein großes Thema.
damals kamen gerade einige neue Extensions für neue CEs ins TER.
Thematisiert hab ich das auch noch früher in http://forum.typo3.org/index.php?t=msg&th=199604&goto=696144&#msg_696144

Auf dem Gridelements/Themes-Codesprint Anfang Nov. war auch ein Ansatz für ext:themes die bestehenden Felder aus tt_content aktiver zu nutzen als alles in pi_flexform zu verpacken.

Vielleicht kommt ein Umdenken, weg von pi_flexform, wenn die Tools vorhanden sind mit einfachen (Fluid-)Templates, sowohl individuelle BE-CEs zu konfigurieren (TCA für neue CTypes), als auch diese CEs einfach im FE auszugeben. Momentan ist die einfachste Möglichkeit eben pi_flexform zu nutzen und so steigen viele auf dieses Pferd.

Bernd Wilke am 05. Juni 2014 um 15:51

Die Altsysteme fallen nicht plötzlich tot um nur weil der Support ausläuft. Die meisten Installationen erfahren sowieso nie ein Update, wenn man mal ehrlich ist.

etgfj am 05. Juni 2014 um 17:07

Auch, wenn es in diesem Post etwas off-topic ist, aber dass GridElements immer noch nicht für 6.2.99 im TER ist, finde ich extrem ärgerlich, bzw. schädlich für das Ansehen von TYPO3.

Klar, man kann sich das in github besorgen oder das in der ext_emconf umstellen. Aber das weiß zum einen nicht jeder und ob das wirklich bugfrei funktioniert, lasse ich mal dahin gestellt.

Dass eine solche Extension nicht pünktlich zum Release von 6.2.0 raus kommt … Schwamm drüber. Dass der Entwickler eventuell Budget braucht, auch verständlich, nur dann muss man es entsprechend kommunizieren … ich würde das auch wieder mit ein paar Mäusen sponsern.

Aber eine Extension erst von der Community finanzieren zu lassen (was ich gut finde!), das Projekt dann so aufzustellen, dass man sich als Entwickler darauf verlässt und bis jetzt immer noch keine Version für 6.2 im TER zu haben … unschön.

Wobei ich auch hinterher schieben möchte, dass ich es toll finde, dass es GridElements gibt – ich finde diese Extension richtig gut. Aber man darf die User dann nicht so hängen lassen.

Meine Meinung. :o)

Marc Fell am 05. Juni 2014 um 17:15

Ich kann mich der Meinung von Rainer nur anschließen.
FCE ist immer noch ein Knackpunkt. Ich persönlich löse es auch noch lieber in einer eigenen Extension. Bei dieser werden die eigenen Inhaltselemente manuell mittels nativen TYPO3-Boardmittel erstellt. Ich finde, dass ich so bei überschaubaren Aufwand, alles gut kontrollieren kann.
Von den alternativen finde ich aber bisher die Lösung von „Fluid Powered TYPO“ noch am interessantesten. Ich könnte mir vorstellen, dass in Zukunft mal im kleinen Rahmen auszuprobieren.

David am 05. Juni 2014 um 17:25

… oder den guten alten Extension Kickstarter für 6.2, der einfach nur pages und tt_content erweitert – das würde ich auch praktisch finden.

Wobei mir der Aufwand nicht klar ist, den Kickstarter für 6.2 zur Verfügung zu stellen.

Marc Fell am 05. Juni 2014 um 17:35

Dein Artikel spricht mir aus der Seele: Einige wichtige Funktionen wünsche ich mir längst schon im Core: realurl z.B. – andere CMS können das von Haus aus und bieten – wie Drupal – auch Möglichkeiten, die URLs per Pattern zu steuern, auf Wunsch aber ganz individuell einzutragen. WordPress und Contao sind für einfache Fälle hier auch gut zu benutzen.
FCEs sind in Drupal kein Thema. Über eine interaktive Oberfläche lassen sich individuelle Inhaltstypen erstellen (per Modulprogrammierung natürlich genauso). Mit dem Modul Views werden individuelle Abfragen und Filter zusammengestellt. Views ist ab Drupal 8 übigens Teil des Core.
So gerne ich mit TYPO3 arbeite, wenn es um eine klassische Unternehmenswebsite mmit Baumstruktur geht: andere CMS-Mütter haben auch hübsche Töchter.

Susannna Künzl am 05. Juni 2014 um 17:44

Zu der CE Problematik… in den kommenden Tagen werde ichden AutoLoader veröffentlichen, welcher eine weitere Art darstellt schnell Inhaltselement auf Basis von Modellen und tt_content zu bauen. Seit gespannt…

Tim Lochmüller am 05. Juni 2014 um 17:58

@Rainer Becker
Ich hab diverse 6.2.3 Versionen mit Gridelements am laufen. Die Gridelements für 6.2 gibts auf GitHub

Pat am 06. Juni 2014 um 22:08

Das Problem mit den eigenen content Elementen habe ich auch ziemlich oft. Eine Lösung von TYPO3 Seite wäre echt top. Bis dahin greife ich aber auf Gridelements und content_designer zurück.

Hendrik am 11. Juni 2014 um 09:23

Bzgl. Definition von Contentelementen:
Alles was Du willst kann Mask – außer dass es auch eine Extension ist 😉 Aber vielleicht schaffen wir es ja auch mal in den Core!
Mask generiert TCA und SQL für neue CEs. Inhalte werden nicht in Flexform gespeichert. Ein Erstellassistent im Backend ermöglicht einfach und schnell neue (auch komplexe) CEs anzulegen. Und es werden gängige TYPO3 Funktionen wie Fluid, TCA, IRRE, Backend-Layout, usw. genutzt.

Noch suchen wir Unterstützer um die Erweiterung fertig zu bekommen:
http://www.startnext.de/mask

Bitte helft uns und werdet bis 10. Juli 2014 Fans und Supporter 🙂
Weitere Infos findet Ihr hier: http://www.typo3experten.com/programmierung/mask.html
Es folgt demnächst ein neues Video von der ersten Live-Präsentation in Wien. Hier wird gezeigt wie weit Mask schon ist, was es kann, und wie man es verwendet. Alle Fans werden automatisch über das Video informiert wenn es erscheint.

Liebe Grüße
Gernot Ploiner

Gernot Ploiner am 14. Juni 2014 um 14:44

@Gernot: Gute Sache, die mir in TYPO3 sehr helfen würde und ich auch gerne unterstütze.

Aber ich lese hier grade zum ersten mal von diesem Projekt und der Bitte, Euch zu unterstützen. Schmeist das doch mal in alle entsprechenden Foren und lasst die Info auf den Barcamps kreisen … ich glaube, dass die Werbetrommel da noch mehr getrommelt werden sollte.

Marc Fell am 14. Juni 2014 um 18:05

Alles als Extension. TYPO3 Grundfunktionen komplett und sauber nutzen. Aufgaben der Bereiche (TS, Fluid etc. definieren). Alle Templates mit FLUID (in Extensions).

Jonas am 18. Juni 2014 um 13:31

Kategorien

Archiv