Beiträge aus der Kategorie: 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.

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-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.

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.

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');

Über den Weg Gelaufenes in KW12

Diese Woche lag im Zeichen des Frühlingsanfangs und irgendwie gab es wenig Artikel, die ich mir überhaupt zum Lesen markiert habe. Lag vielleicht aber auch daran, dass ich wenig dazu kam, meine RSS-Feeds zu scannen.

  • Wunschliste für die Integration von composer in TYPO3 Alexander Schnitzler hat auf Github einige Zeilen geschrieben, wie er sich selber die Integration von composer für TYPO3 vorstellt. Die Kommentare sind lesenswert, weil sie noch mehr Punkte aufgreifen.
  • Karabiner-Elements Tool, mit dem ich die Media-Tasten von macOS auf meine Pok3r-Tastatur legen konnte. Endlich.
  • Interview mit Donald Trump mit dem Time-Magazin Auf der einen Seite total faszinierend, wie so jemand Präsident eines riesengroßen und vor allem bunten Staat werden kann. Auf der anderen Seite beängstigend.
  • OpenEmu - Emulator für diverse Systeme Auf der Suche nach einem SNES-Emulator für den Raspberry Pi drauf gestoßen, ausprobiert und für gut befunden. Alte Spiele auf macOS mit dem PlayStation-Controller spielen. Wunderbar.
  • RetroPie - Emulator für den Raspberry Pi Ich habe es noch nicht ausprobiert, aber das scheint genau das zu sein, was ich für den Mini-Rechner benötige. Wenn das wirklich mit einem PlayStation-Controller zu koppeln ist, wird mein Sohnemann das hoffentlich wie ich hervorragend finden.
  • Der letzte Brand Faszinierendes Interview eines Workaholic und in Perfektion versessenen Mannes, der nicht zum ersten Mal alles hinschmeisst, weil es nur noch betriebswirtschaftliche Maximierung für seine Tätigkeit gibt. Nicht nur, dass ich Monkey 47 immer noch allen anderen Gins bevorzuge, weil er für mich die schönste, fruchtig-würzige Geschmacksnote hat, ich würde gerne mal so einen Williams aus seiner Brennerei probieren. Leider unbezahlbar.

Über den Weg Gelaufenes in KW8

Die letzte Woche war geprägt von Arbeit, selbst gemachtem Freizeitstress und irgendwie viel zu wenig Zeit zum Internet durchforsten oder Podcast hören. Von daher fällt die Liste recht unspektakulär und kurz aus.

  • GitKraken Ausprobiert und für gut befunden, auch wenn ich eigentlich keinen Standalone-Git-Client brauche, da mir der eingebaute Client in PhpStorm reicht. Ich werde dem Kraken aber die nächste Woche mal an seiner Stelle verwenden, vielleicht hat er ja das ein oder andere Feature, was mir mehr zusagt.
  • Anleitung zur Integration des CKEditors in TYPO3 Ich habe leider noch überhaupt keine Zeit gehabt, mir den neuen WYSIWYG-Editor von TYPO3 anzuschauen, obwohl ich den alten RTEHtmlArea mit aller Inbrunst hasse. Auch mal für nächste Woche vornehmen.
  • Cloudbleed Das schlug ja ein wie eine Bombe letzte Woche, auch wenn der nächste Punkt in der Liste viel schlimmer ist. Trotzdem hatte Cloudflare monatelang einen Fehler in seinem SSL-Proxy, der nicht nur den angeforderten SSL-Traffic zum Client auslieferte, sondern auch Teile des SSL-Verkehrs anderer User. Wenn da jemand sich die Mühe gemacht hat über diesen Zeitraum brav mitzusniffen, dürfte jemand jetzt über eine Menge Rohdaten mit Passwörtern und Kreditkarten-Informationen verfügen.
  • Zwei gleiche Hashes darf es nicht geben Ich habe es jetzt nicht überprüft, aber in der dunklen Erinnerung haben früher ziemlich viele Systeme ihre Hash-Verfahren auf SHA1 basieren lassen. Seit Jahren ist dies aber auf dem absteigenden Ast und wird durch andere Verfahren wie RSA ersetzt. Zum Glück.
  • Ist Zelda 1 das bessere Zelda? Ein Video, in dem erörtert wird, dass das erste Zelda das bessere Zelda ist. Weil es in erster Linie den Spieler nicht an die Hand nimmt, wie es fast jedes aktuelle Spiel macht. Ich sollte mir vielleicht doch einen NES Mini besorgen, um zu testen, ob das stimmt. Oder mal schauen, ob es das noch für den 3DS gibt. The Legend of Zelda habe ich zu meiner Schande noch nie gespielt.

Über den Weg Gelaufenes in KW7

An dieser Stelle fange ich mal an, meine Pocket-Liste zu entschlacken, in dem ich erwähnenswerte Sites in solchen Artikeln wochenweise zusammenfasse. Vielleicht gibt es ja den ein oder anderen, der auch gefallen an manchen Artikeln findet. Mich selber soll es dazu bringen, Dinge, die ich mir für später merken möchte, auch wirklich abzuarbeiten. Und sei es nur, sie einfach ungelesen zu löschen.
Den Anfang machen folgende Artikel:

Der wirklich beste Weg, TYPO3-Projekte zu verwalten

Anfang des Sommers hatte ich in einem Artikel meinen ungefähren Aufbau erklärt, wie ich komplexe TYPO3-Projekte, also komplette Installationen von einer oder mehreren Websites verwalte, an denen mehrere Entwickler gleichzeitig arbeiten. Gleichzeitig habe ich im Sommer diesen Aufbau auf den auf seine Funktionsweise überprüft und geschaut, was man verbessern kann. Und so langsam habe ich mein Setting verfeinert, dass ich zufriedener als vorher bin.

Meinen Aufbau, dass ich Extensions per Symlink unterhalb von typo3conf/ext einklinke, die außerhalb des eigentlichen Document-Roots liegen. Das hat sich schon immer als fehlerhaft erwiesen, da TYPO3 nicht wirklich den Symlinks folgt, was darin ausartet, dass Controller nicht geladen werden. Da die meisten selber entwickelten Extensions sowieso kunden- bzw. projektbezogen sind und selten in mehreren Projekten gleichzeitig verwendet werden, werden diese Erweiterungen jetzt direkt per git unterhalb von typo3conf/ext geklont, das Verzeichnis aber aus dem Gesamtprojekt per gitignore ausgeklammert. Die eigentliche TYPO3-Installation wird weiterhin von composer verwaltet, mit dem die üblichen "normalen" Extensions aus dem TER gezogen werden.

Auf einem Testsystem, das grundlegend in gleicher Weise aufgebaut ist wie das Livesystem werden per composer dann nicht nur die TER-Extensions, sondern auch die selber entwickelten Extensions eingebunden. Das geht wunderbar von der Hand und ermöglicht auch die Kontrolle über den Quellcode auf dem Testsystem, da kein Entwickler mehr direkt Code auf dem Testsystem ändern kann bzw. es beim nächsten Update auffällt. Und es dann auf die Finger gibt.

Im nächsten Schritt werden sich jetzt noch Automatic deployment auf Datei- und vor allem Datenbankebene vorgeknöpft, um noch einen Rattenschwanz abzuschlagen, um dem man sich immer kümmern muss. Zeit, die einem zum Entwickeln fehlt und Vorgänge, die immer fehlerbehaftet sein können.

Der beste Weg, um TYPO3-Projekte zu verwalten

Eine anständige Versionsverwaltung von Quellcode ist meiner Meinung nach einer der Grundpfeiler, um funktionalen und vor allem fehlerfreien Code zu schreiben. Vor allem im Team mit mehreren Entwicklern und Projektmanagern.
Aber wie baut man auf Dateiebene ein komplettes TYPO3-Projekt auf? Wie verwaltet man Extensions aus dem TER? Wie bindet man Eigenentwicklungen ein? In den letzten Jahren habe ich für meine Projekte einen entsprechenden Aufbau und Ablauf entwickelt, den ich gerade auf den Prüfstand stelle, um ihn zu verbessern. Verbessern kann man ja immer.

Das gesamte Projekt basiert auf composer und bindet nicht nur die TYPO3-Sourcen, sondern auch alle per TYPO3 Extension Repository Composer Repository erreichbaren Extensions ein. Der Code, der dadurch eingebunden wird, wird per gitignore aus dem Projekt-git ausgeschlossen, Erweiterungen, die nicht per composer installiert werden können, landen aber dann doch in der Versionsverwaltung. Damit alle Entwickler mit dem gleichen Versionsstand arbeiten.

Nur was ist mit den Erweiterungen, die man selber entwickelt und die nicht im TER landen? Man könnte sie natürlich auch per composer und einer eigenen Repository-Verlinkung integrieren. Jede Erweiterung wird in einem separaten git versioniert und in der composer.json lassen sich eigene Repositories verlinken und per require einklinken. Nur heißt das auch, dass man Entwicklungen in den Extensions nicht in diesem Projekt vornehmen kann. Von daher finde ich das zwar den eigentlich konsequenten Weg, der aber so nicht praktikabel umgesetzt werden kann. Man müsste nach Änderungen die Änderungen per composer einladen, um die "Auswirkungen" im Projekt zu sehen und zu testen. Mühsam und zeitaufwendig.

Ich bin dazu übergegangen, die Erweiterungen per Symlink unterhalb von web/typo3conf/ext einzubinden. Der Code liegt außerhalb des Projekt-Verzeichnisbaums in seiner eigenen git-Struktur. Entwickelt wird dann in einer separaten IDE-Instanz. So sind Änderungen in der Erweiterung sofort im eigentlichen TYPO3-Projekt sichtbar, die Repositories aber voneinander getrennt.

Nur bin ich mir nicht mehr so sicher, dass es der beste Weg ist, ein komplettes Projekt zu verwalten. Und ihr so?