Page-Builder-Vorschau (Preview-Template) korrekt implementieren
Page-Builder-Vorschau (Preview-Template) korrekt implementieren
~6 Min. Lesezeit Zuletzt aktualisiert am 9. August 2026
content_type.xml aus Kapitel 59 verweist bereits auf preview_component: Mironsoft_Loyalty/js/content-type/points-banner/preview - dieses Kapitel baut sie.
Warum eine eigene Vorschau-Komponente nötig ist
Live-Bearbeiten bedeutet: bei JEDEM Tastendruck im Eigenschaften-Panel muss die Bühne sofort neu aussehen - ohne Server-Rundreise pro Tastendruck. Ein Server-Rundreise passiert nur einmal, beim tatsächlichen Einfrieren des Master-Formats (Kapitel 58/59). Dazwischen übernimmt eine leichtgewichtige, rein clientseitige Knockout-Komponente, die dieselben Attributnamen wie das PHP-Template spiegelt: heading, body_text, cta_label, cta_url, background_color.
define([
'jquery',
'Magento_PageBuilder/js/content-type/preview',
], function ($, Preview) {
'use strict';
/**
* Live-preview component for the "Points Banner" content type. Mirrors
* Block/PageBuilder/PointsBanner.php's defaults (chapter 59) so the WYSIWYG canvas never
* shows a value the frontend template wouldn't also show.
*/
return Preview.extend({
defaults: {
template: 'Mironsoft_Loyalty/content-type/points-banner/preview',
},
/**
* Returns the heading, falling back to the same default text as the PHP block.
*
* @returns {String}
*/
heading: function () {
var value = this.dataStore.get('heading');
return value ? value : $.mage.__('Earn points on every order');
},
});
});<div class="pagebuilder-points-banner"
data-bind="style: { backgroundColor: data.background_color() || '#0f172a' }">
<h2 data-bind="text: heading()"></h2>
<!-- ko if: data.body_text() -->
<p data-bind="text: data.body_text"></p>
<!-- /ko -->
<!-- ko if: data.cta_label() -->
<span class="pagebuilder-points-banner-cta" data-bind="text: data.cta_label"></span>
<!-- /ko -->
</div>Ein bewusster Unterschied: die Call-to-Action
Achtung: Der Call-to-Action-Button ist in der Vorschau absichtlich ein <span>, kein echter <a href> wie im Frontend-Template aus Kapitel 59: Ein echter Link würde bei einem Klick während der Bearbeitung sofort aus Page Builder heraus navigieren. Die Vorschau und das Frontend-Template dürfen - müssen sogar - an genau dieser einen interaktiven Stelle voneinander abweichen, sonst könnten Redakteurinnen nicht mehr gefahrlos in der Nähe der Schaltfläche klicken, während sie die Seite zusammenstellen.
Achtung: preview.html und default.phtml sind zwei unabhängig gepflegte Dateien ohne gemeinsame Quelle der Wahrheit - der klassische Page-Builder-Wartungsfallstrick. Ändert eine spätere Anpassung z. B. die Standard-Hintergrundfarbe in PointsBanner::getBackgroundColor(), aber vergisst den JS-Default in preview.js, lügt die WYSIWYG-Bühne stillschweigend über das tatsächliche Ergebnis. Empfehlung: nach jeder Änderung an einer der beiden Dateien sowohl den Page-Builder-Editor als auch die Live-Storefront-Seite nebeneinander prüfen, bevor gemergt wird.
Tipp: preview.js und preview.html nutzen Knockout.js - und das ist völlig in Ordnung. CLAUDE.mds "kein Knockout.js"-Regel gilt für das Hyvä-Storefront-Theme, nicht für view/adminhtml-Assets: Der Magento-Admin baut seit Version 2.0 durchgehend auf Knockout.js und UI Components auf, vollständig unabhängig vom Hyvä-Theme-Wechsel im Frontend. Hier verstößt nichts gegen die Projektkonvention.
Vorschau testen
Neue Dateien unter view/adminhtml/web/ brauchen einen Static-Content-Deploy-Lauf, der auch den Admin-Bereich mit einschließt - anders als reine Layout-XML-Änderungen (Kapitel 51) reicht hier kein bin/cache-clean layout:
cd src && rm -rf var/view_preprocessed/* pub/static/frontend/* pub/static/adminhtml/*
bin/magento setup:static-content:deploy de_DE -f
bin/cache-clean config block_html full_pageOhne -t/--area-Einschränkung deployt dieser Befehl beide betroffenen Bereiche - Frontend-Template aus Kapitel 59 UND die neuen Admin-JS-/Knockout-Dateien dieses Kapitels - in einem Schritt.