Switch to PHP

Wir installieren uns ein MAMP-System

Jahrelang war ich stinkend faul und habe als Basis zum Entwickeln MAMP Pro benutzt. Weil ich keine großartige Lust hatte, mich mit dem Installieren und Pflegen von Apache, MySQL und PHP herumzuschlagen. Aber auch habe ich jahrelang geflucht, wenn ein Update der Software irgendetwas kaputt gemacht hat, die Dienste nicht mehr richtig liefen oder Konfigurationsdateien zerstört wurden und man den lauffähigen Zustand aus einem Backup wiederherstellen musste. Auch wenn diese Vorkommnisse in letzter Zeit weniger geworden sind.

Im Zuge meiner aluhutbedingten Einschränkungen meines Benutzerkontos auf einen Standardbenutzer unter macOS verweigerte MAMP Pro aber seinen Dienst, was seinen Ursprung wahrscheinlich darin hat, dass es Zugriff unter anderem auf die hosts-Datei haben möchte. Ich habe kurz geschaut, ob ich mich mit Vagrant oder Docker anfreunden könnte und ob die Entwicklung in virtuellen Maschinen in den Arbeitsablauf zur Agentur, in der ich arbeite, passt. Kurze Antwort: nein. Aus diversen Gründen verlagert man einfach nur das Problem der Versionierung und der Pflege des Systems in eine VM und erleichtert beziehungsweise verbessert man das Entwickeln dadurch nicht. VMs haben schon ihre Daseinsberechtigung wenn es darum geht so einen Container einfach in die Cloud zu packen und wenn dort Systeme laufen, die dadurch einfacher skaliert werden können.

Es sollte daher ein „natives“ Apache/MySQL/PHP-System auf macOS-Basis werden. Mit verschiedenen PHPs zum einfachen Wechseln, PHP-Cache und Xdebug. Letzteres bin ich noch schuldig, wie man den Rest recht einfach installiert bekommt, habe ich mal im Folgenden aufgeschrieben. Einfach die folgende Anleitung von oben nach unten abarbeiten und als Erfolg sollte man ein funktionierendes und stabiles System vorfinden. Dafür lege ich meine Hand aber nicht ins Feuer, kann nur sagen, dass es so bei mir geklappt hat.→ weiterlesen

MacBook und PhpStorm

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.

TYPO3 Aufbau

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?

TYPO3 8, Backend

TYPO3 8 unter Mac OS X anschauen

Was das beste Content Management System der Welt ist, ist ja unumstritten: TYPO3.
Die Weiterentwicklung hat in den letzten zwei Jahren subjektiv gefühlt merklich angezogen und ich finde, der Kern des Systems geht in die richtige Richtung. Version 8 setzt nun PHP7 voraus, was vollkommen in Ordnung geht, sieht man sich die Release-Zyklen und vor allem den Endpunkt des Supports von 5.5/5.6. Lustig an der Stelle ist, dass PHP auch wie TYPO3 seinerzeit eine komplette Versionsnummer aus ähnlichen Gründen unter den Tisch fallen lässt. Nämlich die Version 6, TYPO3 hat damals Version 5 (Codename Phoenix) begraben.

Mit Mac OS X 10.11 wird auch nur ein PHP 5.5 ausgeliefert, was leider dazu führt, dass composer keine Installation des dev-masters von TYPO3 ausführen möchte. Man muss also erstmal mit

1
curl -s http://php-osx.liip.ch/install.sh | bash -s 7.0

und

1
export PATH=/usr/local/php5/bin:$PATH

dafür sorgen, dass die Kommandozeile php in Version 7 ausführt. Die Liip AG aus der schönen Schweiz stellt ganz einfach einen Packager für die Installation bereit, dem ich einfach mal blind vertraut habe, keinen Schindluder zu betreiben. Ich weiß, das ist ziemlich sorglos, aber heute ist Montag.

Danach kann man sich mit composer und

1
composer create-project typo3/cms-base-distribution VERZEICHNISZUMPROJEKT dev-master

den aktuellen Master-Zweig installieren. Im Apache (oder Webserver seiner Wahl) den Host auf das Unterverzeichnis web zeigen lassen und schon kann es mit der Installation losgehen.