Beiträge aus der Kategorie: TYPO3 CMS

|Allgemein, Blog, TYPO3 CMS

Wieder was gelernt und noch mehr

Ein Rubik´s Cube vor einer Computer-Tastatur

Ich nehme mir ja immer wieder vor, mehr aus diesem Blog zu machen. Mich mitzuteilen und vielleicht sogar anderen Input zu geben, der sie weiterbringt. So wie anderen zigtausend Blogs und Websites, von denen ich tagtäglich lernen darf.

Die letzten Wochen habe ich während meiner Freizeit ziemlich offline verbracht. Wir haben eine neue Terrasse gebaut, was schon feststand, als wir vor ein paar Jahren in dieses Haus eingezogen sind. Damals hätte ich nur nicht gedacht, dass wir das alles alleine machen werden.

Neben dem Mauern und verputzen einer Wand (immerhin 3,5 x 2 m groß), dem Auskoffern, Schottern, Split abziehen und Plattenschneiden habe ich außerdem gelernt, dass man Handwerker einfach nichts fragen muss. Fragt man, wie man das ein oder andere machen muss, bekommt man zwei bis drei Antworten, die aber schon eine Woche später obsolet sind. Fast so wie bei Entwicklern also.

Und dann habe ich mir noch das Lösen eines Rubik´s Cube beigebracht. Den hat mein kleiner Sohn angeschleppt und wollte es eigentlich auch lernen. Da ich ihm absolut nicht helfen konnte, musste ich es mir erst einmal beibringen und kann ihn mittlerweile in knapp über 2 Minuten mit der Anfängermethode lösen. Ob ich noch andere Algorithmen lerne, um wenigstens unter einer Minute zu gelangen... Ich weiß noch nicht.

Und dann fange ich jetzt wieder für die Zertifizierung zum TYPO3 Developer (TCCD) zu lernen. Die TCCI-Zertifizierung durfte ich letzten Freitag um ein Jahr verlängern, wobei ich das Verfahren echt, na sagen wir überdenkenswürdig halte. Nur weil ich an einer Präsentation der Neuerungen von TYPO3 10 teilgenommen habe, die ich selber kurz nach Erscheinen in ähnlicher Form in meiner Abteilung abgehalten habe, habe ich zwar eine Menge an Anregungen gesammelt, beherrsche sie aber nicht. Vielleicht liegt das auch daran, dass ich ja einer der letzten war, bei dem die Zertifizierung normalerweise drei Jahre gilt, die neuen Zertifikate gelten nur noch zwei Jahre.

Für die Vorbereitung ackere ich wieder den Exam Study Guide for the Official TCCD Certification of the TYPO3 Association (https://leanpub.com/typo3certifieddeveloper-en) durch und dieses Mal habe ich mir vorgenommen, bei jedem Thema/Frage, die ich beim Lernen nicht korrekt beantworte, einen Blogpost zu schreiben, in dem ich das Thema dann aufarbeite. So von wegen, wenn man einen Spickzettel schreibt, lernt man am besten. Es werden bestimmt einige Posts werden. ;-)

|TYPO3 CMS

TCCI-Zertifizierung

Vor ein paar Wochen hatte ich richtig Schiss. Respekt. War angespannt wie ein Flitzebogen. Hatte wochenlang gelernt. So richtig, wie man es damals hätte in der Schule oder Uni machen sollen. Kannte ich gar nicht oder hatte es schon wieder vergessen, wie es ist, sich auf eine Prüfung vorzubereiten.

Die Schullaufbahn und die Ausbildung ist ja auch schon echt mal lange her und zwar lerne ich jeden Tag etwas Neues hinzu, aber sich auf eine Zertifizierung vorzubereiten ist dann doch etwas anderes. Aber ich habe es geschafft und die nächsten drei Jahre darf ich mich TYPO3 CMS Certified Integrator nennen!

Und übermütig bin ich auch gleich geworden, bereite ich mich doch schon auf die nächste Zertifizierung vor: TCCD oder TYPO3 CMS Certified Developer. Aber das hat bis Anfang nächsten Jahres noch Zeit...

|TYPO3 CMS

T3DD18 - Vierter und letzter Tag

Und schon ist der letzte Tag der Developer Days da. Schön wars, inspirierend und aufregend zu gleich. Es war ja mein erstes Event überhaupt in der TYPO3 Community und ich hatte von Anfang an das Gefühl integriert zu sein. Ich habe eine Menge netter Leute getroffen, die man bis jetzt nur von Twitter, Slack oder von ihren Arbeiten im TYPO3 Universum her kannte. Ich glaube, ich werde immer mal wieder auf Events vorbeischauen und auch die Form der Barcamps ausprobieren.

How to better maintain your (public) extensions

Nicole Cordes zeigte ihr TravisCI-Setup, mit dem sie eine Menge Tasks abfeuert: PHPLinter zum Überprüfen der Kompatibilität, Unit und Functional Tests, Überprüfen der Codequalität per SonarQube und abschließendes Veröffentlichen im TER, wenn alle Tests durchgelaufen sind.

Auf den gesamten DevDays kristallierte sich heraus, dass es ohne Automatisierung einfach nicht mehr funktioniert. Keiner möchte mehr diese Tasks manuell ausführen, weil es nur unnötig Zeit kostet. Aber diese Tasks einfach wichtig sind und immer wichtiger werden, vor allem, wenn man in Teams unterwegs ist. Dienste wie SonarQube können die Qualität des Codes erhöhen und vor allem auf einen fest definierten Standard bringen. Tests sorgen dafür, dass der ganze Kram in erster Linie funktioniert und Änderungen nichts kaputtmachen.

Es wird Zeit, dass alles auch zu automatisieren!

TYPO3 Performance

Speed ist alles, wenn man eine Website aufruft. Dauert das Laden/Anzeigen der Seite zu lange, ist der Tab schon wieder zu.
Marcus Schwemer von in2code präsentierte seine sieben Schichten der Performance Onion (Delivery, Frontend, TYPO3 Konfiguration, Extensions, TYPO3 Core, Services und Hardware).

Angefangen beim Ausliefern an den Browser mit angepassten Caching-Hinweisen (Expire-Header, Cache-Control-Header), über minimiertes und gezipptes Ausliefern von Ressourcen, über das Verwenden von Cache-Extensions wie staticfilecache, Optimierung der GarbageCollection der TYPO3-Cache-Tabellen, das Verwenden des Caching-Frameworks beim Entwickeln eigener Extensions bis hin zur Optimierung der PHP-Konfiguration und schlußendlich dem Verbessern der Hardware-Architektur war alles dabei.

|TYPO3 CMS

T3DD18 - Dritter Tag

Am dritten Tag war ich etwas zwiegespalten, welche Sessions ich besuchen wollte, weil es leider ein paar Überschneidungen gab. Auf der einen Seite wollte ich mir die PHPUnit-Session anschauen, um nochmal einen Tritt in den Allerwertesten zu bekommen, viel mehr Unit-Testing zu betreiben, auf der anderen Seite hat mich aber die Nachmittagssession über das "perfekte" composer-Setup interessiert. Letzteres hat dann gewonnen.

How TYPO3 can help you with GDPR

Und schon wieder eine GDPR-Session! Wer des Themas noch nicht überdrüssig ist, kann sich gerne mal neben den GDPR-Änderungen in den TYPO3-Cores von 6.2 ELTS bis hin zum Master auch die gdpr-Extension von Georg Ringer, der den Talk gehalten hat, anschauen.

Georg zeigte am Anfang den Scheduler-Task und die IP Anonymization API, die in TYPO3 enthalten ist, wobei diese nur Definitionen für sys_log und indexed_search bereithält, für andere Extensions muss man dann seine eigenen Konfigurationen schreiben bzw. werden hoffentlich diverse Extensions angepasst.

Daneben gibt es ja die schon vorhandenen Tasks des GarbageCollectors und vom Recycler den Task zum Entfernen gelöschter Inhalte aus der Datenbank.

Im Zuge der DSGVO muss man ja vielleicht sogar ein Verfahrensverzeichnis erstellen, was dann einhergehen sollte, dass Backend-Zugriffe restriktiver gehandhabt werden. Denn nicht jeder BE-User muss persönliche Daten einsehen können.

Neben so Allgemeinplätzen wie dem Einbinden von Inhalten fremder Plattformen wie YouTube, ging es dann noch um die in der GDPR/DSGVO verankerten Notwendigkeit von Datenlöschung und Export von personenbezogenen Daten bis hin zur Verschlüsselung von sensiblen Daten direkt in der Datenbank.

Zum Schluss stellte er noch seine gdpr-Extension vor, die es auch in einer zahlungspflichtigen Variante gibt. Diese enthält dann ein Backend-Modul zum Löschen und Pseudonymisieren von Datensätzen mittels Faker.

Slides zu der Session kann man hier finden.

Create your perfect TYPO3 (Composer) project setup

In der Vorbereitung auf die TCCI-Prüfung musste ich mich mit der "normalen" Installation von TYPO3 beschäftigen und stellte mal wieder fest, wie einfach nicht nur die Installation, sondern auch das Verwalten von Abhängigkeiten mit composer geworden ist.

Das "perfekte" composer Setup von Helmut Hummel kommt meinem schon recht nahe (beziehungsweise umgekehrt): es wird alles nur noch per composer verwaltet, mit TYPO3 Console wird die PackageStates geschrieben, die Datenbankstruktur wird auf den neuesten Stand gebracht und die Verzeichnisstruktur wird angepasst.

Auch die Trennung von web und vendor halte ich für obligatorisch. Konfigurationsdateien und ähnliches gehören einfach nicht ins Webroot. Warum man, wie am Beispiel von T-Mobile Austria erwähnt, ein komplettes git-Verzeichnis auf einen Live-Server deployed werden konnte: naja, jeder hat mal einen schlechten Tag.

Ganz so hart wie man es mit Helmuts typo3-secure-web anstellen kann treibe ich es zwar noch nicht, aber das werde ich mir mal anschauen, ob man das Package auf alle Hosting-Umgebungen, mit denen ich es zu tun habe, verwenden kann.

Äußerst interessant fand ich auch sein Konzept des Environment-Handlings mit typo3-config-handling, dass die gesamte Konfiguration und sogar das Extconf-Handling in Yaml-Dateien auslagert. Ich benutze dafür noch den ApplicationContext, der dann je nach Kontext die LocalConfiguration mit anderen Werten überschreibt, die ich zum Beispiel in Development benötige.

Die Slides seiner Präsentation kann man hier finden.

|TYPO3 CMS

T3DD18 - Zweiter Tag

Docker based demo server

Hannes Lau präsentierte am Freitag, wie man TYPO3 in einem Docker Cloud Server mit Jenkins bereitstellt. Dazu gab es einen Workshop, in dem auf einer Instanz von DigitalOcean Docker-Droplets gestartet wurden. Leider gab es zu wenig freigegebene Droplets, so dass es recht kuschelig wurde in den Teams.

DigitalOcean ist ein Cloud-Provider, der für Docker-Container eine API zur Verfügung stellt, um leicht Instanzen per API-Call hochzufahren. Wenn man solch ein Verfahren nicht tagtäglich verwendet, kommt es einem schon vor, als würde man eher eine Rakete zum Start ins Weltall klarmachen, aber es war schon interessant zu sehen, wie man TYPO3 in einem Dockerimage über Jenkins an eine Cloud-Instanz pushed, die dann auch noch per Loadbalancer-System überwacht wird. Für größere Projekte bestimmt mal interessant, in denen es darauf ankommt, zeitnah auf unterschiedliche Anforderungen auf die Systemlast zu reagieren.

How do I get my deployment for a project / TYPO3 extension running with GitLab CI

Den unterhaltsamsten Workshop hat bisher Thomas Löffler gegeben, in dem er Einblick in seinen Gitlab-Workflow gab, wie er zum Einen Code auf unterschiedliche Systeme deployed und zum Anderen Tests auf seine Extensions fährt. 

Ich frage mich ja, warum GitHub seit Jahren diesen Teil des Entwicklerlebens verschläft und nicht selber Tools für Continuos Integration und Delivery anbietet. Hat man seinen Code bei GitHub liegen, muss man auf externe Dienstleister zurückgreifen, um seinen Kram auf diverse Server zu packen.

Gitlab bietet einem dies an und es war nett anzuschauen, wie ähnlich sich die ganzen Integrationen doch sind. BitBucket hat mit seinen Pipelines ein sehr ähnliches Werkzeug geschaffen, wobei die Umsetzung von Gitlab in der Webansicht schöner gestaltet ist. Auch wenn man das eigentlich nicht braucht, denn was ist schon schöner als ein Task, um den man sich nicht kümmern braucht, weil er sich sowieso bei einem Fehlschlag per E-Mail meldet?

Coding Night

Never change a running system! Never! Auch nicht aus "Gier" endlich einen Dark Mode in seinem macOS haben zu wollen. Denn das Update auf die Beta hat mir den Abend vermiest. Zwar war ich dann doch in der Lage über ddev mir das TYPO3 zu installieren, aber als dann nach meinem ersten Code-Review überhaupt, Docker abgeschmiert ist und den Container mitgerissen hat, hatte ich ganz schlechte Laune. Vielleicht auch einfach zu wenig Bier getrunken...

|TYPO3 CMS

T3DD18 - Erster Tag

Etwas aufgeregt bin ich zu meinen ersten TYPO3 Developer Days gefahren. Auf der einen Seite, weil ich endlich mal meine Zertifizierung zum Integrator ablegen wollte, auf der anderen, um auch mal die Gesichter zu den ganzen Commits, Extensions und Twitter-Accounts kennenzulernen, die einen über die ganzen Jahre während des Tages begleiten.

Keynote

Christian Kerschbaum, Anwalt für IT-Recht, hält die Keynote über Data Protection, GDPR/DSGVO und ihre Auswirkungen und deren Anforderungen an die IT. Es war ein nettes Resümee der letzten Wochen, in denen bestimmt bei jedem der ein oder andere Kunde angerufen hat, um seine Website fit zu machen und das drohende Damoklesschwert abzuwenden, das einem medial immer wieder vor Augen geführt wurde.

Seine Ausführungen zur Verwendung von Google Analytics (setzen eigentlich so wenige Google Tag Manager ein?), dem Verwenden von Cloud Hosting, dem Einbinden von Social Networks wie Facebook bestätigen die Entscheidungen, die in letzter Zeit umgesetzt wurden. Auch das leidige Einbinden von Cookie Bannern sieht er genauso kritisch, denn ein einfaches Hinweisen auf Cookies ohne OptIn ist ja eigentlich auch sinnlos. Da reicht es, in den Datenschutzbestimmungen darauf hinzuweisen. Vor allem, weil in dem Moment des Hinweises in den meisten Fällen die Cookies schon gesetzt sind. Und wie speichert man eigentlich die Zustimmung oder Ablehnung von Cookies ab? In einem Cookie?

Dann ging es noch um die Kommunikation per unverschlüsselter E-Mail, was ja streng genommen auch nicht mehr zu verantworten ist. Denn in jeder E-Mail an und von Kunden sind sensible Daten zu Geschäftsvorgängen enthalten, die geschützt werden wollen. Aber wer schon einmal versucht hat, technisch nicht so versierten Gesprächspartnern das Konzept von Verschlüsselung (vor allem über PGP/GPG) beizubringen, weiß, wie große Augen und Kopfschütteln aussehen.

Weitere Themen waren die allgemeinen Dinge der DSGVO wie das Anlegen eines Verfahrensverzeichnisses (sollte jeder wenigstens in Kurzform bereithalten, auch wenn er aufgrund der Mitarbeiterzahl nicht darunterfällt) und die Frage, wie gut man denn eigentlich seine Kunden kennt. Wer kann aus der Hüfte Verantwortliche benennen, die überhaupt zeichnungs-/entscheidungsberechtigt sind oder wen man eigentlich im Notfall belangen kann?

Zum Schluss ging es dann noch um Dokumentation von Lizenzen/Nutzungsrechten von Bildern, die man vielleicht in Produkten/Webseiten seinen Kunden weiterverkauft hat. Sollte man auf jeden Fall besitzen, um im Fall einer Abmahnung des Kunden auf der sicheren Seite zu sein.

Frontend Prototype Integration

In der Session wurde gezeigt, wie man Twig als Template-Engine verwendet. Der Gedanke an dieser Art der Implementation war, dass die Frontend-Entwickler den Prototypen komplett unabhängig von TYPO3 entwickeln und man ohne weiteren Aufwand diese Templates dann in TYPO3 einbinden kann. Also ohne erneut diesen Code in irgendeiner Form anfassen zu müssen. 

Dafür wurden eigene Controller entwickelt, die sich komplett um die Datenaufbereitung kümmern und an die Twig-Templates dann nur noch ein Daten-Array schieben. In den Templates findet dann keine weitere Logik mehr statt, wie man sie zum Beispiel in der Integration von Fluid in TYPO3 findet. Zum Beispiel werden URLs direkt im Controller aufgelöst und nicht per ViewHelper wie in Fluid.

Interessante Herangehensweise jedenfalls, wenn man, wie in vielen großen Firmen üblich, strikt getrennte Frontend- und Backend-Entickler hat, wobei die erste Fraktion wirklich nur HTML/CSS/Javascript entwickelt. Meiner Meinung nach verschiebt sich hier aber nur der Aufwand und die Kommunikation nach vorne, da zwischen Back- und Frontend vorher noch klarer kommuniziert werden muss, welche Daten in welcher Form im View ankommen.
Von der Trennung zwischen Controller und View ist dies aber aber eigentlich zu begrüßen, weil streng genommen ja eigentlich keine Logik im View (außer Schleifen und Abfragen, ob Partials überhaupt abgefeuert werden sollen) vorhanden sein soll.

10 Tips for TYPO3 Upgrades

Sanjay Chauhan, CTO einer indischen TYPO3-Agentur, führte in zehn Punkten für Marketing, Entwickler und Integratoren Punkte auf, warum es wichtig ist, TYPO3-Installationen auf dem neuesten Stand zu halten, wie man vorgeht und welche Tools sie dafür so einsetzen. 

Im Marketing-Teil ging es vor allem um Argumente, Kunden die Vorteile (Sicherheit, Geschwindigkeit, neues Backend) schmackhaft zu machen. Für Integrator und Anwender gab es Einsichten, wie sie vorgehen, um die verwendeten Extensions, Core und Konfigurationen zu analysieren, um dann ein Upgrade-Konzept zu verfassen.

Mehr so grundsätzliches Wissen wurde vermittelt, was für den ein oder anderen bestimmt Neuland war, wenn man nicht täglich damit zu tun hat.

|TYPO3 CMS, Videospiele

Wolkenfetzen

Die Zeiten, als ich mit Hardware beschäftigt habe und genau wußte, welche Grafikkarte, welches Mainboard und welcher RAM gerade der heisseste Scheiss sind, sind schon lange vorbei. Mit Einzug von Apple-Geräten und auch dem Abflauen des Apple-Hypes, in dem man sich noch jede Keynote angeschaut hat, besteht die Notwendigkeit, sich mit diesen Themen zu beschäftigen, nicht mehr. Apple-Geräte sind einfach viel zu teuer, haben selten die neueste Technologie verbaut, funktionieren aber.

Früher hat man bestimmt auch den ein oder anderen Bekannten gehabt, der immer die neuesten Software-Cracks hatte, seine PlayStation 1 mit einem Mod-Chip versehen hat und sich Spiele aus der Videothek auslieh, um sie schnell zu brennen und einfach nur zu sammeln.

Der Wired-Artikel "The teens who hacked Microsoft´s Xbox empire" beschäftigt sich mit dieser Szene und einem speziellen Hacker, dessen Geschichte damals irgendwie an mir vorbeiging. Lag wahrscheinlich daran, dass ich noch nie eine Microsoft-Konsole mein Eigen nannte (PlayStations waren schon immer besser! ;-) ).

Dann gibt es noch ein Interview mit Matthias Schreiber, dem Geschäftsführer der TYPO3 GmbH, in dem man es in erster Linie um die Entwicklung und Ziele von TYPO3 9 geht. Sehr lesenswert.

|TYPO3 CMS

TYPO3-Projekte mit composer aufsetzen

Ich weiß nicht, ob es eine ultimative Art gibt, TYPO3-Projekte, in denen man selber Erweiterungen entwickelt, mittels composer aufzusetzen. Von daher beschreibe ich mal mein Setup und bin gespannt, wie man es besser machen könnte.

Allgemein gehe ich davon aus, dass eine Website auf Basis von TYPO3 entwickelt werden soll. Sprich: es wird TYPO3 CMS als Core-System verwendet, ein paar Extensions aus dem TER und dann noch ein paar Erweiterungen, die man selber entwickelt und die nicht öffentlich im TER verfügbar sind. Template-Erweiterungen und so weiter.

Für die Website gibt es dann ein Repository, in dem sich bei mir zwei composer.json-Dateien befinden, da ich Projekte momentan mittels TYPO3 Surf auf ein Test- und Livesystem deploye. Eine Datei heißt composer.json und ist für den Aufbau des Test- und Livesystems verantwortlich. Die andere Datei heißt composer-dev.json und verwaltet alle Abhängigkeiten für mein Entwicklungssystem. Warum ich nicht in der composer-Datei den "require-dev"-Zweig nutze, wird gleich klar.

{
  "repositories": [
    {
      "type": "composer",
      "url": "https://composer.typo3.org/"
    },
    {
      "type": "path",
      "url": "../_Extensions/*"
    }
  ],
  "name": "my-vendor/my-typo3-cms-distribution",
  "require": {
    "typo3/cms": "^8.7",
    "helhum/typo3-console": "^4.6",
    "vendor/my_extension": "^1.0"
  },
  "scripts": {
    "package-states": [
      "./vendor/bin/typo3cms install:generatepackagestates --activate-default"
    ],
    "folder-structure": [
      "./vendor/bin/typo3cms install:fixfolderstructure"
    ],
    "post-autoload-dump": [
      "@package-states",
      "@folder-structure"
    ]
  },
  "extra": {
    "helhum/typo3-console": {
      "install-extension-dummy": false
    },
    "typo3/cms": {
      "cms-package-dir": "{$vendor-dir}/typo3/cms",
      "web-dir": "web"
    }
  }
}

Im repositories-Zweig verweise ich auf den Ordner _Extensions, der sich auf gleicher Ebene wie das Projekt-Repository befindet. Hier kann natürlich auch auf ein projektbezogenen Unterverzeichnis verwiesen werden (mache ich auch so, habe es nur vereinfacht). In diesem _Extensions-Verzeichnis befinden sich die Repositories der Erweiterungen für dieses Projekt, die ich selber entwickele. In diesem Fall die Erweiterung my_extension. Diese Erweiterung besitzt natürlich auch eine entsprechend gepflegte composer.json-Datei um unter anderem das Autoloading zu gewährleisten, Abhängigkeiten aufzulösen und notfalls Umbenennungen vorzunehmen.

Mittels

COMPOSER=composer-dev.json composer update

wird das Entwicklungssystem aufgesetzt. TYPO3 Console übernimmt hierbei auch das Erstellen der PackageStates.php und erstellt notwendige Verzeichnisse. Meine Erweiterungen werden per Symlink in die jeweiligen Repository-Verzeichnisse aufgelöst. Erweiterungen aus dem TER werden wie gewohnt "normal" unterhalb von web/typo3conf/ext/ kopiert.

Nun kann ich in den jeweiligen Erweiterungs-Repositories entwickeln, versionieren, taggen und so weiter. Wenn ich einen Stand erreicht habe, der getestet oder sogar veröffentlicht werden soll, werden meine Erweiterungen beziehungsweise die Symlinks (per Bash-Skript) entfernt und folgende Composer-Datei aufgerufen:

{
  "repositories": [
    {
      "type": "composer",
      "url": "https://composer.typo3.org/"
    },
    {
      "type": "vcs",
      "url": "https://github.com/KaffDaddy/my_extension"
    }
  ],
  "name": "my-vendor/my-typo3-cms-distribution",
  "require": {
    "typo3/cms": "^8.7",
    "helhum/typo3-console": "^4.6",
    "vendor/my_extension": "^1.0"
  },
  "scripts": {
    "package-states": [
      "./vendor/bin/typo3cms install:generatepackagestates --activate-default"
    ],
    "folder-structure": [
      "./vendor/bin/typo3cms install:fixfolderstructure"
    ],
    "post-autoload-dump": [
      "@package-states",
      "@folder-structure"
    ]
  },
  "extra": {
    "helhum/typo3-console": {
      "install-extension-dummy": false
    },
    "typo3/cms": {
      "cms-package-dir": "{$vendor-dir}/typo3/cms",
      "web-dir": "web"
    }
  }
}

Wie man sieht, ist der einzige Unterschied im repositories-Zweig zu sehen. Hier müssen entsprechend alle Repositories der Erweiterungen angegeben werden, die installiert werden sollen. In diesem Fall ist es nur eine, aber das kann dann schon mal ausarten. Wenn man nun composer update ausführt, werden die Erweiterungen alle "normal" installiert.

|TYPO3 CMS

Deployment mit TYPO3 Surf

Den ganzen Tag entwickelt man tolle neue Features, die dann auf einem Testsystem abgenommen werden müssen oder das Licht der Welt auf dem Livesystem erblicken dürfen. Früher hat man dafür den FTP-Client angeschmissen, dann wurde es en vogue alles per SSH zu transferieren und irgendwann wurde alles so komplex, dass man noch Tests vorher ausführen oder das Autoloading von Klassen und Schnittstellen automatisieren wollte. Dadurch wurde dieser Prozess so aufgebläht und kompliziert, dass man gezwungen wurde, diesen auch von Software durchführen zu lassen, um ja nichts zu vergessen oder Fehler zu übersehen.
Neben Travis CI und Codeship gibt es noch für PHP Deployer, die einem auf die ein oder andere Art den Deployment-Prozess abnehmen.

Da TYPO3 das Beste System der Welt ist (höhöhö) gibt es hierfür noch aus den Zeiten von TYPO3 Flow das Deployment-Tool TYPO3 Surf, das unter der Obhut von Helmut Hummel (und ganz vielen anderen Entwicklern) gepflegt wird. TYPO3 Surf setzt darauf auf, dass ein Projekt auf Basis von git und composer erstellt wird und man noch die TYPO3 Console verwendet. Recht viele Anforderungen auf den ersten Blick. Aber wer setzt denn noch TYPO3-Installationen ohne composer auf?

Wie man composer und TYPO3 Surf installiert, wird bestens auf deren Seiten beschrieben und dann kann man sich von mir das Repository ziehen, in der alles vorhanden ist, um sich erstmal lokal eine Entwicklungsumgebung mit allen benötigten Dateien für ein Deployment mit TYPO3 Surf aufzubauen.
Das ganze Script ist noch nicht ganz fertig, es basiert leider darauf, dass eine Datenbank auf dem Livesystem mit den benötigten TYPO3-Tabellen existiert. Und die entsprechenden Konfigurationsdateien müssen auch erstmal in das eigene Repository. Von daher muss man leider noch folgende Schritte ausführen, bis man deployen kann:

  1. "composer install" ausführen, um erstmal lokal die TYPO3-Installation anstoßen zu können.
  2. Dann führt man wie gewohnt die TYPO3-Installation aus, damit wir die Datenbank erhalten, die auf das Livesystem importiert wird.
  3. In der Datei web/typo3conf/LocalConfiguration.php werden die entsprechenden Parameter für das Live-System gemacht, für das Entwicklungssystem werden die Parameter in der Datei web/Configuration/Development.php gesetzt. Diese wird verwendet, wenn man den Application-Context von TYPO3 auf Development während der Entwicklung setzt.
  4. Die Datei .surf/typo3-surf-base-installation.php muss auch noch angepasst werden. Hier müssen Hostname, SSH-User, der Pfad zur PHP-Datei, der Deployment-Pfad und das git-Repository gesetzt werden. Letzteres ist das eigene Repository, in der zwar ein Klon meines Repositories sitzt. Aber mit allen jetzt gemachten Änderungen in den Konfigurationsdateien.
  5. Die Änderungen werden in den Master-Branch des Repositories gepushed.
  6. Im Terminal der Wahl wird im Hauptverzeichnis des Repositories der Befehl "surf deploy typo3-surf-base-installation" ausgeführt. Sollte die Datei im Verzeichnis .surf umbenannt worden sein, den Befehl entsprechend anpassen.
  7. Staunen.

Zum Schluss muss nur noch der vHost-Eintrag des Livesystems auf den Ordner "releases/current/web" unterhalb des Deployment-Pfades verweisen und schon hat man sein erstes "deploytes" TYPO3-System. Viel Spaß.

In der kommenden Zeit werde ich mich noch damit auseinandersetzen, wie man die Datenbank auf dem Livesystem per Deployment und TYPO3 Console "frisch" hält und was vor allem bei zukünftigen Deployments zu beachten ist.

Update: Jan Kiesewetter von t3easy hat auf dem letzten TYPO3Camp in Stuttgart einen Talk zu TYPO3 Surf gehalten. Die Slides kann man sich bei ihm anschauen.

|TYPO3 CMS

Backendmodule von TYPO3 6.2 nach TYPO3 7.6 migrieren

Momentan migriere ich ein paar TYPO3-Installation von Version 6.2 auf die LTS-Version 7.6 als Zwischenschritt um dann auf die neue LTS-Version 8.7 gehen zu können. Dabei sind mir ein paar kleine Backend-Module vor die Füße gefallen, deren Sinn meistens darin besteht, Daten aufzubereiten und anzuzeigen oder eine Import-Schnittstelle für CSV-/XML-Dateien bereitstellen.
Eigentlich würde ich eher dazu tendieren, diesen Update-Schritt dafür zu nutzen, den bestehenden Code zu refakturieren um von piBase/AbstractController-Extensions zu Extbase-basierten Erweiterungen zu kommen. Das ist den meisten Kunden aber schlichtweg zu teuer, von daher bleibt einem manchmal nur übrig, den minimalen Weg zu gehen.

Ich habe diverse Backend-Module mit folgenden Klassen-/Namespace-Ersetzungen wieder zum Laufen bekommen. Diese Erweiterungen sind aber wirklich nur klein und auch nicht mehrsprachig gehalten. In dieser Beziehung konnte ich leider keine Erfahrungen sammeln.

$LANG => $GLOBALS["LANG"]

$BE_USER => $GLOBALS['BE_USER']

t3lib_SCbase => \TYPO3\CMS\Backend\Module\BaseScriptClass

t3lib_BEfunc => \TYPO3\CMS\Backend\Utility\BackendUtility

t3lib_div => \TYPO3\CMS\Core\Utility\GeneralUtility

$page = t3lib_div::makeInstance('t3lib_pageSelect'); => $page = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance('TYPO3\CMS\Frontend\Page\PageRepository');

$template = t3lib_div::makeInstance('t3lib_TStemplate'); => $template = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance('TYPO3\CMS\Core\TypoScript\TemplateService');

$this->doc = t3lib_div::makeInstance('mediumDoc'); => $this->doc = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance('TYPO3\\CMS\\Backend\\Template\\DocumentTemplate');

$this->doc = t3lib_div::makeInstance('template'); => $this->doc = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance('TYPO3\\CMS\\Backend\\Template\\DocumentTemplate');