kantarciandClaude Opus 5
33e4ac0c54
Eine Quelle entscheidet jetzt, welche Seite unter / antwortet: SiteSettings::homePath() und publicPath(). Das Literal home kommt im Anwendungscode nicht mehr vor - öffentliche Routen, Canonical, Sitemap, llms.txt, Menüauflösung, Beitragslisten und der Formularrücksprung benutzen dieselben zwei Methoden. Die gewählte Seite muss veröffentlicht und nicht im Papierkorb sein, ihre eigene Adresse leitet dauerhaft auf /, und als Wurzel ist sie gegen Umbenennen und Papierkorb gesperrt. Zweiter echter Fehler, den nur ein HTTP-Aufruf zeigt: /sitemap.xml, /robots.txt, /llms.txt und /feed.xml waren lokal nie erreichbar. Der eingebaute PHP-Server antwortet für fehlende Pfade mit Dateiendung selbst mit 404, ohne den Frontcontroller zu fragen; alle Kernel-Tests bestanden trotzdem, weil sie die Anwendung direkt aufrufen. bin/dev-router.php bildet die Rewrite-Regel des Hostings nach, Start- und CI-Befehl nutzen es, und die Browserprüfung ruft die vier Adressen jetzt über HTTP auf. Barrierefreiheitsbefunde werden nach Ursache getrennt: ein Kontrastfehler aus Theme oder Stylesheet bleibt ein Defekt und bricht den Lauf ab, einer aus einer im Editor gesetzten Blockfarbe wird bei jedem Lauf mit Seite, Farbe und Verhältnis genannt und in reports/browser.json geschrieben, färbt aber keinen Codewechsel rot. Geprüft: 162 PHP-Tests / 636 Assertions unter PHP 8.2.12 und 8.4.22, 15 JavaScript-Modelltests, vollständiger Editortest mit axe, wieder grüne öffentliche Browserprüfung und Lighthouse mit je drei Läufen mobil und Desktop, alle fünf Kategorien 100. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
164 lines
15 KiB
Markdown
164 lines
15 KiB
Markdown
# Ausbauplan bis zum Pilotbetrieb
|
||
|
||
Stand: 12.09.2026. Ergänzt `ENTWICKLUNGSPLAN.md` um die Aufschlüsselung der noch offenen Arbeit. Der Phasenplan bleibt die übergeordnete Reihenfolge; dieses Dokument benennt die konkreten Arbeitspakete, ihre Abhängigkeiten und ihre Abnahme. Der aktuelle Stand steht in `docs/STATUS.md`, begründete Entscheidungen in `docs/ARCHITECTURE.md`.
|
||
|
||
## Pilotwebsite: kant-it.de
|
||
|
||
Umut hat `kant-it.de` am 12.09.2026 als Pilotwebsite bestimmt. Der Ausbau richtet sich ab jetzt an dieser Website aus, nicht an einem generischen CMS-Funktionsumfang.
|
||
|
||
### Erhobener Bestand
|
||
|
||
Erhoben am 12.09.2026 ausschließlich aus der **öffentlich ausgelieferten Startseite**. Es bestand kein Zugriff auf das WordPress-Backend. Alles Folgende ist damit belegt, aber nicht vollständig: Entwürfe, nicht verlinkte Seiten, Formularkonfigurationen, Benutzerrollen, individuelle Felder und der tatsächliche Beitragsbestand sind von außen nicht sichtbar.
|
||
|
||
**Technischer Bestand**
|
||
|
||
| Bereich | Befund |
|
||
| --- | --- |
|
||
| Kern | WordPress 7.1 |
|
||
| Theme | Flatsome 3.20.9 mit Child-Theme `kant-it-flatsome-ux-child`, eigenes `kant-it-home.js` |
|
||
| Startseite | Seitenvorlage `page-blank`, vollständig im UX Builder aufgebaut |
|
||
| Formulare | WPForms Lite |
|
||
| Cookie-Banner | Complianz GDPR |
|
||
| Bewertungen | WP Google Places Review Slider (externe Google-Rezensionen) |
|
||
| Chat | `kant-nova-chat` – ein **eigenes Plugin**, kein Marktplatzprodukt |
|
||
| Suche | Flatsome Live Search |
|
||
|
||
**Inhaltlicher Bestand**
|
||
|
||
- Startseite als Onepager. Die Hauptnavigation verweist auf Ankerziele derselben Seite (`#dienstleistungen`, `#projekte`, `#kontakt`), nicht auf Unterseiten.
|
||
- Beiträge mit flachem Permalink direkt unter der Wurzel, zum Beispiel `/kanttresor-dsgvo-konforme-archivierung-fuer-moderne-unternehmen/` und `/neue-webseite-fuer-klinik-umsetzer-de-umgesetzt/`. Dazu eine Übersichtsseite `/productsolutions`.
|
||
- Rechtsseiten `/impressum/` und `/datenschutzerklaerung/`.
|
||
- Externe Ziele: `hausklar.app`, `kanttresor.kant-it.de`, TeamViewer-QuickSupport-Download.
|
||
- Kontaktdaten als Inhalt: Telefon, E-Mail, Anschrift in Baden-Baden, jeweils als `tel:`- und `mailto:`-Verweis.
|
||
|
||
**Abschnittsarten der Startseite**, die als Blöcke gebraucht werden: Hero mit Handlungsaufruf, Logoleiste, Kennzahlen, Leistungsraster mit Symbol und Text, Lösungs- und Projektkarten mit Bild, Kundenstimmen mit Bewertung und Person, Hinweisbox mit Download, Handlungsaufruf-Band, Kontaktbereich aus Kontaktdaten und Formular.
|
||
|
||
### Was daraus folgt
|
||
|
||
1. **Menüs müssen Ankerziele und externe Ziele können**, nicht nur Seitenverweise. Ein reiner Seitenbaum als Navigation reicht für diesen Piloten nicht.
|
||
2. **Beiträge liegen flach unter der Wurzel** und haben eine eigene Übersichtsseite. Das passt zum heutigen Datenmodell (`type = post`, `path` ohne Elternteil) und braucht keine Schemaänderung.
|
||
3. **Das Formular ist der Kern der Seite.** Ohne serverseitig validiertes Kontaktformular mit Einwilligung und Versand ist der Pilot nicht livefähig.
|
||
4. **Drei Fremdbausteine sind keine Inhalte, sondern Integrationen**: Cookie-Banner, Google-Rezensionen und der eigene Chat. Sie gehören hinter die Plugin-Schnittstelle, nicht in den Kern. Der Erhaltungsvertrag für unbekannte Blöcke (ADR 011) ist die Grundlage dafür.
|
||
5. **`kant-nova-chat` ist Eigenentwicklung.** Für die Migration muss sein Quellcode vorliegen; ohne ihn ist der Chat kein migrierbares Feature, sondern ein Neubau.
|
||
6. **Strukturierte Daten lohnen sich hier konkret**: Anschrift, Telefon und Öffnungszeiten eines regionalen Dienstleisters sind ein echter `LocalBusiness`-Fall, keine Pflichtübung.
|
||
|
||
### Offen und nur von Umut zu beantworten
|
||
|
||
- Zugang zum WordPress-Backend oder ein Export, um Beiträge, Formularfelder, Benutzer und Flatsome-Shortcodes tatsächlich zu inventarisieren.
|
||
- Quellcode von `kant-nova-chat`.
|
||
- Hostinganbieter, Tarif, PHP- und Datenbankversion, Dokumentenstamm, CLI- und Deploymentzugang.
|
||
- Umgang mit den Google-Rezensionen: weiter über einen externen Dienst oder als gepflegter Inhalt.
|
||
- Soll der Pilot beim Cookie-Banner bleiben, und wenn ja, mit welchem Dienst.
|
||
|
||
## Arbeitspakete
|
||
|
||
Die Reihenfolge ergibt sich aus Abhängigkeiten und aus dem Risiko, etwas später über Kundendaten ändern zu müssen. Jedes Paket endet mit einem prüfbaren Ergebnis, aktualisiertem STATUS und, wo nötig, einer Architekturentscheidung.
|
||
|
||
### A – Navigation und Menüs — **erledigt am 12.09.2026**
|
||
|
||
*Braucht: Seitenhierarchie (erledigt).*
|
||
|
||
Umgesetzt bis auf eines: Aufklappmenüs, Anker-, Seiten- und externe Ziele, Header und Footer getrennt, `aria-current`, keine öffentliche JavaScript-Abhängigkeit, gelöschte Seiten brechen das Menü nicht. **Offen geblieben:** die Sortierung läuft über Positionsnummern statt per Drag-and-drop, und es gibt nur die beiden festen Plätze. Details in ADR 012.
|
||
|
||
Menüverwaltung mit benannten Menüs und sortierbaren Einträgen. Ein Eintrag verweist auf eine Seite, auf ein Ankerziel innerhalb einer Seite oder auf eine externe Adresse; Beschriftung ist überschreibbar. Verschachtelung für Aufklappmenüs. Header- und Footermenü getrennt. Ausgabe als semantische Navigation mit `aria-current`, ohne öffentliches JavaScript für die Grundfunktion.
|
||
|
||
Abnahme: Die feste Navigation im Template ist ersetzt. Ein Menü mit Anker-, Seiten- und externem Ziel wird korrekt ausgegeben. Eine gelöschte Seite macht das Menü nicht kaputt.
|
||
|
||
### B – Beiträge — **erledigt am 12.09.2026**
|
||
|
||
*Braucht: A für die Verlinkung.*
|
||
|
||
Umgesetzt: Datum, Autor, Auszug und Beitragsbild, Übersicht mit Paginierung, Beitragsliste als Block, Einzelansicht mit Datum, Autor und Begriffen, Kategorien und Schlagwörter mit Archiven, RSS. **Offen geblieben:** keine Bildvorschau in der Verwaltung (das Beitragsbild wird über seine Mediathek-ID eingetragen), keine Begriffsverwaltung zum Umbenennen oder Zusammenführen, feste zehn Beiträge je Archivseite. Details in ADR 014.
|
||
|
||
Beitragsdatum, Autor, Auszug und Beitragsbild im Datenmodell. Übersichtsseite mit Sortierung nach Datum und Paginierung. Ein Block „Beitragsliste“ zum Einbetten in beliebige Seiten, mit Anzahl und Filter. Einzelansicht mit Datum und Autor. Kategorien und Schlagwörter einschließlich ihrer Archivseiten. RSS-Feed.
|
||
|
||
Abnahme: Die vier bestehenden Projektbeiträge des Piloten lassen sich als Beiträge abbilden, erscheinen in der Übersicht und in einer eingebetteten Liste auf der Startseite.
|
||
|
||
### C – Blöcke für den Piloten — **erledigt am 12.09.2026**
|
||
|
||
*Braucht: nichts; parallel möglich.*
|
||
|
||
Umgesetzt: Symbolkarte, Kennzahl, Kundenstimme, Logoleiste, Aufruf-Band, Kontaktdaten, Trennlinie, Abstand und Akkordeon, alle ohne neue öffentliche JavaScript-Abhängigkeit. Tabs wurden zunächst zurückgestellt (ADR 015) und auf Entscheidung von Umut anschließend mit JavaScript umgesetzt: der Server liefert vollständigen Inhalt, ein Skript macht daraus ein Tab-Widget, und die strenge Skriptrichtlinie bleibt überall sonst bestehen (ADR 016). **Offen:** das Skript ist nicht im Browser geprüft.
|
||
|
||
Die oben erhobenen Abschnittsarten als Blöcke: Symbol-und-Text-Karte, Kennzahl, Kundenstimme mit Bewertung, Logoleiste, Handlungsaufruf-Band, Kontaktdatenblock, Trennlinie und Abstandhalter. Dazu Akkordeon und Tabs, weil beide im Plan stehen und ohne JavaScript über `details`/`summary` beziehungsweise Sprungmarken lösbar sind.
|
||
|
||
Abnahme: Die Startseite des Piloten ist ohne Code nachbaubar. Keine neue öffentliche JavaScript-Abhängigkeit.
|
||
|
||
### D – Formulare — **erledigt am 12.09.2026, ohne Dateiuploads**
|
||
|
||
*Braucht: nichts; das größte eigenständige Paket.*
|
||
|
||
Umgesetzt: Feldtypen Text, E-Mail, Telefon, Mehrzeiliges, Auswahl und Einwilligung, serverseitige Validierung mit Meldung je Feld, Einwilligungszeitpunkt, E-Mail-Versand mit Antwortadresse, gespeicherte Einsendungen in der Verwaltung und Spamschutz aus Honeypot, signiertem Zeitstempel und Rate-Limit. **Offen geblieben:** Dateiuploads (eigener nicht öffentlicher Ablageort und Typprüfung, Begründung in ADR 017), Löschen und Umbenennen von Formularen, Export und Aufbewahrungsfrist für Einsendungen. Der tatsächliche Versand ist ungeprüft und gehört zu Paket J.
|
||
|
||
Formularbaukasten mit Feldtypen Text, E-Mail, Telefon, Auswahl, Mehrzeiliges, Einwilligungskästchen und Datei. Pflichtfelder, serverseitige Validierung mit Fehlermeldungen am Feld, Beschriftungen und Fehlerauszeichnung für Screenreader. Versand per E-Mail mit Antwortadresse, dazu Speicherung der Einsendungen mit Ansicht in der Verwaltung. Spam-Schutz ohne Drittanbieter-CAPTCHA: Honeypot, Zeitschwelle, Rate-Limit pro IP. Einwilligungstext mit Verweis auf die Datenschutzerklärung, Zeitpunkt der Einwilligung wird mitgespeichert.
|
||
|
||
Abnahme: Das Kontaktformular des Piloten ist nachgebaut, funktioniert ohne JavaScript, weist ungültige Eingaben serverseitig ab und stellt eine E-Mail zu. Ein abgewiesener Versand verliert keine Eingaben.
|
||
|
||
### E – SEO und maschinelle Zugänglichkeit — **erledigt am 12.09.2026**
|
||
|
||
*Braucht: A und B für Sitemap und Breadcrumbs.*
|
||
|
||
Umgesetzt: Indexierungssteuerung und Vorschaubild je Seite, Sitemap, robots.txt, Weiterleitungen mit 301 und 410, strukturierte Daten für Organization/LocalBusiness, Article und BreadcrumbList, Brotkrumen-Block und optionale llms.txt. **Offen geblieben:** getrennte SEO-Titel, Auflösung des Vorschaubilds zu `og:image`, Weiterleitungen mit Mustern, und automatische Weiterleitung beim Umbenennen (gehört zu Paket F). Details in ADR 018.
|
||
|
||
SEO-Felder je Seite: Titel, Beschreibung, Indexierungssteuerung, Open-Graph-Bild. Automatische `sitemap.xml`, `robots.txt`, Weiterleitungsverwaltung mit HTTP 301 und 410. Strukturierte Daten für `Organization`/`LocalBusiness` aus gepflegten Unternehmensdaten, für `Article` aus Beiträgen, für `BreadcrumbList` aus der Hierarchie. Breadcrumb-Block. `llms.txt` optional und abschaltbar, ohne jede Behauptung über Ranking oder Zitierung.
|
||
|
||
Abnahme: Sitemap und robots.txt stimmen mit dem veröffentlichten Bestand überein. Eine Adressänderung erzeugt eine Weiterleitung. Strukturierte Daten decken sich mit sichtbarem Inhalt und bestehen die Prüfung mit dem Testwerkzeug.
|
||
|
||
### F – Seiten verwalten — **erledigt am 12.09.2026**
|
||
|
||
*Braucht: A und E für Menüs und Weiterleitungen.*
|
||
|
||
Umgesetzt: Umbenennen und Verschieben mit Aktualisierung aller Kindpfade und automatischer Weiterleitung, geplante Veröffentlichung, Fassungsverlauf mit Wiederherstellen und ein Papierkorb statt sofortigem Löschen. Die frei wählbare Startseite ist ebenfalls umgesetzt (ADR 023). **Offen geblieben:** kein automatisches Leeren des Papierkorbs und kein Vergleich zweier Fassungen.
|
||
|
||
Seiten umbenennen und verschieben, mit Aktualisierung aller Kindpfade in einer Transaktion und automatischer Weiterleitung von der alten Adresse. Startseite frei wählbar. Geplantes Veröffentlichen. Revisionsliste mit Vergleich und Wiederherstellung in der Oberfläche. Papierkorb statt sofortigem Löschen.
|
||
|
||
Abnahme: Eine Seite mit Unterseiten wird verschoben; alle alten Adressen leiten weiter, Menüs bleiben intakt.
|
||
|
||
### G – Editor für die tägliche Arbeit
|
||
|
||
*Braucht: C.*
|
||
|
||
Inline-Textbearbeitung direkt in der Vorschau. Globale Farben und Schriften. Header und Footer als bearbeitbare Bereiche. Wiederverwendbare Sektionen mit Unterscheidung zwischen Kopie und globaler Verknüpfung. Autosave mit sichtbarem Zustand. Bildzuschnitt in der Mediathek, Ordner, Paginierung und Unterstützung für PDF und Video.
|
||
|
||
Abnahme: Die Pilotwebsite lässt sich vollständig ohne Code pflegen. Eine geänderte globale Farbe wirkt auf allen Seiten.
|
||
|
||
### H – Plugins und Templates
|
||
|
||
*Braucht: den Erhaltungsvertrag (erledigt).*
|
||
|
||
Registrierung von Blöcken, Einstellungen und Hooks über dokumentierte Schnittstellen. Manifest mit Versionsanforderungen, Abhängigkeitsprüfung, Aktivieren und Deaktivieren ohne Inhaltsverlust. Ressourcen werden nur dort geladen, wo der Block vorkommt. Templatepaket mit Designwerten und Seitenvorlagen; zwei Templates auf denselben Inhalten erprobt. Als Referenzplugin der Chatbaustein des Piloten.
|
||
|
||
Abnahme: Templatewechsel erhält die Inhalte. Das Referenzplugin lässt sich aktivieren, aktualisieren und deaktivieren; seine Blöcke werden bei Deaktivierung kontrolliert dargestellt statt gelöscht.
|
||
|
||
### I – Benutzer, Betrieb und Leistung
|
||
|
||
*Braucht: nichts; teils vorziehbar.*
|
||
|
||
Benutzerverwaltung und Passwortänderung in der Oberfläche. Inhaltscache mit gezielter Erneuerung beim Veröffentlichen. Bildformate und Ressourcenpakete prüfen. Sicherung und Wiederherstellung erproben. Updateverfahren mit Datenbankmigration und Rückfallstrategie dokumentieren.
|
||
|
||
Abnahme: Veröffentlichen macht die Änderung sofort sichtbar und erneuert nur die betroffenen Einträge. Eine Wiederherstellung aus dem Backup ist nachgewiesen.
|
||
|
||
### J – Hosting und MySQL
|
||
|
||
*Braucht: die Antwort von Umut.*
|
||
|
||
Anbieter und Tarif festlegen. MySQL oder MariaDB tatsächlich nachweisen statt nur vorbereiten. Deployment, Dokumentenstamm, Dateirechte, Cronjobs und E-Mail-Versand einrichten. Staging aufsetzen. Erst danach sind Leistungsmessungen aussagekräftig: die bisherigen Lighthouse-Werte stammen von einem lokalen PHP-Server mit kleinen Testinhalten und sagen über das Zielhosting nichts.
|
||
|
||
Abnahme: Die Anwendung läuft auf dem Zielhosting mit MySQL. Messungen mit realen Inhalten liegen vor, einschließlich der Bedingungen.
|
||
|
||
### K – Migration von kant-it.de
|
||
|
||
*Braucht: B, C, D, E, F, H, J und Backendzugang.*
|
||
|
||
Export und Import für Seiten, Beiträge, Medien, Adressen und SEO-Daten. Flatsome-Shortcodes inventarisieren und die tatsächlich vorkommenden Typen auf eigene Blöcke abbilden; unbekannte Inhalte im Importbericht ausweisen und erhalten, nicht verwerfen. Adressen, Medienverweise und interne Links vor und nach dem Umzug vergleichen. Weiterleitungen für alle bestehenden Adressen. Backup und Wiederherstellung erproben, Rückweg zur bisherigen Website vorbereiten.
|
||
|
||
Abnahme: kant-it.de ist vollständig geprüft migriert, der Rückweg ist erprobt. Der Livegang erfolgt erst, wenn Umut ihn ausdrücklich beauftragt.
|
||
|
||
## Bewusst nicht in Version 1
|
||
|
||
Shop und Buchungen, Mehrmandantenbetrieb, zentrale Verwaltung mehrerer Installationen, öffentlicher Pluginmarktplatz, Kommentare, Mehrsprachigkeit über das Datenmodell hinaus und redaktionelle KI. Diese Punkte stehen im Entwicklungsplan als spätere Phasen und werden erst nach dem Pilotbetrieb anhand des tatsächlichen Bedarfs geplant.
|
||
|
||
## Zum Aufwand
|
||
|
||
Der Entwicklungsplan sieht eine Aufwandsschätzung nach dem ersten durchgängigen Prototyp vor. Belastbar schätzen lässt sich erst, wenn der Backendzugang zum Piloten vorliegt: der tatsächliche Beitragsbestand, die Anzahl der Flatsome-Shortcode-Typen und der Umfang von `kant-nova-chat` bestimmen den Aufwand der Pakete B, H und K erheblich. Ohne diese Angaben wäre jede Zahl hier eine Erfindung.
|