IWHWI

IWHWI: KI-Framework zur Verwaltung Ihrer Directus-Inhalte über MCP.

Headless-CMS wie Directus stellen Collections und Felder bereit, während Strapi oder Contentful Content Types und Felder bereitstellen - aber jedes mit eigenen Konventionen, eigenem SDK und eigenen Grenzen. Das Ergebnis: Ihr Content-Modell ist an ein einziges Tool gebunden, Ihre Automatisierungen müssen bei jeder Migration neu erstellt werden und die Industrialisierung bleibt Handarbeit.

IWHWI (Interface Web Headless with Intelligence) ist unser proprietäres Clean-Architecture-Framework, das dieses Problem löst. Es führt eine Abstraktionsschicht über dem CMS ein: Content Types - bestehend aus Nodes (strukturelle Bausteine) und Fields (Business-Felder) - werden im Business-Domain modelliert, unabhängig vom verwendeten CMS-Adapter. Directus, das nativ kein Content-Type-Konzept besitzt (im Gegensatz zu Strapi oder Contentful), ist der erste implementierte Adapter - der komplexeste Fall. Weitere CMS, die dieses Konzept bereits besitzen, werden folgen.

Dank des MCP-Protokolls (Model Context Protocol) kann ein KI-Assistent Strukturen erstellen, Daten synchronisieren, Inhalte übersetzen und den gesamten Lebenszyklus steuern - alles aus einer Konversation heraus. Erfahren Sie unten die Architektur, die Schlüsselkonzepte und die konkreten Fähigkeiten dieses Frameworks.

IWHWI

Clean Architecture und CMS-Abstraktion

IWHWI basiert auf einer Clean Architecture mit vier Schichten: Domain (Entitäten, Nodes, Felder), Infrastructure (CMS-Adapter, Datenquellen), Interface (MCP-Server, KI-Befehle) und Usecase (Fassaden, Services). Die Business-Domain ist vollständig vom CMS entkoppelt: Der Directus-Adapter implementiert eine generische Schnittstelle (ICmsAdapter), die andere CMS implementieren können.

Content Types: eine Abstraktionsschicht über dem CMS

Headless-CMS wie Strapi oder Contentful integrieren das Content-Type-Konzept nativ. Directus hingegen arbeitet nur mit einzelnen Collections und Feldern - ohne Abstraktionsschicht. Deshalb wurde IWHWI ausgehend von Directus, dem niedrigsten Fall, konzipiert und führt Content Types ein, die aus Nodes (strukturelle Bausteine) und Fields (Business-Felder) bestehen. Zum Beispiel wird der Content Type « categories » in IWHWI mit 4 Nodes (1 Init, 2 Lang, 1 Supp) und zusätzlichen Feldern definiert. Unter Directus wird diese Definition automatisch in 3 Collections (categories, categories_base, categories_seo) mit allen nötigen Relationen übersetzt. Der Supp Node ist keine eigene Collection: Er fügt eine Feldgruppe direkt in die Haupt-Collection ein. Diese Abstraktion, für den komplexesten Fall entworfen, lässt sich umso einfacher an CMS anpassen, die dieses Konzept bereits besitzen.

Node-System

  • Init Node: Haupt-Collection (Identifikatoren, Status, Metadaten).
  • Lang Node: Collections verknüpft mit dem Content Type languages (übersetzter Inhalt pro Sprache).
  • Flag Node: Collections verknüpft mit dem Content Type countries (länderspezifische Konfigurationen).
  • Supp Node: Feldgruppen in der Haupt-Collection (Bilder, Einstellungen).

Migration von traditionellen CMS

Dank dieser Abstraktionsschicht kann IWHWI auch als Migrationsbrücke zwischen traditionellen CMS und modernen Headless-CMS dienen. Das Ziel: strukturierte Inhalte einer bestehenden Website - WordPress, Joomla + Seblod, Joomla + K2, Joomla + FlexiContent oder Drupal + CCK - auslesen, auf IWHWI Content Types abbilden und dann an das Ziel-Headless-CMS (Directus, Strapi, Contentful...) übertragen. All diese Systeme speichern Content Types mit benutzerdefinierten Feldern, zugänglich über ihre REST-APIs oder Datenbanken. IWHWI wird in diesen Migrationsszenarien getestet, um diesen Ansatz zu validieren.

Felder in drei Schichten

Die Felder werden CMS-unabhängig auf drei Ebenen verwaltet: Types (Basis-Schnittstellendefinitionen), Generics (wiederverwendbare Business-Felder) und Specifics (Node-spezifische Felder). Jedes Feld ist eine separate Datei, die in den Nodes importiert und zusammengesetzt wird.

Schichtenarchitektur und Node-System
Schichtenarchitektur und Node-System
Schichtenarchitektur und Node-System

Schichtenarchitektur und Node-System

IWHWI folgt einer vierlagigen Domain-Driven Design-Architektur. Die Domain-Schicht definiert Geschäftsentitäten: typisierte Felder (generisch und spezifisch), Nodes (Init, Lang, Supp, Flag) und Content-Typen (Seiten, Blöcke, Kategorien usw.). Jeder Content-Typ wird deklarativ mit seinen Nodes und Feldern deklariert.

Dieser Ansatz stellt sicher, dass das Geschäftsmodell unabhängig von der technischen Infrastruktur bleibt.

Die Infrastructure-Schicht verwaltet Speicherung, Synchronisation und externe Adapter. Daten sind in versionierten Ordnern (aXXXX) organisiert, jeder mit drei Räumen: default (eingefrorene Referenz), directus (aktueller CMS-Zustand) und ia (KI-generierte Inhalte). Registry-Dateien pflegen die Zuordnung zwischen lokalen IDs und Directus-UUIDs.

Dieses System ermöglicht vollständige Versionsverfolgung und Nachverfolgbarkeit jeder Änderung.

Das Node-System strukturiert jeden Content-Typ modular. Init Nodes tragen nicht übersetzbare Felder (Status, Sortierung, Datum). Lang Nodes erzeugen getrennte Sammlungen pro Sprache (Titel, Slug, Beschreibung). Supp Nodes bündeln spezialisierte Felder (Bilder, Medien, Parameter). Flag Nodes fügen optionale Indikatoren hinzu.

Diese Modularität erlaubt das Hinzufügen oder Ändern von Strukturen ohne Auswirkung auf Bestehendes.

Domain-Driven Design Schichtenarchitektur Entitäten Geschäftsmodell Infrastructure Registries Versioning aXXXX-Ordner Synchronisation Init Node Lang Node Supp Node Flag Node Modularität

Source/Sync-Workflow und Datenverwaltung

Der Source/Sync-Workflow ist das Herzstück von IWHWI. Für jeden Content-Typ bietet das Framework Befehle: new (leeren aXXXX-Ordner anlegen), source create (nach Directus pushen), source update (aktualisieren), sync (von Directus holen), source set (zwischen Räumen kopieren). Jede Operation ist atomar und nachverfolgbar.

Dieser Zyklus hält lokale Dateien und Directus dauerhaft synchron.

Daten-Dateien sind im JSON-Format, in nummerierten Ordnern (aXXXX) gespeichert und in Git versioniert. Jede Datei ist zeitgestempelt: default-Dateien haben einen festen Timestamp (1970), directus- und ia-Dateien tragen das tatsächliche Erstellungsdatum. Der auto-Modus wählt automatisch die neuesten Dateien aus allen Räumen.

Diese Organisation ermöglicht Vergleich, Wiederherstellung und Audit jeder Content-Version.

Source/Sync-Workflow und Datenverwaltung
Source/Sync-Workflow und Datenverwaltung
Source/Sync-Workflow und Datenverwaltung

Die automatische Übersetzung ist in den Workflow integriert. IWHWI erkennt fehlende Inhalte pro Sprache und übersetzt sie über Gemini oder Google Cloud Translate. Übersetzungen werden im ia-Raum erzeugt, geprüft und dann nach Directus gepusht. Das System unterstützt fünf Sprachen (fr-FR, en-US, es-ES, de-DE, it-IT) und ist erweiterbar.

Übersetzung wird zu einem automatisierten Schritt im Content-Pipeline, keine manuelle Aufgabe.

Source/Sync Workflow Befehle Lebenszyklus Synchronisation JSON Git Zeitstempel Versioning Audit Automatische Übersetzung Gemini Google Translate Mehrsprachig Pipeline
MCP-Integration und KI-gesteuerte Steuerung
MCP-Integration und KI-gesteuerte Steuerung
MCP-Integration und KI-gesteuerte Steuerung

MCP-Integration und KI-gesteuerte Steuerung

Das MCP-Protokoll (Model Context Protocol) ermöglicht einem KI-Assistenten (Claude, GPT), Aktionen auf externen Systemen auszuführen. IWHWI implementiert einen MCP-Server, der alle seine Befehle als KI-Tools bereitstellt: Erstellung von Directus-Strukturen, Quellenverwaltung, Synchronisation, Übersetzung, Inspektion von Feldern und Relationen.

Die KI schlägt nicht nur vor: Sie führt Operationen direkt auf Ihrem CMS aus.

MCP-Befehle decken den gesamten Lebenszyklus ab: structure (Sammlungen und Felder anlegen/entfernen), source (Items erstellen, aktualisieren, löschen), sync (Directus → lokal synchronisieren), translate (automatisch übersetzen), local (Übersetzungsdateien verwalten), util (Felder, Relationen, Items inspizieren). Jeder Befehl ist dokumentiert und typisiert.

Der KI-Assistent hat volle, sichere Kontrolle über Ihre Directus-Instanz.

IWHWI erzeugt automatisch TypeScript-Typen aus Content-Schemas und gewährleistet Konsistenz zwischen CMS und Frontend-Code. Das Framework unterstützt zwei Umgebungen (alpha und production) mit dedizierten Profilen. Das Ganze ist erweiterbar konzipiert: Ein neuer Content-Typ wird deklarativ hinzugefügt.

Ergebnis: ein vollautomatisierter, typisierter Content-Pipeline, gesteuert durch künstliche Intelligenz.

MCP Model Context Protocol MCP-Server KI-Tools Automatisierung MCP-Befehle Structure Source Translate Lebenszyklus TypeScript Generierte Typen Multi-Umgebung Erweiterbarkeit KI-Pipeline

Mit IWHWI für Ihr Content-Management profitieren Sie von:

  • einem Framework, das die Directus-Content-Verwaltung industrialisieren soll,
  • nativem Anschluss an KI über das MCP-Protokoll,
  • einem versionierten, reproduzierbaren Workflow (Source/Sync) Git-kompatibel,
  • mehrsprachiger automatischer Übersetzung und TypeScript-Typ-Generierung,
  • eine Migrationsbrücke, um Inhalte aus traditionellen CMS (WordPress, Joomla + Seblod/K2/FlexiContent, Drupal + CCK) in ein modernes Headless-CMS zu überführen.

IWHWI macht aus Content-Management einen automatisierten, zuverlässigen Prozess, der von Künstlicher Intelligenz gesteuert wird. Kontaktieren Sie uns für eine Demo.