tl;dr: Über die Migration einer Website von Elementor zu Bricks. Praktische Erfahrungen und Learning. Warum? Weil Elementor 4 nicht fertig ist und Elementor 3 veraltet. Weil die Konzepte ähnlich sind und die Website nach der Migration wie vorher funktionieren soll.
Und zwar schneller, besser und zuverlässiger ohne dass der Besucher zu viel merkt.
Zum Einsatz kommt wieder der MCP Novamira und eine KI - nicht ausführend, sondern als Informationsquelle, Protokolldroide und Aufpasser, damit ich mich nicht in den Details verrenne sondern das Projekt auch abschliesse.
Das ist mein erstes echtes Bricks-Projekt. Daher sind manche Dinge vielleicht noch nicht ganz Ideal gelöst. Deswegen übt man ja mit eigenen Sites und nicht mit Kundenprojekten.
Die Website form.at (mein persönlicher Fotoblog) funktioniert wunderbar. Es ist eine auf den ersten Blick sehr einfache Seite. Bilder auf der Startseite in 3 Kategorien, Detailseite, fertig. Organisiert sind die Bilder in einem Posttyp Foto (mit ACF) und einigen Metadaten zu jedem Bild (Exif-Daten) die in eigenen Feldern gespeichert werden.
Die Website war übrigens Vorbild für den Artikel Fotoblog selber bauen vom 12.1.2025.
Ziel: herauszufinden ob/wie man aus Elementor-Pro basierten Seiten rauskommt und in ein anderes System reinkommt. Hier Bricks, könnte bei einem anderen Projekt aber auch Gutenberg sein.
Warum? Elementor hat verschlafen. Die Entwicklung von Elementor 4 hat zu spät begonnen, der Launch war zu früh, die Qualität ist irgendwo zwischen mäßig und schlecht. Wenn ich jetzt ein Projekt beginne setze ich nicht mehr auf Elementor. Es besteht jedoch (noch) kein Grund diese Plattform zu verlassen - was aber, wenn der Grund kommt?
Wie? Zuerst mal eine lokale Kopie der Website erstellen. Diese wird mit Novamira mit der AI verknüpft. Die AI hilft beim Erstellen und Einhalten des Migrationsplanes. Sie kann die Datenbank ordentlich bereinigen, protokolliert und Informiert wenn gewünscht. Und: Novamira unterstützt Elementor und Bricks und Gutenberg. Mehr über den Einstieg in Novamira hier.
Wer Lust hat kann versuchen den Prozess auch ganz von der AI machen zu lassen (übrigens kann sie auch Ele3 zu Ele4), aber die Geduld hatte ich nicht und das war/ist auch nicht mein Ziel von KI in WordPress.
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:
Anklicken zur Großansicht! Die beiden unteren Screenshots wurden in der Responsively-App erstellt (wer's nicht kennt: hier kostenlos holen). Grundsätzlich war es kein Problem, das bestehende Design nachzubauen. Bewusst akzeptierte Unterschiede waren in der Seitennavigation: es ist mir intuitiv nicht gelungen statt einer Nummerierung nur Pfeile zu bekommen. Ausserdem gibt es unter Bricks auf der Detailseite einen Fehler bei der Ausrichtung. Die Änderung an der Startseite Mobil war bewusst (3 Bilder quer statt eines hoch).
Nach Aussen hin also alles gut oder eben akzeptabel. Schauen wir uns die Installation auf WordPress-Ebene an
Theme: Hello Elementor
Plugins:
Advanced Custom Fields
Dynamic Content for Elementor
Elementor
Elementor Pro
Main WP Child
Werkform Foto Importer
WP Staging
WP Staging Pro
Theme: Bricks
Plugins:
Advanced Custom Fields
Main WP Child
Werkform Foto Importer
WP Staging
WP Staging Pro
Für den Betrieb selber benötige ich eigentlich nur ACF und Werkform Foto importer (ein eigenes Plugin, das EXIF-Daten aus den JPG-Dateien in ACF-Felder kopiert). Main WP und Staging dienen Backup und Wartung, haben also mit der konkreten Website nichts zu tun.
Eine weitere Zahl ist die Dateigröße des aktuellen Backups. Da ja Bricks ein Theme ist wird nicht nur die Anzahl, sondern auch die Datenmenge geringer.
Archivgröße: 491 MB
Archivgröße: 437 MB
Wir haben hier also eine Verkleinerung von 11 % (54 MB) beim aktuellen Datenbestand. Auch wenn es nicht gerade populär ist: weniger Daten ist immer besser und billiger. Und wann wurde es eigentlich egal, wie fett die Plugins geworden sind?
Eine weitere Kennzahl (mit Vorsicht geniessen, die Details würde hier viel zu weit führen) sind die Zeilen HTML-Code die ausgeliefert werden. Ich weiss schon, dass Zeilen alleine wenig aussagen, aber eine klare Tendenz darf man schon daraus ableiten:
Startseite: 594 Zeilen
Fotoseite: 514 Zeilen
Startseite: 133 Zeilen
Fotoseite: 127 Zeilen
Ausserdem hat sich mit dem Systemwechsel das Designsystem verändert. Ich habe mir vor und nach dem Change eine DESIGN.md anlegen lassen. (Mehr über die DESIGN.md in diesem Artikel). Da Bricks viel konsequenter und CSS-näher als Elementor 3 ist kann und sollte diese größer sein. Hier als Beispiel zum Download für alle, die wirklich ins Detail gehen wollen .zip einer .md-Textdatei:
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.
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.
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.
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
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,
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.
Technische Dinge sind für uns Nerds immer spannend, aber sogar wir wissen: das muss sich rechnen. Im Vorfeld ist das immer schwer, also habe ich mir den Zeitaufwand des Projektes genau angeschaut. Hier muss man unterscheiden: in den Lernaufwand und die reine Migrationsarbeit. Die gerundete Wahrheit bei diesem Beispiel: es hat 12 Stunden gedauert. Davon sind aber nur 4 der Anwendung zuzuordnen, 8 waren lernen, testen, suchen, fragen, lesen...
Ich kann also behaupten, dass die Migration einer einfachen Site in sicher 3 Stunden machbar ist, wenn Posttypen dazukommen nochmal 2 Stunden dazu. Genauer kann man es wohl nicht sagen, dazu sind die Projekte zu verschieden.
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
Im Erstgespräch schauen wir uns deine aktuelle Site an und ich sage dir ehrlich, was Sinn macht und was nicht. Kostenlos, unverbindlich, online.
Erstgespräch buchenFü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:
- 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)
| Aspekt | Elementor | Bricks | Bewertung |
|---|---|---|---|
| Theme | Hello Elementor | Bricks Child | neutral |
| Breakpoints | 3 Stufen (default) | 4 Stufen (+Mobil Quer) | Verbesserung |
| HTML font-size | Browser-Default 16px | 62.5% Trick = 10px Basis | Bricks-Spezifikum |
| H1-H6 | nicht im Kit definiert | explizit definiert | Verbesserung |
| Spacing-Skala | nicht vorhanden | fluid clamp()-Skala | Neues Feature |
| Query Loop | DCE Widget | nativer Container | Konzept vereinfacht |
| Loop-Item Template | separates Template | inline im Container | Vereinfachung |
| OffCanvas | Footer-Template | Single-Template | Konzept verbessert |
| Komponenten | Globale Widgets | Komponenten-System | neutral |
| DB-Overhead | hoch (Elementor Meta) | gering | Verbesserung |
| Archivgröße | 491 MB | 437 MB | Verbesserung |
- 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
- Fluid Spacing Scale: automatisch generierte clamp()-Werte
- 4. Breakpoint: Mobil Querformat
- Sauberere Datenbankstruktur
- Variablen-System, Klassen-Management, etc.
Ich bilde mir ja ein so ungefähr zu wissen, wie Websites in WordPress funktionieren. Das kann problematisch sein, weil das vermeindliche Wissen der Realität des Tools widersprechen kann. Immer problematisch ist natürlich das Wording auf deutsch - hier hat der Bricksbuilder einen Vorteil: ein führender Kopf hinter dem Tool ist Deutscher, das verbessert die Übersetzungen ungemein.
Was bleibt sind technische, philosophische und stilistische Unterschiede. Hier eine unnvollständige und naturgemäß sehr subjektive Liste an Learnings, die so angefallen sind. Kann sein, dass hier auch nur meine Fehler stehen, dann bitte -> Kommentieren!
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.
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.
Nicht im WordPress-Admin. Wer danach sucht, findet sie nicht. Builder > Einstellungen (Zahnrad) > Template-Bedingungen.
Nicht unter Einstellungen wie in Elementor. Builder-Toolbar > Drei-Punkte-Icon > Breakpoint-Manager.
Bricks rendert SVG-Elemente als <svg class="brxe-svg meine-klasse">. 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); }
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 {format_date} Tag (ab Bricks 2.2):
{format_date @date:'{acf_erstellungsdatum}' @from:'Y-m-d H:i:s' @to:'d.m.Y'}
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).
Bricks taugt nicht zum einfach mal Klicken, zuerst ein Design-System bauen, dann umsetzen. Für besonders Kreative mag das ungewohnt sein, aber es zwingt zu Ordnung.
Bricks ist per se nicht besser als Elementor, zeigt aber Vorteile. Besonders wenn es um Konsistenz und Geschwindigkeit geht.
Es benötigt mehr Lernaufwand als Elementor 3, funktioniert aber besser als das unfertige Elementor 4. Eine Migration von Elementor 3 gelingt je nach Komplexität und Qualität der Ausgangssituation sicher - aber: vorher Müll wird nicht nachher gut - da hilft nur aufräumen.
Sie sehen gerade einen Platzhalterinhalt von Vimeo. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr InformationenSie sehen gerade einen Platzhalterinhalt von YouTube. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr Informationen