chriwode

[chriwode]

Die eigene TYPO3 Extension integrieren

Teil 5 - Nachdem wir nun die wichtigsten Einstellungen in PhpStorm vorgenommen haben, wird es Zeit unsere eigene Extenion zu integrieren.

Spätestens an dieser Stelle kommt für mich auch Git ins Spiel, welches unbedingt gebraucht wird. Mit Git könnt ihr jegliche Art von Dokumenten und Inhalt, in unserem Fall Code versionieren. Wer jetzt denkt „Ich entwickle ja allein, das brauch ich nicht“, dem sei gesagt, doch du brauchst Git.

Das Projekt im Git-Repository

Wie eingangs schon erwähnt ist es an der Zeit den Code in einem beliebigen Git-Repository zu speichern. Ich selbst habe mich vor einiger Zeit dazu entschlossen die Kunden-Distribition direkt im Projekt-Repository und nicht in einem separten Repository abzulegen.

Auf die lokale Installation von Git möchte ich an dieser Stelle verzichten und auf die Website von Git verweisen. Eure Repositories könnt ihr z.B. bei den Anbietern GitHub, BitBucket oder GitLab sogar kostenfrei speichern. Damit spart ihr euch zum einen die Installation eines Git-Servers und deren Wartung, zum anderen sind eure Repositories von überall aus für euch erreichbar.

Der Vorteil eines Git-Repository sollte eigentlich klar sein, dennoch möchte ich kurz die Vorteile benennen:

Versionierung des Codes möglich

Zentrale Anlaufstelle

Arbeiten im Team am gleichen Code möglich

Durch PullRequests (PR) können andere den Code überprüfen, testen und ggf. korrekturen vornehmen

Nachvollziehen von Codeänderungen

.... und viele mehr

Wir speichern in dem Git-Repository nun nicht nur die Kunden Distribution, sondern das gesamte Projekt mit all seinen Abhängigkeiten. Somit kann ein Projekt schnell und einfach von neuen Kollegen aufgesetzt werden, wofür es grob nur 3 Schritte benötigt:

Projekt aus Git auschecken

composer install ausführen

Datenbank einspielen

Git initialisieren

Das Projekt muss nun mit Git auf eurem lokalen Rechner initialisiert werden. Dazu öffnet ihr in PhpStorm den "Terminal", welcher beim öffnen sich bereit in eurem Projektverzeichnis befindet. Nun tippt ihr den einfachen Befehl git init ein, woraufhin ihr die Rückmeldung Initialized empty Git repository ... erhaltet.

Git Index befüllen

Nun noch den Befehl git add ., wodurch alle Dateien und Verzeichnis (sofern nicht in der .gitignore enthalten) in den Index von Git aufgenommen werden. In PhpStorm sollten sich eure Datein nun entsprechend Grün färben. Mit dem Befehl git commit -m "Initial commit" werden nun alle Änderungen vermerkt, die Grünfärbung eurer Dateien verschwindet wieder. Bei Änderungen an Dateien, werden diese zukünftig blau gefärbt.

Projekt ins Git-Repository pushen

Jetzt müssen wir unserem lokalen Git nur noch mitteilen wo sich der Git-Server befindet und setzen einen entsprechenden Remote, z.B. zu GitHub: git remote add origin https://github.com/user/repo.git

Die URL in dem Befehl müsst ihr entsprechend anpassen. Infos dazu findet ihr bei eurem Git-Hoster.

Nun können wir mittels des Befehls git push origin master unseren Commit auf den Server übertragen. Damit ist es nun möglich, dass andere Teammitglieder, Kollegen, Freunde oder wer auch immer Zugriff auf das Repository hat, an dem Projekt mitarbeiten kann.

Extension anlegen - customer_theme_example

Bevor die Struktur für die Extension angelegt wird, sollte in der Datei ".gitignore" (im Projekt-Root) folgende Zeile hinzugefügt werden !/web/typo3conf/ext/customer_theme_example. Dadurch wird Git angewiesen das entsprechende Verzeichnis nicht zu ignorieren.

Die eigene Extension legen wir nun im Verzeichnis /web/typo3conf/ext/ an. Die Grundstruktur der Exentsion kann wie im nachfolgenden Screenshot aussehen. Weitere Strukturierungen sind durchaus möglich und denkbar.

Ihr könnt nun immer wenn eine Aufgabe für die Kunden Distribution abgeschlossen ist, diese direkt in eurer Git-Repository übertragen.

Sass compilieren - ohne FileWatcher

Wie in der Ordnerstruktur erkennbar ist, nutze ich für die CSS-Erstellung Sass als PreProcessor, wodurch weniger Code geschrieben und andere Sass-Dateien inkludiert und überschrieben werden können. In PhpStorm gibt es sogenannte FileWatcher welche bei Änderungen in Dateien anspringen und unterschiedliche Dinge ausführen können. Ich selbst mag den FileWatcher für Sass nicht, da dieser wirklich bei jeder Änderung anspringt, obwohl man sich noch nicht sicher ist, ob der geschriebene Code so bleiben soll. Werden zudem noch CSS-Frameworks inkludiert, dauert das Rendering entsprechend lange, was wiederum den Arbeitsfluss stört (triff zumindest für mich zu).

Daher nutze ich die Option der "Externen Tools" in PhpStorm, wodurch die Generierung manuell aufrufen werden kann und die CSS-Datei dabei automatisch im Verzeichnis /customer_theme_example/Resources/Public/Css/ abgelegt wird. Auf dem unteren Screenshot kann man meine Konfiguration für die Sass-Generierung sehen. Möglich sind auch weitere Konfigurationen, so dass diese speziell gestartet werden können (z.B. eine minimierte CSS).

Nachdem diese Einstellung gespeichert ist, legt man eine entsprechende Sass Datei in der Distribution an

Nun kann man mit der rechten Maustaste auf die Sass-Datei klicken und erhält in dem Context-Menü einen Punkt "Sass" in welchem sich als Unterpunkt "Sass to Css" befindet.

Nachdem nun auch mit Git gearbeitet wird, ist die Einrichtung eines TYPO3 Projektes in PhpStorm in den Grundlagen fertig. An dem Projekt kann nun gearbeitet werden, bevor wird es z.B. mit TYPO3.Surf auf den Ziel-Server des Kunden deployen. Dazu aber mehr im nächsten Kapitel ;)

Fragen, Probleme, Anregungen? Dann her damit, in den Kommentaren oder per Twitter an @chriwode.

[chriwode]

Coding Styles festlegen

Teil 4 - Coding Styles sind ein wichtiger Bestandteil in Projekten an die man sich unbedingt halten sollte. Natürlich kann jeder Entwickler, respektive jede Agentur ihren eigenen Coding Style bzw. Coding Guidelines definieren, aber es macht durchaus Sinn sich an bewährtem zu orientieren bzw. bewährtes zu nutzen.

Für TYPO3 Projekte gibt es bereits eine ausführliche Dokumentation zum Thema Coding Guidelines bzgl. PHP Dateien. Im allgemeinen wird auf den PSR-2 Standard gesetzt. Dieser lässt sich in PhpStorm einfach einrichten. Damit aber nicht genug, auch HTML, CSS und JavaScript Dateien unterliegen einem CodeStyle.

PSR-2 CodeStyle einrichten

Der CodeStyle für PHP Dateien lässt sich sehr einfach, mit wenigen Klicks in den PhpStorm Einstellungen festlegen.

PHP-CS-FIXER

Zusätzlich könnt (solltet) ihr euch PHP-CS-Fixer installieren wodurch ihr euren Code nach Änderungen erneut formatieren lassen könnt. Dazu kann man sich im Projekt eine *.dist Datei anlegen, welche als Konfiguration für PHP-CS-Fixer genutzt wird. Im TYPO3 Core befindet sich bereits eine entsprechende Konfigurationsdatei, welche auch für eigene Projekte genutzt werden kann. Weiterhin hat Nicole Cordes für die Extension content-defender eine eigene Konfigurationsdatei und bevor ich das alles wußte, hatte ich mir die Mühe gemacht und eine entsprechende Datei erstellt. Diese gibt es als Gist zum download.

Für welche ihr euch auch immer entscheidet ist nicht wichtig, sondern das ihr PHP-CS-Fixer regelmäßig über euren Code laufen lasst. Dazu könnt ihr PHP-CS-Fixer als externes Tool in PhpStorm einbinden. Ich habe dafür 2 Konfigurationen angelegt, wobei die eine Konfiguration nur die aktuell geöffnete Datei und die zweite Konfiguration das gesamte Projekt überprüft und anpasst.

Nachdem die Einstellungen in PhpStorm konfiguriert sind, könnt ihr nun mit einem Rechtsklick auf eine Datei oder euren Projektordner PHP-CS-Fixer ausführen.

EditorConfig

Damit ihr einen Code Style für alle anderen Dateien (abgesehen von PHP Dateien) erhaltet, könnt ihr euch innerhalb eures Projektes die Datei .editorconfig anlegen bzw. ihr nutzt die entsprechende Datei aus dem TYPO3 Core und speichert diese in eurem Projekt. Anschließend, falls noch nicht geschehen installiert ihr das Plugin EditorConfig und alle neu angelegten Dateien werden entsprechend der Definition formatiert.

Für den Tipp mit der .editorconfig, welcher mir absolut neu war möchte ich mich bei @IchHabRecht, @faulencer, @MarcusSchwemer, @kaystrobach und @wahnsinn bedanken.

Meine Einstellungen für HTML und XML Dateien könnt in den nachfolgenden Screenshots sehen. An dieser Stelle, Danke an @IchHabRecht für das teilen der Einstellungen.

Bestehende Dateien (außer PHP-Dateien) können zudem über den Menüpunkt Code => Reformat Code formatiert werden. Ihr könnt dabei auch einzelne Ordner auswählen und die Formatierung darauf anwenden. Die Optionen Optimize imports und Rearrange entries habe ich dabei deaktiviert.

Gelegentlich habe ich das Problem, dass InlineViewHelper umgebrochen werden, wodurch Fluid diese nicht mehr korrekt erkennen kann und entsprechende Fehlermeldungen ausgibt. Hier also mit Vorsicht unterwegs sein.

Falls ihr weitere Anregungen zum CodeStyle habt, dann gern her damit. Entweder in den Kommentaren oder per Twitter an @chriwode.

[chriwode]

PhpStorm für TYPO3 Projekte einrichten

Teil 3 - Nachdem wir inzwischen mit Composer umgehen können (wenn auch vielleicht nur rudimentär) und unser Projekt in PhpStorm eingebunden haben, wird es an der Zeit ein paar Einstellungen in PhpStorm zu machen. Falls du das verpasst haben solltest, schau doch mal in Teil 1 und Teil 2 dieser Serie vorbei.

Nachdem ich lange Zeit Netbeans genutzt habe, habe ich vor die Vorteile von PhpStorm lieben gelernt und möchte auch keine andere IDE mehr nutzen. Die durch die Einbindung externer Tools und die vorhanden Plugins sind TYPO3 Projekte damit einfach sehr gut zu realisieren.

Dennoch stoße ich immer wieder auf Probleme, welche ich in diesem Post verdeutlichen möchte und hoffe das andere Tipps haben wie man diese beheben kann.

Eine wichtige und für mich Erkenntnis bei PhPStorm ist, dass es eine Unterschied macht ob die Einstellungen innerhalb eines offenen Projektes oder im Startbildschirm von PhpStorm vorgenommen werden.

Einstellungen die im Startbildschirm vorgenommen werden gelten Global und werden als Default für alle zukünftigen Projekte verwendet. Werden die Einstellungen innerhalb eines offenen Projektes vorgenommen, so gelten diese zumeist nur für das aktuellen Projekt! Zu erkennen ist dies im Breadcrumb in welchem entweder For default project oder For current project steht.

Zusätzliches HTML Fluid Template

Eine allgemeine Einstellung die ich vorgenommen habe ist, dass ich mir in den Einstellungen unter File and Code Templates eine separate HTML Fluid Vorlage erstellt habe. Dadurch erhalte ich beim Anlegen einer HTML Fluid Datei immer eine Codebasis

mit welcher die Autovervollständigung von TYPO3 ViewHelpern funktioniert. Eine detailliertere Beschreibung dazu und wie ihr dies auch mit euren eigenen ViewHelpern machen könnt, gibt @helhum unter http://insight.helhum.io/post/85031122475/xml-schema-auto-completion-in-phpstorm

Verzeichnisse

In den Einstellungen gibt es den Punkt Directories mit welchem ihr die Verzeichnisse eures Projektes bestimmen könnt (Tests, Sources, Excludes, Resource Root).

Resource Root Verzeichnis

Als ResourceRoot Verzeichnis markiert ihr das oberste Verzeichnis eures Projektes. Diest dient dazu die Autovervollständigung in eurem gesamten Projekt zu erhalten, so zum Beispiel in CSS und JavaScript Dateien.

Verzeichnis(se) als Sourcen kennzeichnen

Als Sources Verzeichnis markiere ich immer das vendor Verzeichnis. Durch diese Markierung hilft euch PhpStorm bei der Verwaltung und Nutzung von Namespaces beim erstellen oder verschieben von PHP Dateien.

Exkludieren von Dateien und Verzeichnissen

Im Nachfolgenden Screenshot habe ich mal alle Verzeichnise die ich während der Umsetzung nicht benötige als Excludes markiert. Damit werden euch diese Verzeichnisse im Verzeichnisbaum vom PhpStorm ausgeblendet (optional lassen diese sich wieder anzeigen).

Die excludierten Verzeichnisse werden euch in Orange dargestellt. Damit diese nun nicht mehr sichbar sind, können wir auf das Einstell-Rädchen oberhalb des Verzeichnisbaums klicken und die Option Show excluded files abwählen. Somit reduziert sich der Seitenbaum auf Verzeichnisse und Dateien die ihr zur aktiven Entwicklung benötigt.

Damit einzelne Dateien excludiert werden können bietet PhpStorm eine Eingabezeile Exclude files:, in welche folgende Dateien eingetragen werden: index.php;*AdditionalConfiguration.php;*PackageStates.php, da ich diese in meinem Projekt nicht editieren möchte.

Das Excludieren von Dateien und Verzeichnissen hat zudem den Vorteil, das PhpStorm diese Dateien und Verzeichnisse innerhalb seines Indexzierungprozesses ausschließt.

Datenbankverbindung

Für alle die zwischenzeitlich mal einen Blick in die Datenbank werfen müssen oder wollen, bietet es sich an diese zu konfigurieren. Damit werden Tools wie PhpMyAdmin in TYPO3 Installationen nun mehr als überflüssig!

Für die Konfiguration habe ich einige Screenshots erstellt, damit es besser nachvollziehbar ist. In PhpStorm habt ihr an der rechten Seitenleiste den Punkt Database.

Solltet ihr beim testen der Verbindung eine Fehlermeldung erhalten:

Connection to Blog-DB failed. [01S00] Must specify at least one slave host to connect to for master/slave replication load-balancing functionality

dann ist der korrekte Treiber nocht nicht ausgewählt. Klickt hierzu auf Driver: MySQL wie im vorherigen Screenshot zu sehen und wählt wie im nachfolgenden Screenshot bei Class com.mysql.jdbc.Driver aus.

PhpStorm Plugins

In einem späteren Teil dieser Serie komme ich noch auf die von mir benutzten Plugins und externen Tools zu sprechen. Vorab möchte ich schon einmal auf ein paar Plugins hinweisen die ihr sicherlich gebrauchen könnt

TYPO3 CMS Plugin

TYPO3 XLIFF Utility

TypoScript Plugin

Auf YouTube findet ihr von Oliver Thiele einen Beitrag vom April 2016, welchen ich nicht als Best-Practice sehe, aber in welchem er ein paar interessante Einstellungen in PhpStorm zeigt.

Bei der Entwicklung einer Extension kommen noch ein paar Einstellungen hinzu, auf welche ich in einem späteren Teil eingehen werde.

Fallen euch noch weitere Einstellungen ein die per Default bei jedem Projekt gemacht werden sollten? Schreibt dies gern in die Kommentare oder per Twitter an @chriwode

[chriwode]

Projekt in PhpStorm einbinden

Teil 2 - Damit wir loslegen können, solltet ihr in Teil 1 TYPO3-Projekt mit Composer eine fertige Composer Datei besitzen oder eine der genannten Distributionen verwenden.

Da die Einstellungen in PhpSorm vielseitig sind, habe ich mich dazu entschlossen diesen Bereich separat zu behandlen und euch in diesem Teil die Einbindung eures Projektes in PhpStorm zeigen.

Composer per Konsole aus Git Repository auschecken

Es macht durchaus Sinn seine Composer Datei in ein Git Repository zu speichern, damit ihr diese bei jedem neuen Projekt verwenden könnt. Hierzu bietet sich GitHub, BitBucket oder gar GitLab an. Auf der Konsole könnt ihr den Checkout mittels git clone REPOSITORY-URL EuerNeuerProjektName machen. EuerNeuerProjektName wird das Verzeichnis in welches Git das Repository ablegt. Damit ihr die Versionshistory des Repositories verliert (dies ist hierbei ausdrücklich gewünscht) wechselt in das Verzeichnis EuerNeuerProjektName und löscht das Verzeichnis .git rekursiv mittels rm -rf .git

Composer mittels PhpStorm auschecken

PhpStorm bietet euch ebenfalls das Reppository zu holen. Dazu wählt im Startbildschirm von PhpStorm Check out from Version Control aus und gebt die notwendigen Daten wie Git-Repository und Zielverzeichnis an. Das Verzeichnis .git könnt ihr allerdings in PhpStorm nicht sehen, so dass ihr es hier manuel außerhalb von PhpStorm löschen müsst.

Mit einem Rechtsklick auf die composer.json Datei öffnet sich ein Kontextmenü und ihr habt die Option ein composer install auszuführen

Für welchen Weg ihr euch auch immer entscheidet, ich beforzuge den Weg auf der Konsole, sollte euer Projekt in PhpStorm anschließend so aussehen

[chriwode]

TYPO3-Projekt mit Composer

Teil 1 - Composer ist aus meiner Sicht aus der TYPO3-Welt nicht mehr wegzudenken. Es gibt noch den einen oder anderen der Projekte nicht mit Composer erstellt, was ich mir selbst nicht mehr vorstellen mag.

Kurzer Abriss zu Composer

Für all diejenigen welche noch nicht mit Composer arbeiten sei gesagt, stellt eure Projekte darauf um. Das handling der Projektabhängigkeiten wird hierdurch deutlich vereinfacht. Composer selbst ist ein Paketmanager, durch welchen ihr alle benötigten TYPO3 Extensions installieren könnt.

Anlaufstellen für Composer

Eine der ersten Anlaufstellen ist https://composer.typo3.org/, wo euch rudimentär erklärt wird wie ihr ein Composer basiertes TYPO3 Projekt erstellt. Bei der Vertiefung eurer Composer Kenntnisse hilft euch https://getcomposer.org/.

Darüber hinaus haben sich andere Leute bereits Gedanken darüber gemacht, die Composer-Datei nicht stets neu erstellen zu müssen. Zum einen gehört Helmut Hummel (@helhum) und Stefan Salzmann (@KaffDaddy) dazu, zum anderen habe ich mich auch so meine Gedanken dazu gemacht ;)

Helmut's Composer Varianten

Von Helmut gibt es auf GitHub die TYPO3-Distribution, welche alles enthält um sein eigenes Projekt zu erstellen. Diese Distribution schließt bereits die optionale Nutzung von Surf mit ein. Zudem gibt es auf GistHub von Helmut seine (derzeit) ideale Composer Datei samt Beschreibung.

Stefan's Composer Variante

Auf den Blog von Stefan bin ich erst kürzlich gestoßen, als ich mich mit diesem Best-Practise auseinder gesetzt habe. Ähnlich wie Helmut beschreibt Stefan den Aufbau seiner Composer-Datei mit interessanten Details und wie er diese gleich mit der typo3_console verbindet.

Christian's Composer Variante

Neben oben genannten Möglichkeiten habe ich selbst auch eine Variante auf GitHub veröffentlicht. Mit meiner Variante ist die Nutzung von Surf möglich und auch die typo3_console kommt hier zum Einsatz. Wobei ich ehrlich gestehen muss, dass meine Variante eine ältere Variante von Helmut's TYPO3-Distribution ist, welche jedoch um andere Dinge erweitert wurde.

Auf welchen Weg auch immer ihr eure Composer-Datei erstellt, mittels dem Konsolenbefehl composer install installiert ihr das TYPO3-Projekt mit allen notwendigen Abhängigkeien. Ihr wollt nachträglich eine Extension installieren?, kein Problem! Dazu auf der Konsole lediglich composer require typo3-ter/ext-key tippen und schon wird die Erweiterung installiert.

Welche TYPO3 Extensions über o.g. Befehl installiert werden können, könnt ihr unter https://composer.typo3.org/satis.html herausfinden. Wichtig ist lediglich der Bindestricht im Extensionnamen. Heißt eine Extension beispielsweise cw_best_practice, so muss diese bei Composer als cw-best-practice angegeben werden.

Hinweis von @IchHabRecht (vielen Dank dafür)

Es ist besser eine TYPO3 Extension über den Package Key in die Composer Datei hinzu zufügen. Dazu muss die jeweilige Extension bei Packagist registriert sein. Zudem macht man sich vom TYPO3 Extension Repository (TER) nicht abhängig.

Das bedeutet, wenn ihr beispielsweise die Extension "News" von Georg Ringer nutzen möchtet, reicht ein composer require georgringer/news und die Extension wird in der aktuellsten Version für die euere TYPO3 Installation installiert.

Ist man mit Composer zwischenzeitlich warm geworden und mag nicht mehr ohne arbeiten, dann ist der Blogbeitrag von Marcus Schwemmer sehr hilfreich, in welchem er das Patchen von Erweiterungen bzw. auch vom TYPO3 Core beschreibt. Ich konnte dies bereits auch 2x verwenden und es ist ein Traum wie einfach und schnell das geht.

Wenn jemand weitere interessante Links zu diesem Thema hat, bitte diese gern als Kommentar hinterlassen, so dass diese hier mit aufgeführt werden können.

[chriwode]

TYPO3 Projekt in PhpStorm einrichten

Es gibt sicherlich diverse Möglichkeiten ein TYPO3 Projekt in PhpStorm einzurichten. Da es derzeit scheinbar noch kein Best-Practice dazu gibt, möchte ich versuchen meinen Weg zu beschreiben und hoffe darauf Input von vielen anderen Stellen zu bekommen. Mein Weg hat aus meiner Sicht einige Lücken/Schwachpunkte die immer wieder zu verschiedenen Problemen führen.

Um ein wirkliches Best-Practice zu entwickeln werde ich die Beschreibungen in kleinere Beiträge unterteilen. Hierbei sollen die Themen Composer, Surf, typo3_console, Git, PhpStorm, Dokumentation und die Entwicklung einer eigenen Extension in diesem Umfeld besprochen werden.

Zu allen Einzelthemen gibt es bereits genügend Blog- bzw. Gistbeiträge, die ich auch gern nennen möchte. Jedoch ist für mich die Kombination aus allem hier entscheident.

Dieses Blogserie soll sich klar nicht nur an Enwickler richten, sondern den Integrator in den Forderung schieben. Meiner Ansicht nach hat sich das Aufgabengebiet eines Integrators vergrößert, so dass es nicht nur seine Aufgabe ist eine Extension einzurichten.

Teil 1 TYPO3-Projekt mit Composer

Teil 2 Projekt in PhpStorm einbinden

Teil 3 PhpStorm einrichten

Teil 4 Coding Style

Teil 5 Eigene Extension integrieren

Teil 6 Website-Projekt mit Surf deployen

Teil 7 Dokumentieren mit Sphinx und/oder Markdown

Teil 8 Tools in PhpStorm

Gern könnt ihr Themenwünsche in den Kommentaren hinterlassen, so dass diese hier ebenfalls einfliessen können.

[chriwode]

Bootstrap Tabellen-Klassen im RTE

Auf der Suche wie man in TYPO3 7.6.x Bootstrap Klassen für Tabellen im RTE unterbringen kann ist klar geworden, dass dies ein scheinbar schwieriges Unterfangen wird. Viele Artikel in Foren, StackOverflow und anderen Blogs brachten mich dem Ziel immer nur ein Stück weiter, aber scheinbar war es unmöglich.

Also musste die TSref und TSconfig herhalten und der eine oder andere Snippet der sich irgendwo auf meiner Festplatte befand. Schließlich gab es eine Lösung, so dass im Tabellenelement im RTE die Bootstrap Klassen auswählbar waren und anschließend im Frontend eingebunden wurden.

So viel zur Theorie und der Suche nach einer Lösung, packen wir's an

Als erstes brauchen wir für den RTE eine eigenständige CSS-Datei, welche ihr beliebig ablegen könnt (falls noch nicht vorhanden). In dieser CSS-Datei (nennen wir sie mal rte.css) legen wir folgenden Code an:

table.hover {background-color:transparent;} table.bordered {border: 1px solid #ddd;} table.striped {background-color:transparent;} table.condensed tr td, table.condensed tr th {padding: 5px;}

Normalerweise heißen die Bootstrap CSS Klassen für Tabellen table-hover, table-bordered, table-striped und table-condensed.

Kurzer Ausflug: Um die CSS Klassen für Tabellen nutzen zu können ist es notwendig mehrere CSS Klassen gleichzeit anzugeben, z.B. table table-striped. Aber genau das scheint nicht zu funktionieren, so dass wir .table und den Prefix .table- vorerst ignorieren und später wieder zusammenfügen.

Der geschriebene CSS-Code ist selbst nicht so wichtig. Ob nun Hintergrundfarben oder was auch immer definiert wird ist egal. Hauptsache die Klassen sind verfügbar, da der RTE sich sonst weigert diese anzubieten.

Anschließend müssen wir im PageTsConfig dem RTE die rte.css bekannt geben und die erlaubten CSS-Klassen definieren. Dies geht recht einfach mit folgendem Snippet:

RTE.default { contentCSS = your-path/rte.css buttons { blockstyle { tags.table.allowedClasses := addToList(striped,bordered,hover,condensed) } } proc { allowedClasses := addTolist(striped,bordered,hover,condensed) } }

Wenn bis hierhin alles geklappt hat, bietet der RTE nun die CSS-Klassen an.

So weit, so gut. Nur werden die Klassen noch nicht im Frontend ausgegeben. Dazu muss im TypoScript Setup die lib.parseFunc_RTE etwas aufgebohren werden, was genau so geht:

lib.parseFunc_RTE.externalBlocks { table { stdWrap { HTMLparser.tags.table.fixAttrib.class { list := addToList(hover,striped,bordered,condensed) always = 1 prefixRelPathWith = table table- } wrap = <div class="table-responsive">|</div> } } }

Hier werden noch einmal die erlaubten CSS-Klassen für unsere Tabelle hinzugefügt. Entscheidend an dieser Stelle ist prefixRelPathWith wodurch die 2te notwendige CSS-Klasse table und der Prefix table- vorangestellt wird. Dadurch erhält man nun wieder die gewünschte Bootstrap Klassendefinition für Tabellen z.B. table table-striped.

Zusätzlich ist im stdWrap noch ein wrap eingebunden, welcher dafür sorgt das um die Tabelle ein zusätzlicher Div-Container mit einer CSS-Klasse erzeugt wird. Damit werden Tabellen in Bootstrap nun auch Responsive, yeaaaaa.

That's it! Wenig Code, smarte Lösung, Lösungssuche mehrere Stunden...

Nachtrag: Die Code-Snippets sind in diesem Gist noch einmal zusammengefasst.

[chriwode]

News-Kategorien an Menü andocken

Pflegt man auf seiner Webseite News-Artikel und kategorisiert diese schön, so kommt man schnell auf die Idee, die Kategorien mit in das Hauptmenü zu integrieren. Die TYPO3 Extension news (tx_news) hat für die Ausgabe der Kategorien sogar eine entsprechende Ausgabe, jedoch ist diese für die Implementierung in das Hauptmenü nicht geeignet und sicherlich auch nicht gedacht. Einfacher geht dies mit ein paar Zeilen TypoScript, wodurch man sehr flexibel ist und diese Snippets auch für andere Extensions mit Kategorisierung nutzen kann.

Das TypoScript habe ich in 2 Bereiche aufgeteilt, Konstanten und Setup. Dadurch ist eine flexible Nutzung möglich, indem lediglich die Konstanten angepasst werden.

appendCategoryMenu { # cat=appendCategoryMenu/navigation/10; type=string; label=complete string of navigation lib menuLibary = # cat=appendCategoryMenu/navigation/20; type=int+; label=UID of navigation point menuPid = # cat=appendCategoryMenu/navigation/30; type=int+; label=UID of category pages defaultCategoryPid = #cat=appendCategoryMenu/navigation/40; type=int+; label=UID of the parent category. All subcategories would be used in the menu parentCategory = 0 }

In den Konstanten oben, welche auch durch den Konstanten-Editor von TYPO3 gepflegt werden können, gibt man unter der menuLibary den Namen seiner Menü Libary an. Diese wird im Setup benötigt, um die Kategorien nur an diese Menü Libary (z.B. lib.myMainMenu) zu hängen. Unter menuPid gibt man die SeitenUid der Seite an, welche als Hauptmenüpunkt dient. Die defaultCategoryPid ist die Seite, auf welche alle News-Artikel einer Kategorie ausgegeben werden sollen. Wenn man einen großen Kategoriebaum hat oder diesen auch für andere Dinge benutzt, ist es sinnvoll nur die Kategorien ausgeben zu wollen, welche zu einer bestimmten Hauptkategorie gehören. Dies kann mittels parentCategory konfiguriert werden.

Der Setup-Bereich ist dabei schon ein wenig umfangreicher, sollte sich aber selbst erklären. In diesem werden letztendlich die oben definierten Konstanten und die Konstanten der News-Extension genutzt.

Das untere TypoScript bindet die Kategorien lediglicht an die erste Ebene des Hauptmenüs.

# Category menu as sublevel menu ############################################ lib.categoryMenu = COA lib.categoryMenu { wrap = <ul class="dropdown-menu graybg-bottom">|</ul> 10 = CONTENT 10 { table = sys_category select { pidInList = {$plugin.tx_news.persistence.storagePid} andWhere.dataWrap = parent={$appendCategoryMenu.parentCategory} } renderObj = COA renderObj { 10 = TEXT 10 { field = title typolink { # listPid parameter.dataWrap = {$appendCategoryMenu.defaultCategoryPid} # add link params additionalParams = &tx_news_pi1[overwriteDemand][categories]={field:uid} additionalParams.insertData = 1 useCacheHash = 1 no_cache = 0 } wrap = <li role="presentation">|</li> } } } } {$appendCategoryMenu.menuLibary} { 1 { NO { # move parent categories as sub menu entry after.cObject = CASE after.cObject { key.field = uid # e.g. uid 51 of page to append the parent categories {$appendCategoryMenu.menuPid} < lib.categoryMenu } } } }

[chriwode]

Belegungs- und Stundenpläne mit Gridelements

Mit der Exentsion gridelements kann man so einiges Anstellen und die diverse Grids anlegen. Für ein Kundenprojekt (eine Grundschule) sollten die Stundenpläne der einzelnen Klassen auf der Webseite abgebidlet werden. Grundsätzlich würde man dies mit einer Tabelle erledigen, jedoch empfinde ich die Pflege einer Tabelle in TYPO3 nicht besonders praktisch. Die Pflege über gridelements ist da schon etwas besser und es ist möglich die Standard Content Elemente von TYPO3 zu nutzen.

Voraussetzungen

Für die Umsetzung habe ich 2 Extension benötigt, welche bereits in dem Projekt genutzt wurden:

Gridelements

VHS: Fluid Viewhelpers

Erstellt werden mussten 2 Gridelemente, eine FlexForm (optional) und ein Fluid HTML. Natürlich noch ein wenig TypoScript, um die Gridelemente zu konfigurieren und ein wenig CSS. Damit ich euch nicht mit ewig langen Codezeilen langweile, habe ich den entsprechenden Code für die Dateien bei Gist abgelegt.

Die FlexForm ist wie schon erwähnt optional, jedoch würde ich diese empfehlen, da dadurch die Uhrzeiten für die einzelnen Unterrichtzeiten gepflegt werden können.

Ausgabe im BE und FE

Im TYPO3 Backend kann es in etwa so aussehen:

In den Grids habe ich für beide Layouts Farben vergeben, um den Redakteuren einen besseren Überblick zu geben und damit das Bearbeiten zu vereinfachen. Im Codes des Grid Unterricht kann man sehen, dass ich lediglich das Text-Element zugelassen habe, damit Redakteure keine weitere Option für CE’s haben und damit die Fehler bei der Eingabe reduziert werden.

Die Ausgabe im Frontend könnte wie in diesem Screenshot aussehen:

Optimierung

Optional kann man überlegen, ob man statt den Default Content Elementen, eigene Content Elemente baut, um dem Redakteur noch die Pflege noch weiter zu vereinfachen.

[chriwode]

Erweitere Suchfunktion in Ext. femanager

In der Dokumentation des femanagers ist gut beschrieben, wie man diesen erweitern kann, um eigene Felder bei der User Registrierung bzw. beim ändern seiner Daten einzubinden. Nun hatte ich die Anforderung die FeUser Ausgabe inkl. Suchfunktion zu implementieren und dabei weitere Suchoptionen zur Verfügung zu stellen.

Zuerst muss per TypoScript das Überschreiben des UserController ermöglicht werden:

config.tx_extbase { objects { In2code\Femanager\Controller\UserController { className = Vendor\ExtensionName\Controller\UserController } } }

Nun können wir den UserController erstellen, welcher vom femanager UserController abgeleitet wird

<?php namespace Vendor\ExtensionName\Controller; class UserController extends \In2code\Femanager\Controller\UserController { /** * list action * * @param array $filter * @return void */ public function listAction($filter = []) { if (!empty($filter['searchgroup'])) { $this->settings['list']['usergroup'] = intval($filter['searchgroup']); } parent::listAction($filter); } }

In der Variablen $filter[‘searchgroup’] wird überprüft ob sich Inhalt befindet und wenn dies so ist, wird dieser mit den Settings überschrieben. searchgroup ist die definierte Selektbox in unserem Suchformular, welche wir etwas später erstellen.

Nun fehlen nur noch 2 Dinge.

wir müssen das Suchtemplate anpassen und

wir müssen noch einen kleinen ViewHelper schreiben, welcher alle Benutzergruppen ausließt.

Den ViewHelper habe ich “GetFeUserGroupsViewHelper” genannt und im Verzeichnis “/Classes/ViewHelpers/Form/” abgelegt.

<?php namespace Vendor\ExtensionName\ViewHelpers\Form; use TYPO3\CMS\Extbase\Reflection\ObjectAccess; use TYPO3\CMS\Fluid\Core\ViewHelper\AbstractViewHelper; class GetFeUserGroupsViewHelper extends AbstractViewHelper { /** * UserGroupRepository * * @var \In2\Femanager\Domain\Repository\UserGroupRepository * @inject */ protected $userGroupRepository; /** * Build an feUserGroup array * * @param string $removeFromUserGroupSelection commaseparated list * @return array */ public function render($removeFromUserGroupSelection = '') { $feGroups = $this->userGroupRepository->findAllForFrontendSelection($removeFromUserGroupSelection); $feGroupsArray = []; foreach ($feGroups as $group) { /**@var \In2code\Femanager\Domain\Model\UserGroup $group*/ $feGroupsArray[ObjectAccess::getProperty($group, 'uid')] = ObjectAccess::getProperty($group, 'title'); } return $feGroupsArray; } }

Der ViewHelper ermöglicht es, alle vorhandenen FeUserGroups auszulesen. Als Parameter kann der ViewHelper allerdings eine kommaseparierte Liste von FeUserGroup Uids enthalten, welche in der Ausgabe ausgeschlossen werden sollen, was kann bequem per TypoScript definiert wird. Dazu habe ich den TypoScript Bereich des filters im femanager erweitert:

plugin { tx_femananger { settings { list { filter { searchgroup { removeFromUserGroupSelection = 1,5,17 } } } } } }

Mit dem obigen TS Snippet schließen wir die FeUserGroups mit den Uid 1,5 und 17 aus, so dass diese nicht in der Selektbox erscheinen.

Fehlt nur noch das Partial “Searchform.html”, um die entsprechende Selektbox zu erweitern. Der folgende Code muss dem Partial hinzugefügt werden.

{namespace yourKey=Vendor\ExtensionName\ViewHelpers} <div class="femanager_fieldset femanager_searchgroup form-group"> <div class="controls"> <femanager.form.select id="searchgroup" property="searchgroup" options="{yourKey:Form.GetFeUserGroups(removeFromUserGroupSelection:'{settings.list.filter.searchgroup.removeFromUserGroupSelection}')}" defaultoption="{f:translate(key:'searchGroupPlaceholder')}" class="form-control"></femanager.form.select></div> </div>

Mit ein wenig CSS könnte das Suchformular anschließend etwas so aussehen:

Happy coding ;) Das ganze Beispiel gibt es auch auf github

[chriwode]

Update Gridelements zu Version 3

colPos Sicherung vor dem Update

Bevor ein Update des TYPO3 Cores durchgeführt wird, müsst ihr per PhpMyAdmin oder ähnlichen MySQL Tools einen kleinen Datenbank Dump des colPos Feldes erstellen. Ich persönlich mache dies mit diesem SQL-Query und exportiere mir dann dass Ergebnis.

SELECT CONCAT('UPDATE tt_content set colPos=',colPos,' where uid=',uid,' limit 1;') FROM tt_content ORDER BY uid;

Das Ergebnis des obigen SQL Queries kann beispielsweise wie folgt aussehen

UPDATE tt_content set colPos=0 where uid=1 limit 1; UPDATE tt_content set colPos=-1 where uid=8 limit 1; UPDATE tt_content set colPos=-2 where uid=12 limit 1;

Danach führe ich das Update/Upgrade für den TYPO3 Core und gridelements durch und aktualisiere anschließend wieder das colPos Feld mittels des zuvor exportierten Queries. Nun sind alle Inhalte wieder in den entsprechenden Grids gespeichert.

Danke an @bunnyfield für die Korrektur des Textes und der Problembeschreibung!

[chriwode]

TYPO3 Upgrade HowTo

Ich möchte euch hier einen kleinen Leitfaden geben, welcher bei mir bisher sehr funktioniert hat und sich bei aktuell 20 TYPO3 Upgrades von Version 4.6 auf 6.2.6 bewährt hat. Die beigefügten Scripte funktionieren auch problemlos bei 4.7-Versionen.

Wichtig: Führt das Upgrade niemals im Livebetrieb aus, erstellt auch immer eine Testumgebung der Dateien und Datenbank!

Upgrade Vorbereitung

alle vorhandenen Extension auf die den aktuellen Stand bringen (sofern noch unterstützt)

überlegen, ob wirklich alle Extensions benötigt werden oder ggf. durch TypoScript Code ersetzt werden können

Datenbank Compare im InstallTool durchführen

alle Extensions deaktivieren, die von 6.2 nicht mehr unterstützt werden oder die erst in Version 6.2 aktualisiert werden können

TypoScript Code prüfen und Anpassungen für 6.2 vornehmen

Database Analyser => “Clear tables” im InstallTool starten

Clean up => alle generierte Bilder entsorgenReferenz Indizes aktualisieren (im InstallTool)

DB-Überprüfung => Globalen Referenz-Index prüfen und aktualisieren im (TYPO3 Backend)

Wenn diese Vorbereitungen abgeschlossen sind, könnte man bereits mit dem Upgrade beginnen. Ich persönlich mache noch 2 zusätzliche Schritte, um Komplikationen bei der Migration der Dokumente wie Bilder, PDF, etc. aus dem Weg zu gehen.

Bei der Dokumentenmigration (Bilder, PDFs, etc.) zu FAL ist mir aufgefallen, das auch Dokumente von gelöschten Datensätzen migrieren werden. Teilweise kann das zu Problemen führen, wenn das entsprechende Dokument bereits vom Server gelöscht wurde. Mittels eines einfachen PHP Scripts lasse ich alle als gelöscht markierten Datensätze in der DB löschen. Das PHP Script besitzt einen Debug und einen Simulations Modus. Dadurch könnt ihr erst einmal prüfen wie viele Daten aus welchen Tabellen gelöscht werden sollen. Um vom Simulationsmodus in den Livemodus zu wechseln müsst ihr lediglich in dem PHP Script in Zeile 19 aus “FALSE” ein “TRUE” machen (ohne die Anführungsstriche).

Nachdem das Script ausgeführt und die Daten gelöscht wurden, lasse ich noch einmal den Referenz Index aktualisieren (siehe Punkt 7 in den Vorbereitungen).

Nachtrag: Alternativ kann auch die Systemextension Recycler (Papierkorb) genutzt werden, um bereits gelöschte Datensätze endgültig aus der Datenbank zu entfernen. Danke an Jousch für den Hinweis.

Nun kann es aber endlich mit dem Upgrade zu 6.2 losgehen ;)

Wenn ihr im Besitzt eines Shell Zugriffs bist, kannst du mit diesen wenigen Zeilen Bash Code die neue Version installieren.

# delete old TYPO3 structure rm -R typo3_src rm typo3 rm t3lib rm index.php #get the current TYPO3 version wget get.typo3.org/current -O typo3_src.tgz # extract the tgz file tar xfpvz typo3_src.tgz # set new symlink ln -s typo3_src-6.2.6 typo3_src ln -s typo3_src/typo3 typo3 ln -s typo3_src/index.php index.php # remove and create folder typo3temp rm -r typo3temp mkdir typo3temp rm typo3_src.tgz

Nun ruft ihr eure Webseite www.domain.ltd/typo3/ auf und ihr werdet zum InstallTool weitergeleitet. Nach dem Login im InstallTool sind ein paar Sachen zu erledigen: solltet ihr als erstes die angezeigten Fehler unter “Folder structure” und “System environment” beseitigen.

Jetzt könnt ihr den “Upgrade Wizard” starten und einfach den Anweisungen folgen. Zum Schluss wird wird euch angeboten das Datenbank compare auszuführen. Diesen Schritt solltet ihr erst einmal ignorieren und stattdessen zum Extensionmanager gehen und alle Extension aktualisieren und anschließend aktivieren. Nun könnt ihr den Datenbank compare im InstallTool durchführen.

Abschließende Arbeiten

“Configuration Presets” globale Einstellungen vornehmen (InstallTool)

aktuellen Sprachpakete laden unter Adminwerkzeuge => Sprache Referenz-Index aktualisieren

Extension rsaauth installieren und saltedpasswords konfigurieren

Viel Spaß mit der TYPO3 Version 6.2.

[chriwode]

Bild - Slider im Content Element

Die Anpassungen am TypoScript sind etwas umfangreicher, daher empfiehlt es sich, den Code gut zu dokumentieren. Als Slider kommt wieder eine jQuery Plugin (Nivo-Slider) zum Einsatz, welcher hier herunter geladen werden (http://dev7studios.com/downloads/63).

Der Grund warum am TypoScript-Code so viel angepasst werden muss ist der, dass der Nivo-Slider nur die img-Tag haben möchte und keine DIV's drumherum. Da TYPO3 an dieser Stelle aber etwas fleißig ist, muss da einiges entfernt werden.

Schritt 1: jQuery und Nivo-Slider einbinden

Fangen wir mit den einfachen Sachen an und binden die jQuery-Bibliothek und den Nivo-Slider ein.

page { includeCSS { file10 = fileadmin/externalLibaries/nivo-slider/nivo-slider.css } includeJSFooterlibs { file1 = code.jquery.com/jquery-1.11.0.min.js file1.external = 1 file2 = fileadmin/externalLibaries/nivo-slider/jquery.nivo.slider.pack.js } }

Schritt 2: TCEFORM für tt_content anpassen

Da wir uns später entscheiden wollen, ob wir das Content Element "Text mit Bilder" oder "Nur Bild" mit oder ohne Slider benutzten wollen, erweitern wir den "section_frame" von tt_content. Dazu wird (am besten auf der Root-Seite) in den Seiteneigenschaften unter Seiten-TSconfig der "section_frame" angepasst.

TCEFORM.tt_content { section_frame { addItems { 100 = Bild - Slider } } }

Schritt 3: TypoScript von tt_content anpassen

Nun folgt der Teil mit dem größten Codeänderungen. Im Standard TypoScript werden die Bilder in "tt_content.image.20" gerendert (egal ob "Text mit Bild" oder "Nur Bild"). Dies wollen wir im Grund beibehalten, allerdings müssen wir einen Case einbauen, da wir entscheiden wollen, ob mit oder Slider.

Bevor wir dazu kommen, müssen wir noch im "tt_content.stdWrap" eine Option für unseren Schalter einbauen, da der Nivo-Slider ein paar CSS-Angaben in dem Umschließenden Tag braucht.

tt_content.stdWrap { // --> CE image must be set manuel to 100 for image-slider 100 = changed image-rendering tt_content.image.30 = CASE tt_content.image.30 { key.field = section_frame default singleStdWrap.wrap = | } noCaption { # Multiple images and no caption at all fallbackRendering > allStdWrap > allstdWrap.dataWrap = | singleStdWrap > singleStdWrap.wrap = | rowStdWrap.wrap = | noRowsStdWrap.wrap = | lastRowStdWrap.wrap = | columnStdWrap.wrap = | } } } } }

Da wir die Original Bildrendering Ebene von TYPO3 (tt_content.image.20) nicht mehr benötigen, müssen wir diese und auch die Renderingdefinition von "tt_content.textpic.20" löschen

// --> remove original image-rendering tt_content.image.20 > // --> remove original textpic-rendering tt_content.textpic.20 >

Für "tt_content.textpic.20" müssen wir noch die Definition neu schreiben, damit diese wieder funktioniert. Auch hier muss ein "CASE" rein, damit der "section_frame"-Schalter greift

tt_content.textpic.20 = Text rendering (noSlider) default { text.10 = COA text.10 { if.value = 24 if.isGreaterThan.field = imageorient 10 = | } text.20 = | } // --> Text rendering with Slider 100.9

[chriwode]

Layout des Inhaltselements wrappen

In TYPO3 gibt es in den einzelnen CE's unter dem Karteireiter "Erscheinungsbild" (engl. Appearance) eine Select Box mit der Überschrift "Layout des Inhaltselements". Ohne zusätzliche TypoScript Konfiguration bleibt diese Funktion von TYPO3 leider ungenutzt, obwohl ein enorm starkes Potential in ihr steckt.

Nach einer Standardinstallation von TYPO3 heißen die Optionsfelder in der Select Box "Standard", "Layout 1", "Layout 2", "Layout 3". Allerdings kann man sich nach der späteren Konfiguration dieser Elemente schlecht etwas unter diesen Begriffen vorstellen.

Daher fangen wir damit an, den Optionsfeldern einen eindeutigeren und besseren Namen zu geben.

TCEFORM.tt_content { layout { altLabels { 3 = Blauer Hintergrund - rechte Spalte } } }

Die Labelbezeichnung 3 überschreibt in unserem Fall die vorherige Bezeichnung "Layout 3". Dies kann für alle anderen Layout ebenfalls gemacht werden.

Nun muss im TypoScript - Setup noch das Verhalten des Layout berücksichtigt werden. In meinem Beispiel ändere ich die Eigenschaften für das wrappen des CE TEXT.

tt_content { text { 20 > 20 = CASE 20 { key.field = layout 0 = TEXT 0 { field = bodytext required = 1 parseFunc = | } } }

In Zeile 3 löschen wir die Anweisungen, welche auf das normale CE zutreffen. Dann legen wir uns in Zeile 4 ein CASE - Objekt an, um das Datenbankfeld "layout" ab zufragen (Zeile 6) und entsprechend reagieren zu können.

Zeile 8 bis 20 entspricht der ursprünglichen Konfiguration der von uns gelöschten Ebene 20. Danach kopieren wir die Ebene 0 auf die anderen Ebenen (Zeile 21 - 24). Zeilen 25 legen wir endlich unseren Wrap an, damit der Layoutschalter funktioniert bzw. sich von den anderen unterscheidet.

Nachtrag:

Zusätzlich zu diesem Thema, habe ich einen PodCast von Jens Hoffmann und Arnd (Tips'n'Tricks: Using the page "Layout" field) gefunden, in welchem erklärt wird, wie man das Layout Field ebenfalls für Seiten benutzen kann.