PageMeister

PageMeister ist das Grundgeruest fuer ein modernes WordPress-Plugin, das langfristig als visueller Page-Builder mit HTML-Import und HTML-Export ausgebaut wird.

Projektstatus

Der aktuelle Stand enthaelt die technische Foundation des Plugins:

• WordPress-Plugin-Einstiegspunkt mit Plugin-Header
• OOP-Bootstrap mit Namespace-basiertem Autoloading
• Aktivierungs-, Deaktivierungs- und Uninstall-Logik
• Admin-Menue PageMeister mit erstem Builder-Einstiegspunkt
• Capability-Schicht fuer Builder-Zugriff
• Builder-Adminseite mit App-Root (#pagemeister-app-root)
• vorbereitete Ordnerstruktur fuer Admin, Builder, Rendering, Import, Export und Tests
• saubere, screen-spezifische Einbindung der Editor-Assets
• Vite-, React- und TypeScript-Build-Setup fuer den Editor

Installation

1. Den Plugin-Ordner in wp-content/plugins/pagemeister ablegen.
2. Im WordPress-Admin das Plugin PageMeister aktivieren.
3. Sicherstellen, dass die Zielumgebung mindestens WordPress 6.5 und PHP 8.1 verwendet.

Entwicklung

Die Plugin-Foundation orientiert sich an einer modularen Struktur:

• pagemeister.php startet das Plugin und registriert zentrale Hooks.
• includes/Core enthaelt Bootstrap, Autoloader und Lifecycle-Klassen.
• includes/Admin ist fuer spaetere Admin- und Editor-Integration vorgesehen.
• src/editor enthaelt die React-TypeScript-Quellen fuer den Builder.
• src/editor/components, src/editor/stores und src/editor/utils trennen UI, Status und Hilfsfunktionen.
• build/editor ist das Ziel fuer gebaute Assets aus Vite.

Frontend-Build

Verfuegbare Skripte:

• npm install installiert alle Frontend-Abhaengigkeiten.
• npm run dev startet den Vite-Dev-Server fuer die Editor-Entwicklung.
• npm run build schreibt das Produktionsbundle nach build/editor.
• npm run preview startet eine lokale Vorschau des Vite-Bundles.
• npm run lint prueft das Frontend inklusive Tests per ESLint.
• npm run typecheck prueft die TypeScript-Typen.
• npm run test:unit fuehrt Frontend-Unit-Tests mit Vitest aus.
• npm run test:e2e startet die Playwright-Grundlage fuer Builder-Flows.
• npm run check kombiniert Typecheck und Produktionsbuild.

Custom Widget SDK

PageMeister enthaelt jetzt eine erste SDK-Grundlage fuer externe Widgets.

• Die Runtime-API wird im Builder unter window.PageMeisterWidgetSDK bereitgestellt.
• Widgets koennen zur Laufzeit registriert werden und erscheinen danach in Bibliothek, Properties und Command-System.
• Freie Kategorien werden unterstuetzt; die linke Sidebar gruppiert registrierte Widgets dynamisch.
• Deklarative Export-Mappings koennen direkt am Widget hinterlegt werden und werden vom PHP-HTML-Export fuer unbekannte Widget-Typen verwendet.
• Widget-spezifische Frontend-Assets koennen serverseitig ueber den Filter pagemeister_widget_assets angebunden werden.

Dokumentation:

• docs/sdk/README.md
• docs/sdk/custom-widgets.md

Frontend Rendering und Asset-Loading

PageMeister enthaelt nun eine serverseitige Frontend-Rendering-Schicht mit klar getrennten Verantwortlichkeiten:

• includes/Rendering/CssGenerator.php
  • generiert CSS aus globalen Design-Tokens (:root-Variablen) und widget-spezifischen Styles pro Node
  • erzeugt responsive Regeln fuer Desktop/Tablet/Mobile inkl. Sichtbarkeits-Logik
  • haengt optional settings.customCss am Ende an
• includes/Rendering/WidgetAssetRegistry.php
  • ermittelt benoetigte Widget-Assets nur fuer verwendete Widgets
  • Standard-Konvention: assets/frontend/widgets/<widget-type>.css|js
  • ist ueber den Filter pagemeister_widget_assets pro Widget erweiterbar
• includes/Rendering/FrontendAssetLoader.php
  • Hook: wp_enqueue_scripts
  • laedt nur auf singulaeren Frontend-Seiten mit gespeichertem PageMeister-Modell
  • registriert generiertes CSS als Inline-Style und enqueued nur gefundene Widget-Assets
  • verwendete Widgets werden aus dem nodes-Baum ermittelt

Wichtige WordPress-Integrationspunkte

• PageMeister\Core\Plugin::registerHooks() registriert wp_enqueue_scripts fuer den Frontend-Loader.
• PageMeister\Builder\PageModelRepository::hasStoredModel() verhindert unnoetige Frontend-Arbeit auf Seiten ohne Builder-Modell.
• Filter pagemeister_frontend_widget_types erlaubt Anpassung der erkannten Widget-Liste vor dem Enqueue.

Beispiel fuer Widget-Assets

• assets/frontend/widgets/image.css
• assets/frontend/widgets/button.js

Nur wenn image oder button im aktuellen Seitenmodell vorkommen, werden diese Dateien geladen.

Naechste Schritte

1. JSON-Seitenmodell und REST-Endpunkte fuer Speichern und Laden definieren.
2. Erste Widget-Registry mit Basis-Widgets implementieren.
3. Die Builder-UI auf Topbar, Seitenleisten und Canvas ausbauen.