KantSites/docs/AUSBAUPLAN.md

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.

G2 – Freie Bereiche, Rich Text und eigener Code (Nutzerauftrag vom 12.09.2026)

Umut hat den Umfang von G erweitert. Vier Punkte, in dieser Reihenfolge:

1. Kopf- und Fußbereich frei aus Elementen bauen — erledigt am 12.09.2026 (ADR 026). Ursprünglicher Wortlaut: Kopf- und Fußbereich frei aus Elementen bauen, genau wie eine Sektion – keine feste Marke, keine feste Navigation im Template. Dazu wiederverwendbare Sektionen, die verknüpft und nicht kopiert werden: eine Änderung erreicht jede Seite, die sie nutzt.
2. Rich Text in Textelementen — erledigt am 12.09.2026 (ADR 027). Umgesetzt für Textblöcke mit Werkzeugleiste und HTML-Ansicht; gefiltert wird auf dem Server beim Speichern. Überschrift, Button und Zitat bleiben bewusst Klartext.
3. Eigenes CSS und eigenes Skript je Element. — erledigt am 12.09.2026 (ADR 028). Ursprünglicher Wortlaut: Eigenes CSS und eigenes Skript je Element. Eigenes CSS ist unkritisch und für alle mit Editorrolle nutzbar. Eigenes Skript ist es nicht: es ist gespeichertes, ausführbares JavaScript auf der Website. Wer es setzen darf, kann Code im Browser jedes Administrators ausführen. Deshalb: nur für Administratoren, Ausgabe über eine seiteneigene Skriptdatei statt inline, keine Ausführung in der Editorvorschau, und script-src 'self' nur auf Seiten, die tatsächlich ein Skript tragen. Der Preis steht in der Oberfläche.
4. Verwaltung neu gestalten — erledigt am 12.09.2026 (ADR 029). Der Editor behält seinen Aufbau und übernimmt die neue Gestaltung; neu gebaut sind der Rahmen, die Navigation, die Seitenliste und die Formularseiten. Ursprünglicher Wortlaut: Verwaltung neu gestalten – einfacher, schöner, ohne Nachdenken bedienbar. Gestaltungsfreiheit ausdrücklich bei mir; der bisherige Stil ist nicht bindend. Das betrifft Navigation zwischen den Bereichen, die Seitenliste, die Panels im Editor und die Formularseiten, die derzeit alle als lange Formulartabellen gebaut sind.

Abnahme: Kopf- und Fußbereich sind im Editor gestaltbar und öffentlich sichtbar. Eine verknüpfte Sektion auf zwei Seiten ändert sich an beiden Stellen gleichzeitig. Ein Textelement lässt sich formatiert und als HTML bearbeiten, und keine Auszeichnung außerhalb der Positivliste übersteht das Speichern. Eigenes CSS wirkt, eigenes Skript wirkt nur für Administratoren gesetzt und nur auf der veröffentlichten Seite. Die Verwaltung ist ohne Anleitung bedienbar.

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. — erledigt am 12.09.2026 (ADR 030). Offen bleibt der Rest des Pakets: Inhaltscache mit gezielter Erneuerung beim Veröffentlichen. Bildformate und Ressourcenpakete prüfen. Sicherung und Wiederherstellung erproben. Updateverfahren mit Datenbankmigration und Rückfallstrategie dokumentieren — geplant am 12.09.2026 in docs/UPDATE.md: neue Version über einen Git-Tag ziehen, mit Vorprüfung, Sicherung, Wartungszustand, Migration, Rauchtest und Rückweg. Umsetzung offen; zwei Entscheidungen hängen am Hosting (Composer auf dem Server oder vendor/ im Tag, und ob es Shell-Zugriff gibt).

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.