Die Aufgabe

Das Ergebnis

Vergleichen wir zuerst das Ergebnis. Die Live-Version ist hier: form.at. Es gibt viele gute theoretische Systemvergleiche (hier der von M. Baierl). Uns interessiert die Praxis:

Elementor

Bricks

Der Stufenplan

Vor dem ersten Klick im Builder habe ich einen Stufenplan erstellt. Das hat verhindert, dass ich irgendwo mittendrin steckenbleibe. Hier kommt die KI zum Einsatz: Pläne machen und protokollieren kann sie hervorragend.

0 - Vorbereitungen

Zuerst wurde eine lokal Installation der bestehenden Seite mit Hilfe von WP-Staging und Local durchgeführt (über lokales WordPress hier weiterlesen). Danach kann man die Plugins bereinigen: Caches, Securtity u.ä. benötige ich nicht, die können eher störend sein. Danach das Theme Bricks installiert (und das Child-Theme dazu), man weiss im Vorfeld ja nicht ob es notwendig wird). Novamira Pro aktiviert und mit der AI verbunden (bei mir Claude Desktop), das Projekt in Claude gestartet und die DESIGN.md einlesen lassen. Das Projekt als Prompt beschrieben.

1 - Design-System in Bricks einrichten

Schriften, Farben, Typographie, Breakpoints, Content-Breite. All diese Definitionen liegen vor und müssen in Bricks eingepflegt werden. In meinem Fall war das der wichtigste Teil der Lernerfahrung. Wo ist was? In diesem Schritt wird man zwangsläufig mit dem Interface vertraut und auch - wenn man so will - mit der Denke des Systems. Begriffe und Organisation des Systems muss man einfach lernen.

2 - Templates bauen

Der vom Zeitaufwand her größte Block. Es mussten 5 Templates erstellt werden:
1. Der Header (leer)
2. Der Footer (in Elementor gab es 2, hier nur mehr einen, dafür im Foto-Template ein OffCanvas.
3. Single Foto, hier gibt es Landscape- und Portrait-Format, die jeweils eigene Sektionen benötigen und je nach Foto über Bedingungen ein/ausgeblendet werden.
4. Startseite mit der Query-Loop und Seitennummerierung
5. Kategorie/Archivseite, optisch und funktional wie die Startseite

3 - Theme Wechsel und Verifikation, DB-Bereinigung

Elementor und seine Derivate konnten nun endgültig gelöscht werden, nachdem Design und Funktion im Backend und Frontend überprüft wurden. Vor Schritt 4 wurde nochmal ein Backup des Zwischenschrittes gemacht.
Danach hat die KI eine DB-Bereinigung durchgeführt - das Löschen der Plugins belässt ja die Daten von Elementor. In diesem Fall wurden 2992 Einträge aus der DB entfernt,

4 - Launch

Vor dem Launch wurde noch das Matomo-Snippet für die lokale Analyse hinzugefügt. Ausserdem eine neue DESIGN.md erstellt. Danach das Migrations-File erzeugt und auf der Live-Site eingespielt. Fertig.

Aufwandsermittlung

Hier noch der Aufwand aufgeschlüsselt nach dem obigen Stufenplan aus dem Protokoll:
Stufe 1: Einrichten, einspielen etc.: 2,5 Stunden
Stufe 2: Templates: 8 Stunden
Stufe 3: 30 Minuten
Stufe 4: 1 Stunde

Systemunterschiede - ein Vergleich

Für WordPress-Profis und Admins ist es natürlich interessant zu wissen, was sich verändert hat und was nicht. Hier eine Aufzählung der relevanten Dinge:

Was gleich geblieben ist

- Visuelles Ergebnis: identisch. Kein Besucher würde den Unterschied sehen.
- Farbpalette: dieselben 7 Farben, nur andere Variablennamen
- Schrift: Exo, dieselben Schnitte, dieselbe font-size (16px effektiv)
- Content-Breite: 1140px
- ACF-Daten: vollständig erhalten, kein Datenverlust
- Custom Post Type 'foto': unverändert
- Leerer Header als Workaround (das Design hat keinen Header)

Was sich verändert hat

Was wegfällt

Was wegfällt

- DCE (Dynamic Content for Elementor): vollständig ersetzt durch Bricks native Dynamic Data
- Elementor Overhead in Widgets (oder Elementor Manager Konfiguration)
- Loop-Item Templates als separate Posts: nicht mehr nötig

Was dazukommt

- Fluid Spacing Scale: automatisch generierte clamp()-Werte
- 4. Breakpoint: Mobil Querformat
- Sauberere Datenbankstruktur
- Variablen-System, Klassen-Management, etc.

Learnings in Bicks

Bricks denkt anders als Elementor

Display/Grid sitzt unter Inhalt, nicht unter Stil

In Bricks steuert Inhalt > Anzeige wie Kinder angeordnet werden (Grid, Flex als Container). Stil > Sonstiges > Display steuert wie das Element selbst im Fluss erscheint. Elementor hat diese Trennung anders - anfangs verwirrend, nach dem Verstehen ok.

Query Loop ist kein eigenes Widget.

Jeder Container kann zur Abfrageschleife werden. Das ist konzeptuell sauberer als Elementors Loop Grid / DCE Dynamic Posts. Die Struktur: äusserer Container als Grid-Wrapper, innerer Container mit aktivierter Abfrageschleife.

Template-Bedingungen sind nur im Builder zugänglich

Nicht im WordPress-Admin. Wer danach sucht, findet sie nicht. Builder > Einstellungen (Zahnrad) > Template-Bedingungen.

Breakpoints sitzen in der Builder-Toolbar.

Nicht unter Einstellungen wie in Elementor. Builder-Toolbar > Drei-Punkte-Icon > Breakpoint-Manager.

SVG-Icons brauchen besonderes CSS

Bricks rendert SVG-Elemente als <svg>. Der Selektor .meine-klasse svg { fill: ... } findet nichts - weil `.meine-klasse`das SVG-Tag selbst ist, nicht ein Elternelement. Korrekt:

.meine-klasse.brxe-svg { fill: var(--form-weiss); }
.meine-klasse.brxe-svg:hover { fill: var(--form-rot); }

ACF Date Time Picker ist ein Sonderfall

Bricks liest ACF Date Time Picker Felder als Raw-DB-Wert ('Y-m-d H:i:s'), nicht als formatierte Ausgabe. {acf_erstellungsdatum} gibt nichts aus. Lösung mit dem Tag (ab Bricks 2.2):

{acf_erstellungsdatum}

Farbpalette: 8-stelliges Hex für Alpha

Bricks akzeptiert rgba() in der Farbpalette stillschweigend, zeigt die Farbe aber nicht im Editor-Farbpicker an. Für Farben mit Alpha-Kanal: 8-stelliges Hex verwenden (#RRGGBBAA). Beispiel: Schwarz 70% = #000000B2 (70% von 255 = 178 = B2 hex).

Fazit