Beiträge aus der Kategorie: Webentwicklung

Globales Ignorieren

Es gibt nichts Schlimmeres als fremde IDE-Konfigurationsdateien in einem Repository. Damit ich meine IDE-Konfiguration auch nicht anderen Entwicklern aufdrücke, gibt es eine globale gitignore-Datei, in der wenigstens folgende Zeilen erstmal enthalten sind:

.DS_Store
.idea

Die Datei kann man nennen wie man möchte, muss sie dann lediglich per

git config --global core.excludesfile ~/.gitignore_global

der globalen git-Konfiguration mitgeben.

Von Stöckchen und Software

Vor fast 15 Jahren habe ich ein neues Laptop kaufen wollen und auf der Suche nach einem vernünftig verbauten und soliden Case haben mich die aus Aluminium bestehenden Gehäuse der MacBooks angelacht. Ich kannte zwar den Ein oder Anderen durch die Arbeit mit Agenturen, der mit macOS gearbeitet hat, aber so richtig haben mir nur die ganzen Blogs geholfen, die im deutschsprachigen Raum zu dieser Zeit erblühten.

Damals hat man noch mit Stöckchen geworfen und in der Sidebar Blogrolls gepflegt, um andere auf lesenswerte Seiten aufmerksam zu machen. Und kommentiert. Twitter (oder eher twttr) war in der Pre-Smartphone-Zeit noch unbekannt und auf StudiVZ/Facebook... naja.

Aber es gab unzählige Blogs, die sich mit macOS und der Software dafür beschäftigten. Man bloggte, wie sein System aufgesetzt ist, wo man gerade irgendwelche Rabatte für den Einkauf von Software bekam und so weiter.

Da ich mir gerade durch einen Jobwechsel einen neuen Laptop aussuchen durfte und ich die letzten zwei Jahre wegen eines Windows-Systems geflucht habe, bin ich echt dankbar, dass ich diesen Text auf macOS schreiben darf. Hätte es WSL2 nicht gegeben, wäre ich schon im letzten Jahr mit dem Auto über das Laptop gefahren. Nachdem ich es angezündet und aus einem Hochhaus geworfen hätte.

Und es gibt fast nichts Schöneres als ein neues macOS einzurichten. Ich hätte zwar das Profil und die Software von meinem privaten MacBook während der Installation übertragen können, aber irgendwie war es mir wichtig, das Ganze frisch aufzusetzen. Und da mache ich es doch wie vor 15 Jahren und schreibe auf, was ich so alles installiert habe.

Die erste App, die ich installiert habe, ist iA Writer, mit der ich diesen Text auch schreibe. Schon seit Jahren meine Wahl für Texte schreiben, aber auch Notizen finden hier ihren Platz.

Und dann kommt neben dem ganzen Entwicklerkram das Wichtigste: die Shell. Keine Ahnung, es soll immer noch Entwickler da draußen geben, die so gut wie keine Berührung mit Shells haben, ich kann gar nicht ohne. macOS kommt ja seit 10.15 mit zsh als Standard-Shell daher. Ich haue da noch iTerm2 und oh-my-zsh drauf und in Verbindung mit meiner geliebten Konfiguration, Syntax-Highlighting, Autosuggestions und einem schönen Theme will ich eigentlich gar nicht raus. Aus ihr.

Was schon bei der Installation der Shell nicht fehlen darf, ist Homebrew. Ein Paketmanager für macOS und in Verbindung mit dem AppStore von Apple braucht man eigentlich keine weiteren Quellen mehr, um Software zu installieren.

Neben den üblichen verdächtigen Browsern und Firefox als Standard-Browser, kommen dann noch Tweetbot (Links lasse ich jetzt einfach mal aus Bequemlichkeit weg, ihr könnt ja bestimmt Suchmaschinen bedienen), Slack, Discord und Signal, sowie ReadKit auf den Rechner, um mit der Außenwelt zu kommunizieren und Feeds abzugreifen.

Mit Thunderbird versuche ich mal wieder warm zu werden. Sonst gefallen mir auf macOS eigentlich bisher gar keine Mail-Clients. Die Hübschen haben zu wenig Funktionen wie Verschlüsselung und die Funktionalen sehen alle scheisse aus.

Neben den üblichen Tools wie 1Password (auch wenn die gerade böse geworden sind) und Lastpass für das Passwort-Management, Things für ToDos (obwohl ich das eigentlich kaum noch benutze, es spielt sich ja zum Glück alles in Ticketsystemen ab), odrive für das Handling aller Cloud-Dienste, VLC für Videodateien und Pixelmator für Bilder, werkelt dann noch Little Snitch herum. Ja, ist ne Software-"Firewall", aber zum Placebo-Blocken von Ressourcen ist es halt was fürs "besser fühlen".

Die GPG Suite fürs Verschlüsseln (Keybase ist ja auch böse geworden und hat sowieso kaum einer genutzt) und Tunnelblick für die VPNs. Achso, Moom als Fenstermanager. Warum Apple sowas immer noch nicht in macOS integriert hat, ist mir schleierhaft. Die ganzen Standardtools wie einen PDF-Reader und Office... geschenkt.

Kommen wir nun zum eigentlich Wichtigsten: dem Enwicklerkram. Da ich die meiste Zeit PHP schreibe, sollte es nicht verwundern, dass PhpStorm meine IDE der Wahl ist. Mit VSCode mögen Frontendler klarkommen, mir reicht das aber nicht. GitKraken ist der schönste Git-Client, da lasse ich mir nichts anderes erzählen und mit Sequel Ace kann man schön Datenbanken kaputtmachen. Atom ist auch dabei, aber wirklich nur im Notfall einen einfachen Text-Editor starten zu können. Und ja, ich habe sogar noch Transmit installiert. In der Hoffnung, es nie brauchen zu müssen.

Neben der Installation von Docker und DDEV habe ich dann noch git aktualisiert (die Version von macOS ist zwar halbwegs aktuell, aber neuer und sicherer ist immer gut) und sowas wie wget/curl kann man auch immer gebrauchen.
So bin ich schon mal bereit, da kommt aber mit der Zeit bestimmt noch mehr Software nach.

Gib dem Code Statik

Ja, ich weiß, Statik und statische Code Analyzer haben in erster Linie nicht viel miteinander zu tun, aber im Endeffekt wird Code durch deren Verwendung trotzdem um einiges besser. Härter. Und tragen somit zu einem soliden Code-Gerüst bei, das unsere Anwendungen noch stabiler und besser macht.

Wie Roland Golla in der 5.2021 vom Entwickler Magazin schreibt: "Legacy-Code macht krank." In seinem Artikel geht es um PHPStan. Wie man diesen Static Code Analyzer in seine Entwicklungsumgebung (und damit ist nicht nur die IDE gemeint) einbinden kann, um nicht nur bisher unentdeckte Fehlerquellen zu finden, sondern um seine Fähigkeiten und vor allem sein Wissen als Entwickler zu verbessern.

Man kann einfach nicht alles wissen, die Entwicklung in PHP findet auch in immer kürzeren Releaes-Zyklen statt. Auf der anderen Seite pflegt man die in die Jahre gekommenen Anwendung des Kunden. So muss jeder Entwickler eine ungeheure Bandbreite von Features abdecken, die einem die im jeweiligen Projekt eingesetzte PHP-Version zur Verfügung stellt.

Das unfassbar schöne und immer wieder faszinierende am Beruf eines Softwareentwicklers ist in meinen Augen, dass man jeden Tag etwas lernt. Wirklich jeden Tag. Und Tools wie Static Code Analyzer helfen einem dabei. Ich glaube jeder kennt das Gefühl, wenn man Code von vor drei, vielleicht vier Jahren anschaut, den Kopf schüttelt und dann nach einem beherzten "git blame" am liebsten im Boden versinken möchte, wenn man feststellt, dass man selber diesen Legacy Code produziert hat.

Static Code Analyzer setzen hier schon beim ersten Entwickeln an und helfen einem, sehr viel sauberen Code zu schreiben. Sie helfen einem jetzt nicht unbedingt, bessere Programm-Logiken zu schreiben, man kann also immer noch die Business-Logik so dermaßen unnütz verschachteln und schwer zu verstehen umsetzen. Aber hey, dafür gibt es ja wiederum andere Tools wie Performance Profiler (Blackfire usw.), die man auf dieses Problem werfen kann.

Ich kann jedem eigentlich nur Tools wie PHPStan, rector, Psalm usw. neben den hoffentlich schon seit Jahren verwendeten Tools wie PHP-CS-Fixer oder PHPMD ans Herz legen. Um Code zu analysieren, zu refactoren und vor allem zu lernen. Quasi als Pair-Programming mit einem Tool und nicht mit einem anderen Entwickler. Oder als Code review vor dem eigentlichen Code review.

Disclaimer: Roland Golla hat mir die oben erwähnte Ausgabe kostenlos zur Verfügung gestellt, wofür ich ihm herzlich Danke. Print-Produkte habe ich schon lange aus den Augen verloren, wenn es um Programmierung oder Themen im Web geht. Es war aber mal wieder eine wunderbare Erfahrung, beim Lesen Papier in der Hand zu haben. Ich werde jetzt zwar kein Abo abschließen, aber sollte ich mal wieder irgendwelche Reisen per Bahn oder so unternehmen, werde ich am Bahnhofskiosk auf die Suche nach solchen Zeitungen gehen. Ansonsten kann ich euch seinen YouTube-Kanal "Never Code Alone" ans Herz legen, den ich regelmäßig verfolge. In seinen Videos geht es vor allem um Testing, Refactoring und allgemeinen Themen rund um das Entwicklerdasein.

2021-2

In Zukunft möchte ich einmal die Woche die besten und nützlichsten Artikel/Websites in einer Liste zusammenfassen, um auf der einen Seite meine Liste an noch zu lesenden Artikeln in Pocket klein zu halten und vielleicht hilft es auf der anderen Seite dem ein oder anderen. Wenn jemand überhaupt mein Blog liest. Was ich nicht annehme.

Fangen wir also an:

  • Xdebug bzw. eigentlich die Sponsoring-Seite von Derick, dem Maintainer und Erfinder des besten Debug-Tools für PHP. Los! Unterstützen! Denn auch Entwickler wollen Geld verdienen.
  • TYPO3 Rector: eigentlich wollte ich meinen Urlaub über die Feiertage für ganz viel Lernen und Anschauen nutzen, nur kam wie es so nun mal so ist ganz anders. Wird aber für das nächste Refactoring/Migration verwendet und werde darüber bestimmt berichten
  • Laragon: ich bin ja strenger Verfechter von DDEV als Serverumgebung für die lokale Entwicklung für TYPO3. Laragon möchte scheinbar so etwas ähnliches sein. Leider auch noch nicht angeschaut, weil ich halt auch mit DDEV mehr als zufrieden bin
  • Ein schöner "Früher war alles besser (anders)"-Artikel über die OpenSource-Entwicklung: The Golden Age of Open Source is Over

Alles muss raus

Im letzten Jahr, das man nicht beim Namen nennen darf, hatte ich so viel vor und echt mal wenig davon geschafft. Irgendetwas mache ich nämlich falsch (oder anders) als alle anderen, die auch im HomeOffice waren und gefühlt dauernd Freizeit hatten oder wenigstens sowas von tiefenentspannt waren, dass ich im Spätsommer mit Meditation angefangen habe, um auf das gleiche Level zu kommen. Das mit der Meditation habe ich dann schnell wieder verworfen, das klappt bei mir einfach nicht. Da muss man scheinbar genauso wie bei Homöopathie dran glauben und dafür ist mein Gehirn einfach nicht gemacht.

Zum Bloggen bin ich dann nämlich auch nicht gekommen, wie ich mir das so vorgenommen hatte. Einfach mal Texte schreiben. Für mich. Und die ins Internet stellen. Warum auch immer. Weil man das im frühen Internet auch so gemacht hat. Wo das Internet noch nicht ganz so kaputt war wie heute.

Vielleicht werde ich sogar demnächst hier eine Blogroll veröffentlichen, denn es gibt sie immer noch! Die kleine Blogosphäre und auch die Tech-Blogger. Anfangen werde ich aber mit einer Auswahl von Artikeln und Websites, die ich im letzten Jahr in Pocket abgespeichert und mit Vergessen gestraft habe. Von den knapp 300 Einträgen habe ich diese mal hier gelassen, vielleicht findet der ein oder andere ja noch was, was ihn weiterbringt.

Webdesign

TYPO3

DevOps

PHP

Programmierung allgemein

Geschwindigkeit ist alles

Es gibt ja für alles Untersuchungen. Auch dafür, wie sich die Ladezeit einer Website auf die mögliche Absprungrate der Besucher auswirkt. Und man mag es kaum glauben, aber die Erkenntnis ist, dass je länger eine Website zum Laden benötigt, desto höher ist die Chance, dass der Besucher den Tab schließt. Unglaublich.

Man sollte also alles daran setzen, dass eine Website so schnell wie möglich ausgeliefert und vor allem angezeigt wird. Mal abgesehen, dass man dafür sorgen sollte, dass Elemente im sichtbaren Bereich zuerst gerendert werden und schon gar nicht während des Ladens hin- und herflippen sollten, ist ein weiterer Faktor, den man ganz gut beeinflussen kann, die Anzahl und vor allem die Größe der Ressourcen wie Stylesheets und JavaScript so gering wie möglich zu halten.

Mit TYPO3 10.3 ist hierfür der AssetCollector integriert worden. Mit diesem können Skripte und Stylesheets in Fluid-Dateien mit den Viewhelpern f:asset.script und f:asset.css dem Renderingprozess hinzugefügt werden. Und das ähnlich dem schon in 8.6 hinzugefügten renderAssetsForRequest, mit dem man über die beiden Fluid-Sections HeaderAssets und FooterAssets entsprechenden Code rausrendern konnte.

Der entscheidende Unterschied ist, dass, wie der Name schon vermuten lässt, der AssetCollector die Stylesheets und Skripte erstmal sammelt und dann nur einmal im Rendering inkludiert. Heißt, ich kann in diversen Fluid-Dateien mit dem gleichen Namen auf die gleiche JavaScript-Datei referenzieren, die ich zum Beispiel für einen Slider benötige, die dann aber am Ende des Dokuments nur einmal per Script-Tag im Dokument hinterlegt wird.

Ein weiterer Vorteil ist, dass man auf diese Art und Weise dafür sorgen kann, dass nur benötigte Ressourcen an den Browser gesendet werden und nicht ein JavaScript-Plugin für ein Akkordeon, welches gar nicht auf der Seite vorhanden ist. Natürlich hebelt das ein wenig das Konzept aus, dass man eigentlich immer die gleichen Ressourcen an den Browser sendet, damit dieser diese auf der zweiten Seite gar nicht mehr anfordert, weil er sie dann aus seinem Cache nimmt.

Aber mit der gleichzeitigen Verwendung von HTTP/2, das dafür sorgt, dass die Ressourcen zum Rendern der Website an den Browser ausgeliefert werden, bevor dieser überhaupt weiß, dass er sie benötigt, wird in Verbindung mit der geringen Datengröße trotzdem ein Geschwindigkeitsvorteil erzielt, der sich vor allem in einem schnelleren Rendering der Seite bemerkbar macht. Dabei ist es gar nicht schlimm, dass die Ressourcen nicht im Concatenate- oder Komprimierungs-Prozess von TYPO3 integriert werden, wie man das ja bisher gewohnt war, wenn man seine Ressourcen mittels TypoScript eingebunden hat.

Und schon hat man wieder ein paar mehr Besucher seiner Website glücklicher gemacht.
Und ja, ich weiß, hier auf der Seite habe ich leider noch kein HTTP/2 aktiviert. Liegt nicht an mir. Tut mir leid.

DDEV auf dem Webmontag

Letzten Montag hat es mich nach einer längeren Pause wieder auf den Webmontag Kassel verschlagen. Als Entschuldigung habe ich auch eine Session über DDEV gehalten, die ich leider nicht so gut vorbereiten konnte, wie ich mir das vorgestellt hatte. Sie wissen schon: Familie, Wochenende und alles, was so dazwischenkommt.

Meine Folien kann man hier einsehen, die der anderen Sessions sind bestimmt auf der MeetUp-Seite zu finden. Die Vorträge über Ethical Design, GraphQL und Event Storming waren klasse und das Format des Webmontags so als kleines Appetithäppchen zwischen den ganzen Konferenzen und Barcamps, die man so verfolgen kann, genau richtig.

Hacktoberfest 2018

Open Source lebt ja nicht nur von der Idee, dass die Software quelloffen und damit für jeden einseh- und bewertbar ist, sondern auch davon, dass die Möglichkeit gegeben sein kann, dass jeder mitmachen kann. Jedenfalls, wenn der Autor der Software mitmacht und sogenannte "Pull Requests" entgegennimmt.
"Pull Requests" sind Quellcode-Schnippsel (oder auch Assets), die von Entwicklern beigesteuert werden können, die keine Schreibrechte im Repository haben. Sie dienen vor allem dazu Bugs zu beseitigen, aber auch um Features ein- oder auszubauen. Oder um Dokumentationen zu pflegen.

Das Hacktoberfest wird 2018 zum fünften Mal von GitHub und DigitalOcean organisiert (und dieses Jahr ist auch zum ersten Mal Twilio als Supporter dabei) und zelebriert einen Monat lang Open Source Software. Man kann daran weltweit teilnehmen, indem man im Oktober fünf Pull Requests in offenen Projekten auf GitHub postet. Die müssen noch nicht einmal angenommen werden, nur sollten sie nicht in Fake-Repositories landen oder aus Spam bestehen.

Meine Pull-Requests sind bis jetzt in die Repositories von Oh My Zsh, DDEV und gitignore.io gewandert. Vielleicht finde ich diese Woche auch noch ein wenig Zeit. Am Freitag gab es jedenfalls noch ein Hacktoberfest-Meetup in den heilligen Hallen der Micromata hier in Kassel, bei dem ich auch ein paar Stunden anwesend war. Hat Spaß gemacht und wieder Lust gemacht, die Webmontage zu besuchen, die dort auch abgehalten werden.

Oh my shell!

Für mich ist das wichtigste Werkzeug nach einer Entwicklungsumgebung eine gut funktionierende Shell. Ohne diese könnte ich diverse Dinge in meinem täglichen Workflow gar nicht oder nur schwer umsetzen. Klar gibt es eigentlich für alle Befehle, die man in einer Shell abfeuert, in der ein oder anderen Weise eine Ersetzung in Form von graphischen Oberflächen oder Integrationen in die IDE, aber diese sind entweder kompliziert zu konfigurieren oder bieten in den meisten Fällen nur einen geringen Teil der notwendigen Befehle oder Parameter.

Die Zeiten, in denen so eine Shell nur aus einem blinkenden Cursor bestand, man sich mühsam die Syntax von Befehlen merken musste und sie sich gefühlt nicht in den Workflow integrieren lies, sind auch vorbei. Und mit "Oh My Zsh" existiert sogar noch ein "Konfigurations"-Framework, das eigentlich keine Wünsche offen lässt, weil man es einfach selber erweitern kann.

Zwar kann man Oh My Zsh auch im Terminal von macOS verwenden, aber wenn man schon mal dabei ist, kann man ja auch gleich noch einen Ersatz dafür installieren: iterm2. Ein Ersatz für das macOS-Terminal, das neben einer Suche, Profilen und einer Historie über seine unzähligen Parameter so konfigurierbar ist, dass es sich wie bei Quake von oben öffnet. Was will man mehr?

Installation

Man sollte erstmal Homebrew installieren, danach kann man mit

brew cask install iterm2

iterm installieren. Und dann gleich noch mit folgendem Befehl "Oh My Zsh" nachinstallieren:

sh -c "$(curl -fsSL raw.github.com/robbyrussell/oh-my-zsh/master/tools/install.sh)"

Konfiguration

Fangen wir mal an erstmal iTerm2 etwas aufzuhübschen: Material Design Colors, "Quake-Console"-Shortcut und besser lesbare Schriftart.

Das Farbprofil für die Material Design Colors kann man sich hier herunterladen und diese dann in den Einstellungen unter Profiles > Colors in der Selectbox unten rechts "Color Presets..." importieren und auswählen.

Um ein Terminalfenster so ähnlich wie das Terminal bei Quake von oben herunter aufgehen zu lassen, erstellt man unter dem Reiter Profiles ein neues Profil mit ähnlichen Einstellungen wie im Bild zu sehen. Die wichtigste Einstellung ist bei Style den Wert "Full-Width Top of Screen". 

Dann noch im Reiter "Keys" im Bereich "Hotkey Window" einen Shortcut definieren und dann fehlen nur noch ein paar Schriften, die man sich hier auf GitHub runterladen kann. Ich verwende für alle Fenster folgende Schriftart

12pt Meslo LG M DZ Regular for Powerline

Dann kommen wir zu "Oh My Zsh", das ganz einfach per Textdatei konfiguriert werden kann. In iTerm2 einfach folgenden Befehl ausführen oder die Datei im Editor seiner Wahl öffnen:

vi ~/.zshrc

In der gut dokumentierten Datei kann man neben dem Theme (ich verwende "awesomepanda") auch eine Menge Plugins installieren, die einem sehr viele nützliche Shortcuts und Tools zur Verfügung stellen. Eine Liste, welche Tools verfügbar sind, kann man hier einsehen. Ich verwende folgende Konfiguration:

plugins=(
brew
composer
docker
dotenv
git
osx
urltools
web-search
)

Ansonten lohnt es sich, Shortcuts/Aliase für Befehle in dieser Datei abzulegen. Welche gerade aktiv sind, kann man sich mit "alias" anzeigen lassen.

Ordentlich debuggen mit Xdebug und PhpStorm

Es gibt ja nichts Schlimmeres, als Code nicht ordentlich debuggen zu können. Nicht nachvollziehen können, warum der vermaledeite Code, den man gerade mit Herzblut und Schweiß geschrieben hat, verdammt noch mal nicht das hinten rauswirft, was er soll.

Da PHP größtenteils zur Laufzeit und dann auch noch von einem serverseitigen Daemon beziehungsweise Webserver interpretiert wird (Caches jetzt mal außen vorgelassen), benötigt man eine Erweiterung in Form von Xdebug, die sich dazwischen schaltet und Informationen an die IDE liefert. Unter macOS kann man das Installieren sowieso recht bequem per Homebrew erledigen:

brew install php71-xdebug

Wie man den Rest (Apache, MySQL und PHP) installiert, hatte ich hier mal beschrieben, auch wenn man anstelle der MariaDB lieber Mysql 5.6 installieren sollte.

Okay, zurück zu Xdebug, dass zwar jetzt schon installiert, aber noch nicht konfiguriert ist. Im Verzeichnis /usr/local/etc/php/7.1/conf.d sollte sich die Datei ext-xdebug.ini befinden, in die man folgendes schreiben sollte:

[xdebug] zend_extension="/usr/local/opt/php71-xdebug/xdebug.so" xdebug.max_nesting_level = 500 xdebug.idekey = PHPSTORM xdebug.remote_host = 127.0.0.1 xdebug.remote_enable = 1 xdebug.remote_port = 9000 xdebug.remote_handler = dbgp xdebug.remote_mode = req xdebug.auto_trace=1 xdebug.collect_includes=1 xdebug.collect_params=1 xdebug.collect_return=1 xdebug.extended_info=1

Da Xdebug sich nach meinem Gefühl schon verlangsamend auf den PHP-Interpreter auswirkt, auch wenn kein aktiver Debugging-Prozess läuft, installiert man sich am Besten noch den Xdebug Toggler per

brew install xdebug-osx

Danach kann man dann per

xdebug-toggle on/off

Xdebug einfach ein- und ausschalten. Schlußendlich installiert man dann noch den Xdebug Helper in Chrome oder dem Browser seiner Wahl.

Fehlt jetzt nur noch die Konfiguration von PhpStorm und das Mapping von TYPO3-Core bzw. Erweiterung. Nehmen wir einfach an, dass eine Erweiterung debuggt werden soll die per composer in ein TYPO3-Projekt eingebunden ist. Ich verwende composer bei der Entwicklung von Erweiterungen so, dass zu entwickelnde Erweiterungen als Symlink eingebunden sind, damit sich die git-Repositories nicht in die Quere kommen. Könnte man auch mittels Submodule realisieren, aber ich mache es halt am Liebsten so.

In PhpStorm sollte man in der Konfiguration unter Languages & Frameworks > PHP > Debug die Optionen

  • Force break at first line when no path mapping specified
  • Force break at first line in when a script is outside the project

entfernen. Zusätzlich sollte man in den Einstellungen von PhpStorm unter Languages & Framework > PHP die korrekte Version und Cli-Interpreter angegeben und das "vendor/typo3/cms"-Verzeichnis als "External Library" eingebunden haben.

Wenn man nun die Debugging-Session in PhpStorm aktiv schaltet und zum Beispiel das Frontend von TYPO3 neu lädt, sollte sich PhpStorm mit einem Mapping-Hinweis zu Wort melden und auch gleich entsprechende Dateien zur Auswahl geben. Für das Frontend wählt man am Besten die index.php aus dem Hauptverzeichnis des TYPO3 Cores.
Fröhliches Debuggen!