Das ist wieder so ein Fall von „ich kann es mir nicht merken und die Google-Suche liefert immer die falschen Ergebnisse“.

Früher konnte TYPO3 nur Seitentitel der Form [Sitename]: [Seitentitel] generieren. Die einzige Möglichkeit, das zu ändern, bestand darin, die Option config.noPageTitle zu aktivieren und den Titel unter headerData selbst zusammenzustellen. Dabei gibt es schon seit langem Konfigurationsmöglichkeiten für den Seitentitel. Zum einen kann man die Reihenfolge einstellen, zum anderen kann man den Trenner angeben.

Ich war mir nicht sicher, wie die dafür notwendigen Konfigurationen heißen, daher wollte ich mal die Suche im Internet bemühen. Aber die Google Suche leitet mich nur auf Seiten mit dem config.noPageTitle Beispiel. Dabei ist es so einfach:

config {
    pageTitleFirst = 1
    pageTitleSeparator = -
    pageTitleSeparator.noTrimWrap = | | |
}

Ergebnis:
Meine Site - Seite ABC

Ja, es gibt Anleitungen da draußen, in denen das drin steht. Ich kann es mir einfach nicht merken … weder den Link noch den Inhalt.

Projekt-Ordner erstellen
mkdir spielwiese11

In Projekt-Ordner wechseln
cd spielwiese11

Ddev Projekt initalisieren
ddev config
Es kommen ein paar Fragen, bei docroot „public“ eingeben und bei Project type „typo3“.

Ddev starten
ddev start

In Ddev wechseln
ddev ssh

TYPO3 per Composer installieren
Hier ist der TYPO3 Composer Helper sehr hilfreich. Einfach die Version auswählen, die installiert werden soll (Minimal, Default oder Full), kopieren, einfügen und ausführen.

Dann kann man die Seite bereits unter https://spielwiese11.ddev.site aufrufen und den Rest im Browser erledigen.

Quellen:
https://docs.typo3.org/m/typo3/guide-contributionworkflow/main/en-us/Appendix/SettingUpTypo3Ddev.html

Ich arbeiten ja nun bereits seit mehreren Jahren (seit 2007?) mit TYPO3 und dachte, dass ich schon fast alles gesehen hätte an Implementierungen und Ansätzen. Immer wieder werde ich überrascht von kreativen Ansätzen mancher Entwickler und Agenturen und stelle fest, dass ich auf solche Ansätze nicht gekommen wäre. Es gibt in der Programmierung nicht die eine „Wahrheit“ (auch wenn manche gerne so tun als ob), sondern mehrere Lösungsmöglichkeiten für ein Problem. Manchmal denke ich darüber nach, ob in einem bestimmten Fall mein gewählter Ansatz der richtige ist. In der Retrospektive stelle ich dann bei fast allen Projekten fest, dass ich es aus heutiger Sicht anders gemacht hätte – und das ist auch gut so, das bedeutet, dass man sich persönlich weiterentwickelt hat. Als Freelancerin habe ich Einblick in viele Projekte, an denen vorher andere Agenturen oder Freelancer gearbeitet haben und manchmal würde ich (gelegentlich nach stundenlangem Fluchen) diese gerne fragen, warum sie dieses oder jenes so umgesetzt haben und nicht anders.

Das sind grob die Szenarien, die mir bisher begegnet sind

1) Nicht konfigurierbare Zielseiten/Texte/E-Mail-Adressen etc.
Wenn man schon dabei ist, einen Text oder eine E-Mail-Adresse einzugeben, sollte man sie nicht per TypoScript/Flexform/Datenbank-Feld konfigurierbar machen? Natürlich ist es schön, noch etwas Geld zu verdienen, wenn der Kunde eine Textkorrektur haben möchte oder die E-Mail-Adresse sich geändert hat. Habe ich dazu Lust? Nein.

2) Keine Verwendung von TYPO3 (Core) Konfigurationsmöglichkeiten
Man kann sich in TYPO3 mittels TSconfig doch zu Tode konfigurieren – was ich gerne nutze. Wenn das nicht hilft, gibt es doch Hooks und man kann auch direkt in ext_localconf und ext_tables konfigurerieren. Mit Backend Layouts und Content Defender kann man mittlerweile ziemlich genau einschränken, welche Inhaltselemente in welchen Spalten erlaubt sind. Letztens bin ich über eine Extension gestolpert, die den Content Element Browser und die Auswahl der Inhaltselemente (mit Hooks, höhö) kompett umgeschrieben hat. Welche Inhaltselemente erlaubt sind, steht in einer JSON-Datei. Wenn man diese Schema immer wieder verwendet, ist es natürlich gut. Wenn man als Agentur Entwickler ausbildet, dann zeigt man denen einmal, wie es funktioniert und schon können sie Inhaltselemente zusammenkloppen. Ich bezweifle jedoch, dass sie verstehen, was da im Hintergrund passiert. Jemand, der dieses Schema nicht kennt und das Projekt anschließend übernimmt, muss sich in diese Implementierung reindenken und entweder weiter damit arbeiten oder es so umschreiben, dass es näher an den Vorgaben ist.

3) Inhaltselemente nur für eine bestimmte Verwendung implementieren
Das bezieht sich vor allem aufs Frontend. Immer wieder erlebe ich, dass die Inhaltselemente nur genauso wie bisher eingepflegt gut aussehen und anderswo zwar positioniert werden können, aber dann das Layout zerschießen. Ich sehe TYPO3 mehr wie Duplo: verschiedene Bausteine und ich kann sie beliebig einsetzen. Ein Akkordion z.B. kann im Header, Inhalt und Footer eingesetzt werden und funktioniert dort immer wie erwartet. Wenn das nicht möglich sein soll, dann konfiguriere ich ihn in der Spalte weg (siehe Punkt 2) oder ich sorge per CSS dafür, dass er an allen drei Locations gut aussieht. Bei den meisten Implementierung ist es eher Mikado: So steht es gerade, aber bloß nicht anfassen.
Auch prüfe ich, ob ein Element zweimal auf der Seite einsetzen werden kann! Letztens gerade wieder eine Implementierung gesehen, bei der einem solchen Element ein feste HTML-id zugeteilt wurde und dann mit JavaScript irgendwas damit gemacht wurde. Blöd nur, wenn der Kunde das Element zweimal auf einer Seite einsetzt.

Das reicht fürs erste an Gruselgeschichten. Es hat auch Vorteile, dass mir immer wieder unterschiedliche Projekte begegnen. Zum einen werden meine grauen Zellen stimuliert – ich muss mich in andere Ansätze und Lösungen reindenken und arbeite nicht immer nach dem gleichen Schema. Zum anderen hinterfrage und optimiere ich immer wieder meine eigenen Ansätze und kann so das (zu dem jeweiligen Zeitpunkt) beste Ergebnis abliefern. Und diesen Aspekt mag ich besonders an meinem Freelancer-Dasein…