WPTransformer — Abstract

Form follows function. By design.

Was es ist

WPTransformer ist kein Framework.
Es ist kein SaaS.
Es ist kein Abonnement das nie aufhört zu laufen.

Es ist ein Prozess mit Haltung —
und ein Werkzeug das der Maschine erlaubt zu atmen.

Das Problem mit Maschinen die nur pusten

Cloud-Systeme schlafen nie.
Sie patchen. Sie updaten. Sie senden Daten. Sie berechnen.
Wenn WordPress läuft, läuft PHP, läuft MySQL, läuft der Angriff.
Wenn Joomla läuft, läuft die Oberfläche — und die Hintertür gleich mit.

Die Maschine hat keine Zeit zu atmen.
Das ist kein Kodex.

Cloud denkt:    always on → always connected → always vulnerable
Wald denkt:     Offline by Default → No Central Command → Data doesn't exist

WPTransformer ist der Übergang zwischen beiden Welten.

Die Transformierung: Von Rohdaten zum Vektor

Rohdaten                SQL Dump · Joomla Export · Leerer Brief
    │
    ▼
WPParser                Extraktion — pure PHP, kein Server nötig
    │
    ▼
Intermediate Layer      Editierbare Zwischenschicht in DB
    │                   ← hier hält der Mensch inne →
    │                   ← hier atmet die Maschine →
    ▼
StaticBuilder           HTML · CSS · JS — nichts mehr, nichts weniger
    │
    ▼
Vektor                  USB-Stick · ZIP · FTP · Hugo Deploy Node
    │
    └──→ Nullfeld Sync  VPN → 194.164.194.191 · #local #offline

Der Output ist kein Website-System mehr.
Es ist ein Vektor — eine in sich geschlossene, portable Einheit.
Läuft auf USB. Läuft auf Rasperry Pi. Läuft im Rechenzentrum.
Ohne PHP. Ohne Datenbank. Ohne laufende Kosten.

Static ist nachhaltig

Nachhaltig bedeutet nicht: billig.
Nachhaltig bedeutet: langlebig, wartungsarm, unabhängig.

Ein statischer Output ist nicht "fertig".
Er ist unvergänglich — bis jemand ihn bewusst verändert.

Das ist der Kodex-Gedanke: ls -la. Alles prüfbar. Alles lesbar. Für immer.

Der Human Loop — der Atemzug

Automatisierung kann konvertieren.
Hugo kann bauen. Gatsby kann bauen. Dutzende Tools können bauen.

Was sie nicht können: innehalten.

Parse → Build → [ HOLD ] → Commit → Deploy
                    │
                    └── Ein Mensch sieht es.
                        Stimmt die CI?
                        Passt die Typo?
                        Fehlt eine Seite?
                        Ist der Ton richtig?

Der Human Loop ist kein Engpass.
Er ist das Feature — der Atemzug der die Maschine menschlich macht.

Qualitätssicherung die kein Algorithmus ersetzt.
Haltung die kein Deployment-Script hat.

Das Archiv — was nie deployed wird, bleibt trotzdem

WordPress vergisst nicht.
Aber WordPress verfault.

WPTransformer vergisst auch nicht —
aber es verfault nicht.

SQL-Import (vollständig)
    │
wpt_posts           Alle Posts · Alle Pages · Alle Entwürfe
    │                   ← hier entscheidet der Mensch →
    │
    ├── Deploy        → public/ · statisch · sichtbar
    └── Archiv        → bleibt in der DB · unsichtbar · unveränderlich lesbar

Der Kunde bringt 10 Jahre WordPress.
Davon gehen vielleicht 40% live.
Die anderen 60% verschwinden nicht —
sie leben im Intermediate Layer,
durchsuchbar, editierbar, exportierbar.

Kein Cloud-Bucket. Kein Backup-Plugin das irgendwann nicht mehr läuft.
Ein Ordner. Eine Datenbank. ls -la. Alles prüfbar.

Das ist der Unterschied zwischen Migration und Übergabe:
Migration nimmt das Neue und wirft das Alte weg.
Übergabe nimmt alles — und lässt den Menschen entscheiden, was sichtbar wird.

Hugo als Deploy-Knoten

Hugo ist das schnellste Static-Site-Build-System der Welt.
Eine Binary. Eine Config. Ein hugo Befehl.

hugo --minify → /public/
rsync /public/ user@rz:/var/www/kunde/

Kein Node.js. Kein npm-Hell. Kein Lock-in.
Jedes Rechenzentrum nimmt das. Keine Diskussion.
Crumbforest-kompatibel: ls -la zeigt alles.

Nullfeld-Sync: #local #offline

Der Output kann überall leben:

USB-Stick           → Kunde hat alles lokal. Kein Internet nötig.
ZIP-Download        → Archiv. Unveränderlich. Beweisbar.
FTP-Deploy          → Klassisches Shared Hosting. Läuft überall.
Hugo-Build          → RZ-fertig. Professionell. Schnell.
VPN-Sync Nullfeld   → 194.164.194.191 · Crumbforest-intern · #offline

Der Nullfeld-Sync bedeutet:
Das transformierte Werk landet im Herz des Waldes —
nicht in einem Cloud-Bucket den jemand anderes kontrolliert.

Offline by Default. No Central Command. Data doesn't exist — ausser wo wir es wollen.

Der Stack (Schichten, keine Abhängigkeiten)

Crumbforest         Infrastruktur · Haltung · Lizenz (das Holz darunter)
    │
WPTransformer       Prozess · Extraktion · Human Loop (der Werkzeugmacher)
    │
Hugo                Deploy-Knoten · Build · Publikation (der Bote)
    │
Rechenzentrum       Statische Files · Kein PHP · Kein MySQL (das Ziel)

Jede Schicht ist austauschbar.
Nur die Haltung ist unveränderlich.

Quellen (Input-Typen)

Was das für den Kunden bedeutet

Was das für uns bedeutet

Wir sind nicht die Billig-Migration.
Wir sind die betreute Übergabe —
mit einem Menschen der innehalten darf,
bevor etwas unveränderlich live geht.

Das rechtfertigt den Preis.
Das erklärt den Mehrwert.
Das ist das Alleinstellungsmerkmal.

"Wenn die Maschine nur pustet und keine Zeit zu atmen hat —
klingt das nicht nach Kodex."

"Code ist nicht neutral. Architektur ist Haltung."
— Crumbforest · B.W.A · Nullfeld · Hamburg

Crumbforest · Bits With Attitude
MIT License · CKL v1.0
ls -la. Alles prüfbar. Alles lesbar. Für immer.