kantarci/KantSites
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 81 Wiki Activity
Files
042aef9a32f709c4aa47c47c66cfccf754101984
KantSites/docs/LIVEGANG.md
T
kantarciandClaude Opus 5 05ea703655
CMS quality / php (8.2) (push) Canceled after 0s
Details
CMS quality / php (8.4) (push) Canceled after 0s
Details
CMS quality / browser (push) Canceled after 0s
Details
CMS quality / mysql (push) Canceled after 0s
Details
Fassung 1.6.0: der Aufgabenplan wird veroeffentlicht 
Wiederkehrende Aufgaben ohne Cronjob (ADR 073): Sicherung, Statistik kuerzen,
geplante Veroeffentlichung, Updatepruefung und Aufraeumen laufen als Plan in
der Tabelle scheduled_task - eine Zeile je Aufgabe mit Faelligkeit, Sperre und
letztem Ergebnis. Auf geteiltem Hosting gibt es oft keinen Cronjob; der Plan
haengt stattdessen an Anfragen und an einem Takt aus dem geoeffneten Backend.

Diese Arbeit entstand in einer parallel laufenden Sitzung und lag bis hierher
unveroeffentlicht im Arbeitsverzeichnis: die Releases 1.5.0 bis 1.5.5 wurden
bewusst aus dem jeweiligen Tag gebaut und enthielten sie deshalb nicht.

Vor der Veroeffentlichung geprueft, nicht bloss eingepackt:

- phpunit 452/452, npm test 28/28, npm run test:editor vollstaendig.
- Die Migration 20260914000100 legt nur die Tabelle scheduled_task an und nimmt
  sie beim Zurueckrollen wieder weg. Sie fasst keine bestehenden Daten an.
- Seit einer Stunde keine Schreibzugriffe der anderen Sitzung mehr.

Dabei zwei Fehler behoben:

- config/services.yaml verwendet !tagged_iterator. Das ist gueltiges Symfony,
  aber "lint:yaml config" kennt eigene Tags nur mit --parse-tags und gab 1
  zurueck - der CI-Lauf waere daran gescheitert. Flag ergaenzt.
- AdminHeadersSubscriber.php (aus 1.5.3) entsprach nicht dem Stil von
  php-cs-fixer; composer lint gab 8 zurueck. Behoben.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-14 08:30:13 +02:00

6.1 KiB
Raw Blame History

Livegang von kant-it.de

Stand: 13.09.2026. Diese Liste trennt, was geprüft ist, von dem, was nur auf dem echten Hosting geprüft werden kann – und in welcher Reihenfolge umgeschaltet wird.

Geprüft (lokal, gegen den Nachbau)

Prüfung Ergebnis
PHPUnit, PHP 8.2 und 8.4 409 Tests, 1791 Zusicherungen, grün
JavaScript-Modelltests grün
Editor durchgespielt (Playwright + axe) grün, isolierte Datenbank
Öffentliche Seiten (Playwright + axe, 1440 px und 390 px) keine Beanstandung
Interne Verweise (npm run test:links) 35 Seiten, 408 Adressen, kein toter Verweis
Lighthouse, vier Adressen, je drei Läufe Barrierefreiheit, Best Practices, SEO, agentic browsing 100 überall; Performance 100 außer Startseite (98 mobil / 96 Desktop)
Sicherung (cms:backup) angelegt: 33 Seiten, 100 Fassungen, 388 Mediendateien
Weiterleitungen der alten WordPress-Adressen 14 Stück angelegt, alle beantwortet mit 301

Gemessen wurde im Produktionsmodus auf dem PHP-Entwicklungsserver, der dieselben Kopfzeilen sendet wie public/.htaccess. Das ist kein Ersatz für eine Messung auf dem echten Hosting.

Nicht geprüft – muss vor dem Umschalten passieren

  1. E-Mail-Versand. Nie ausgeführt, in keiner Umgebung. MAILER_DSN=sendmail://default funktioniert auf den meisten PHP-Hostings; verlangt der Anbieter SMTP, gehört dort eine Zeile der Form smtp://benutzer:passwort@mailserver:587 hinein. Nach dem Hochladen eine echte Anfrage über das Kontaktformular abschicken und prüfen, ob sie ankommt – auch im Spam-Ordner. Die Anfrage wird vor dem Versand gespeichert; kommt keine Mail an, steht sie trotzdem unter „Formulare“ in der Verwaltung.
  2. HTTPS. Zertifikat einrichten, dann in public/.htaccess die drei Zeilen der HTTPS-Umleitung einschalten. Erst wenn das eine Weile läuft, die HSTS-Zeile aktivieren – sie lässt sich in einem Browser ein halbes Jahr lang nicht zurücknehmen.
  3. www oder nicht. Das alte kant-it.de ist kanonisch mit www. In .htaccess steht die Umleitung dafür vorbereitet und auskommentiert; sie muss zur Einstellung SITE_ORIGIN passen, die in .env steht. Beide zeigen auf dieselbe Schreibweise, sonst zeigt jede Seite auf eine Adresse, die weiterleitet.
  4. Datenbank. Geprüft ist ausschließlich SQLite. Für MySQL ist alles vorbereitet, aber nichts erprobt – wer MySQL nimmt, sollte danach Seiten anlegen, veröffentlichen, Bilder hochladen und ein Formular absenden.
  5. Wiederkehrende Aufgaben. Sicherung, Statistik und geplante Veröffentlichung laufen nach dem Hochladen von selbst – angestoßen von Seitenaufrufen und vom geöffneten Backend (Verwaltung → Aufgaben). Das genügt, ist aber nicht minutengenau: ohne Besuch passiert nichts. Bietet der Hoster einen Cronjob, gehört php bin/console cms:tasks:run dorthin (jede Minute); bietet er nur einen URL-Cronjob, die Adresse vom Bildschirm „Aufgaben“ (alle fünf Minuten). Danach dort den Auslöser „Besuche der Website“ abschalten. Nach dem Umzug einmal nachsehen, ob in der Spalte „Zuletzt“ bei der Sicherung ein ok steht – ohne Sicherung gibt es keinen Rückweg.
  6. Schriften. Auf dem neuen Server einmal php bin/console cms:fonts:fetch ausführen oder im Designbereich den Knopf drücken – die Dateien liegen nicht im Repository. Bis dahin lädt die Seite die Schriften von Google, was sie nicht soll.
  7. Rechtstexte. Impressum und Datenschutzerklärung sind vom alten Auftritt übernommen. Der Abschnitt über Google Fonts wurde an die Wirklichkeit angepasst (die Schriften kommen jetzt vom eigenen Server), die Abschnitte über Google Maps und reCAPTCHA entfernt, weil beides nicht eingebunden ist. Das ersetzt keine anwaltliche Prüfung, und es ist die Verantwortung des Betreibers, nicht des CMS.
  8. Texte. Acht Projektbeschreibungen stammen nicht vom alten Auftritt, sondern sind neu geschrieben. Sie sollten gelesen werden, bevor sie öffentlich sind.

Optional: die Verwaltung umbenennen

/admin ist die erste Adresse, die jeder Scanner probiert. php bin/console cms:admin:path meine-verwaltung legt sie woanders hin; der Name steht danach in .env.local und in keiner öffentlichen Datei. Vorher notieren, wohin – danach antwortet /admin mit 404 wie jede unbekannte Adresse. Zurück geht es mit php bin/console cms:admin:path admin.

Optional: Spamschutz mit Cloudflare

Die Formulare haben drei eingebaute Prüfungen ohne Dritte. Kommt trotzdem Spam durch, gibt es unter Einstellungen → „Spamschutz für Formulare" Cloudflare Turnstile: Schlüsselpaar im Cloudflare-Konto anlegen (kostenlos), beide Schlüssel eintragen, Haken setzen. Vorher wissen: das Widget braucht JavaScript, und die IP-Adresse des Absenders geht an Cloudflare – beides gehört in die Datenschutzerklärung, bevor es scharf geschaltet wird.

Reihenfolge am Umzugstag

  1. Dateien auf das Hosting, .env mit APP_ENV=prod, APP_DEBUG=0, DATABASE_URL, MEDIA_DIRECTORY, SITE_ORIGIN, MAILER_DSN und einem neuen APP_SECRET.
  2. Datenbank und Medienordner einspielen (oder php vendor/bin/doctrine-migrations migrate auf einer leeren Datenbank und dann der Installer).
  3. php bin/console cms:fonts:fetch, danach eine Seite aufrufen und im Quelltext prüfen, dass nichts von fonts.googleapis.com geladen wird.
  4. Kontaktformular abschicken, Mail prüfen.
  5. Jetzt erst die Domain umstellen.
  6. Danach: CMS_URL=https://www.kant-it.de npm run test:links von einem Rechner mit Node, robots.txt und sitemap.xml im Browser aufrufen, die Sitemap in der Google Search Console neu einreichen, und drei bis vier alte Adressen von Hand aufrufen (etwa /productsolutions/, /kanttresor-dsgvo-konforme-archivierung-fuer-moderne-unternehmen/) – sie müssen mit 301 auf die neue Adresse führen.
  7. Eine Woche lang in der Search Console auf 404-Meldungen schauen; jede weitere alte Adresse bekommt eine Weiterleitung unter „Einstellungen → Weiterleitungen“.

Rückweg

Das alte WordPress bleibt bis auf Weiteres bestehen. Geht etwas schief, wird die Domain dorthin zurückgestellt; die Inhalte des neuen Auftritts liegen unverändert in der Sicherung unter var/backups/.

Reference in new issue View Git Blame Copy Permalink