04b — Installation im Classic Mode

Classic Mode ist TYPO3 ohne Composer: Die TYPO3-Quellen werden als Archiv heruntergeladen, die Extensions in einen Ordner entpackt und im Backend eingeschaltet. Keine composer.json, kein vendor/bin, keine Auflösung von Abhängigkeiten — und für die entscheidenden Teile keine Kommandozeile nötig.

Das ist der Weg für Hosting, das FTP und eine Datenbank bietet und sonst nichts. Er funktioniert mit TYPO3 v14, und sowohl das Theme als auch seine Abhängigkeiten sind als schlichte Archive verfügbar.

Was gebraucht wird

Die vier Archive

Alles ist ein Download. Nichts wird für dich aufgelöst, also zuerst einsammeln:

Beide TER-Extensions deklarieren Unterstützung für TYPO3 v14 (bootstrap_package bis 14.4.99, container bis 14.99.99). Das ZIP nehmen, nicht das T3X: T3X ist ein altes Packformat, das nur der Extension Manager entpacken kann.

1. TYPO3 entpacken

tar xzf typo3_src-14.3.5.tar.gz
mv typo3_src-14.3.5 my-site
cd my-site
mkdir -p typo3conf/ext fileadmin typo3temp var

Das Quellarchiv ist in sich geschlossen — es bringt ein eigenes vendor/- Verzeichnis mit jeder PHP-Bibliothek mit, die TYPO3 braucht. Genau darum geht es im Classic Mode.

Der Document Root ist der Projektordner selbst. Ein public/ gibt es nicht. Den vhost auf my-site/ richten, nicht auf einen Unterordner — das ist der größte Unterschied zu einer Composer-Installation, und er ändert jeden Pfad weiter unten.

2. Die Extensions entpacken

Vier Ordner kommen nach typo3conf/ext/:

typo3conf/ext/container/
typo3conf/ext/bootstrap_package/
typo3conf/ext/yavi-core/
typo3conf/ext/yavi-lucerne/

Die beiden Yavi-Ordner stammen direkt aus dem Portal-ZIP, aus yavi-lucerne/packages/. Nicht umbenennen. Ältere Dokumentation sagt, der Ordnername müsse der Extension Key mit Unterstrichen sein; seit TYPO3 v14 (Breaking #108310) wird der Key aus extra.typo3/cms.extension-key in der composer.json der Extension gelesen, und beide Pakete tragen ihn. Ein Ordner namens yavi-core wird als Extension yavi_core erkannt, und die Site rendert Byte für Byte genauso wie mit der Unterstrich-Schreibweise.

Jedes TER-ZIP so entpacken, dass ext_emconf.php unmittelbar im Extension-Ordner liegt — nicht in einem Unterordner darin.

3. Den Installer ausführen

Über den Browser: die eigene Domain aufrufen, das Setup von TYPO3 übernimmt. Es fragt nach der Datenbankverbindung, legt die Tabellen an und richtet einen Administrator ein.

Auf der Kommandozeile ist dasselbe ein Aufruf. Auf den Pfad zur Binärdatei achten — im Classic Mode liegt sie in typo3/sysext/, nicht in vendor/bin/:

php -d memory_limit=512M typo3/sysext/core/bin/typo3 setup \
    --no-interaction \
    --driver=mysqli \
    --server-type=apache \
    --host=127.0.0.1 --port=3306 \
    --dbname=your_database --username=your_user --password=your_password \
    --admin-username=admin --admin-user-password='choose-a-strong-one' \
    --admin-email=you@example.com \
    --project-name="My Site"

--server-type=apache lässt den Installer eine 14 KB große .htaccess in die Projektwurzel schreiben. Die will man haben: Sie trägt die Rewrite-Regeln, die Cache-Header und die Deny-Regeln, die typo3conf/ unerreichbar halten. Für nginx other verwenden und die Serverkonfiguration aus der TYPO3-Dokumentation nehmen.

Das Ergebnis ist typo3conf/system/settings.php — das Gegenstück zu config/system/settings.php im Classic Mode.

4. Die Extensions einschalten

Das Backend unter /typo3/ öffnen, anmelden und zu Admin Tools → Extensions gehen. In dieser Reihenfolge aktivieren, denn jede hängt von der davor ab:

1. container
2. bootstrap_package
3. yavi_core
4. yavi_lucerne

Mehr ist es nicht — der Extension Manager schreibt typo3conf/PackageStates.php und erzeugt die Klassenladeinformationen in einem Zug neu.

Danach die Datenbankmigrationen ausführen:

php -d memory_limit=512M typo3/sysext/core/bin/typo3 extension:setup
php -d memory_limit=512M typo3/sysext/core/bin/typo3 cache:flush

extension:setup ergänzt die Spalten des Themes auf tt_content, legt die acht Item-Tabellen an und kopiert Initialisation/Files/ nach fileadmin/yavi_lucerne/ (405 Dateien, 24 MB). Im Backend erledigt dieselbe Arbeit Admin Tools → Maintenance → Analyze Database Structure.

5. Über die Demo-Inhalte entscheiden

5a. Mit den Demo-Inhalten

gunzip -c .tarballs/yavi-demo.sql.gz | mysql -u your_user -p your_database

Oder über phpMyAdmin, das jeder Hoster bereitstellt — die Datei ist gepackt 208 KB und liegt damit weit unter jedem Upload-Limit.

Danach die Medien kopieren, denn die Dateidatensätze der Demo erwarten sie unmittelbar unterhalb von fileadmin/:

cp -R typo3conf/ext/yavi-lucerne/Initialisation/Files/. fileadmin/

Das ist eine flache Kopie — das Ergebnis ist fileadmin/dummy-media/…, nicht fileadmin/yavi-lucerne/dummy-media/…. Die Kopie, die extension:setup nach fileadmin/yavi_lucerne/ gelegt hat, ist eine zweite, davon getrennte und nicht die, welche die Demo verwendet.

5b. Ohne die Demo-Inhalte

Den Import auslassen. Nach Schritt 6 läuft ein Hilfsskript, das eine Wurzelseite anlegt und die Grundstruktur des Themes einspielt — Topbar, Footer und die Seiten, auf die das Footer-Menü verlinkt.

6. Die Site-Konfiguration

Im Classic Mode liegen Site-Konfigurationen in typo3conf/sites/, nicht in config/sites/.

mkdir -p typo3conf/sites/mysite
cp -R typo3conf/ext/yavi-lucerne/Initialisation/Site/yavilucerne/. typo3conf/sites/mysite/

Das kopiert drei Dateien, und das Theme braucht alle drei:

page.tsconfig und settings.yaml liest TYPO3 selbstständig aus dem Site-Ordner — es ist nirgends etwas einzubinden. Wer die Site stattdessen im Backend anlegt, statt den Ordner zu kopieren, bekommt eine config.yaml und sonst nichts: Das Frontend rendert dann, es sieht also fertig aus, während dem Backend seine Layouts, seine RTE-Konfiguration und die Inhaltselemente des Themes fehlen. In diesem Fall die beiden anderen Dateien von Hand hineinkopieren.

Danach typo3conf/sites/mysite/config.yaml bearbeiten:

base: 'https://example.com/'
# den ganzen baseVariants-Block loeschen
languages:
  -
    base: /            # war %env(DDEV_BASE)%
  -
    base: /de/         # war %env(DDEV_BASE_DE)%

Die base-Werte der Sprachen sind relativ zur base der Site; sie bleiben also / und /de/, gleich welche Domain im Spiel ist.

Ohne Demo wird das Hilfsskript jetzt ausgeführt — es braucht die Site-Konfiguration, weil es hineinschreibt:

php -d memory_limit=512M init-static-elements.php mysite
php -d memory_limit=512M typo3/sysext/core/bin/typo3 cache:flush

Zuvor init-static-elements.php und .tarballs/ aus dem Portal-ZIP in die Projektwurzel kopieren. Das Skript erkennt das Layout selbst und arbeitet in beiden Modi. Es gibt die vergebenen uids aus. Der Cache-Flush ist nicht optional: Das Hilfsskript schreibt Einstellungen, nachdem TypoScript bereits gebaut wurde; Topbar und Footer bleiben bis zum nächsten Flush leer.

Mit Demo das Hilfsskript nicht ausführen — der Dump bringt diese Datensätze bereits mit, und die settings.yaml zeigt schon darauf.

So oder so prüfen, dass die Wurzelseite ein Backend-Layout hat: Seiteneigenschaften → Erscheinungsbild → Backend-Layout (nur diese Seite) und (Unterseiten dieser Seite), beide auf Yavi Core – Standard. Ohne das hat die Seite keine Spalten, in die Inhalte gehören, und das Frontend rendert einen leeren Rahmen, ohne dass irgendetwas ein Problem meldet. Die Demo und das Hilfsskript setzen es; eine selbst angelegte Wurzelseite hat es nicht. Siehe 05 — Die erste Site einrichten.

7. Den eigenen Backend-Benutzer anlegen

Nur nach dem Import der Demo. Schritt 3 hat ein Konto angelegt, aber der Dump aus 5a verwirft be_users und bringt selbst keine Konten mit — dieses Konto ist also weg.

php -d memory_limit=512M typo3/sysext/core/bin/typo3 backend:user:create \
    --username=admin --password='choose-a-strong-one' \
    --email=you@example.com --admin --no-interaction

--no-interaction in der langen Form angeben. Ohne das legt der Befehl den Benutzer an und wartet danach auf eine Antwort, die nie kommt.

8. Konfiguration des Webservers

Apache muss die von TYPO3 geschriebene .htaccess beachten:

<Directory "/path/to/my-site">
    Options FollowSymLinks
    AllowOverride All
    Require all granted
</Directory>

AllowOverride All ist nicht optional, und eine von Hand geschriebene Rewrite-Regel ist kein Ersatz. Die naheliegende,

RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^ index.php [QSA,L]

macht das Backend stillschweigend kaputt: /typo3/ ist ein echtes Verzeichnis auf der Platte, die Bedingung schließt es also aus, die Anfrage erreicht index.php nie, und Apache antwortet mit 404 — während das Frontend einwandfrei läuft und keinen Hinweis gibt. Die .htaccess von TYPO3 behandelt diesen Fall korrekt.

Für den Webserver-Benutzer beschreibbar:

typo3conf/sites/<id>/settings.yaml   hierhin speichert das Backend-Modul
typo3conf/system/                    settings.php
typo3temp/                           Caches, kompiliertes CSS, verarbeitete Bilder
fileadmin/                           Uploads
var/

9. Prüfen

php -d memory_limit=512M typo3/sysext/core/bin/typo3 extension:list | grep -E 'yavi|bootstrap|container'

Vier Zeilen, alle active. Danach die Site öffnen: mit Demo landet man auf der fertigen Standard-Site, ohne sie auf einer Seite mit dem Rahmen des Themes darum herum. Das Backend liegt unter /typo3/.

Weiter mit 05 — Die erste Site einrichten für den Lizenzschlüssel und die ersten Inhalte.

Jeder Pfad, der vom Composer Mode abweicht

Updates

1. Datenbank und Projektordner sichern.
2. TYPO3 selbst: das neue Quellarchiv neben das alte entpacken und dann typo3conf/, fileadmin/, typo3temp/ und var/ hinüberziehen — oder über die Installation entpacken und zuvor die alten Ordner typo3/ und vendor/ löschen.
3. Das Framework: typo3conf/ext/yavi-core löschen, dann die neue Version entpacken. Nicht über die alte entpacken — Dateien, die die neue Version entfernt hat, blieben liegen. typo3conf/ext/yavi-lucerne unangetastet lassen: Das Theme gehört dir, und ein Update darf dein SCSS und deine Templates nicht überschreiben.
4. php typo3/sysext/core/bin/typo3 dumpautoload
5. php typo3/sysext/core/bin/typo3 extension:setup
6. php typo3/sysext/core/bin/typo3 cache:flush

Schritt 4 ist der, den man leicht vergisst und schwer diagnostiziert: Ohne ihn sind neue PHP-Klassen unsichtbar, und TYPO3 meldet sie als fehlend in Dateien, die sie offensichtlich enthalten.

Was der Classic Mode nicht bietet