Smart Data Synchronizer
+ QUELLE → ZIEL
Mehrere Systeme, eine Leitung
Die Extension wird auf mindestens auf einer Quellsystem- und einer Zielsystem-Instanz installiert. Das Quellsystem überträgt die gewünschten Informationen via Magento WebAPI. Das Zielsystem nimmt sie entgegen und legt sie an – oder aktualisiert sie, falls sie schon existieren.
+ TYPISCHE SZENARIEN
Wer mit "Smart Data Synchronizer" arbeitet
Staging → Live
Kampagnenseiten und neue Produkte in Ruhe auf dem Staging bauen, prüfen lassen und dann gezielt einzeln freischalten. Ohne Datenbank-Dump, ohne Deployment-Fenster.
Mehrere Ländershops
Separate Magento-Installationen für DE, AT und CH. Ein Produkt wird einmal gepflegt und geht mit einem Klick in alle Instanzen, die es haben sollen.
Agentur und Kunde
Vorlagenseiten und Blockbibliotheken zentral pflegen und in Kundeninstanzen ausrollen – ohne dass jemand Zugriff auf die Produktionsdatenbank braucht.
Relaunch mit Parallelbetrieb
Während der neue Shop entsteht, laufen die alten Inhalte weiter. Änderungen aus dem Tagesgeschäft ziehen Sie stückweise in die neue Instanz nach.
B2B- und B2C-Instanz
Gemeinsame Stammdaten, getrennte Systeme. Über die Feldauswahl gehen Texte und Bilder mit, die Preislogik bleibt je Instanz eigenständig.
Notfall-Nachpflege
Ein Tippfehler in der Kategoriebeschreibung, drei Systeme betroffen. Korrigieren, Data Sync, erledigt – statt dreimal einloggen.
+ WARUM ÜBERHAUPT
Der Weg von Staging nach Live kostet Sie jedes Mal einen halben Tag
bisher
Export, Datei, Import, Nacharbeit
- CSV exportieren, Spalten prüfen, Mapping pflegen, wieder importieren.
- Bilder liegen nicht in der Datei – die lädt jemand von Hand nach.
- Page-Builder-Inhalte brechen, weil die Block-IDs im Zielsystem andere sind.
- Fehlt ein Attribut im Ziel, bricht der Import ab.
- Für eine einzige geänderte Landingpage denselben Aufwand wie für 5.000 Produkte.
- Niemand weiß hinterher genau, was übertragen wurde.
mit Smart Data Synchronizer
Bearbeiten, Data Sync, fertig
- Die Redaktion bleibt in der Maske, in der sie ohnehin gerade arbeitet.
- Bilder der Galerie und aus Page-Builder-Inhalten werden base64-kodiert mitgeliefert.
- Referenzierte CMS-Blöcke werden vorab übertragen und die ID's im Zielsystem neu verknüpft.
- Fehlende Attribute und Attributsets legt das Zielsystem auf Wunsch selbst an.
- Jeder Sync steht mit Status und Zeitstempel im Log.
+ IM BETRIEB GESEHEN
Ein Sync in zwei Minuten erklärt
Die Funktionalitäten im Überblick und an zwei Beispiel-Synchronisationen einfach erklärt.
+ WAS ÜBERTRAGEN WIRD
Vier Datentypen, jeder mit eigener Vorlage
Pro Typ definieren Sie eine Sync-Vorlage: welche Felder an das Zielsysteme, mit welchen Optionen übertragen werden sollen. Was Sie nicht auswählen, bleibt im Ziel unverändert.
product
Produkte
Alle Produktattribute stehen zur Auswahl. Die Zuordnung im Ziel läuft über die SKU. Die Galerie kann als base64 mitgeschickt werden.
category
Kategorien
Kategoriefelder inklusive der strukturellen Bezüge zur Elternkategorie. Der url_key geht immer mit.
cms_page
CMS-Seiten
Inklusive Page-Builder-Inhalt: Bilder werden eingebettet, absolute URLs zu host-unabhängigen Direktiven normalisiert.
cms_block
CMS-Blöcke
Zuordnung über den Identifier. Blöcke, die in einer Seite referenziert sind, synchronisieren automatisch vorweg.
Immer dabei, egal was Sie auswählen: Identitäts- und Strukturschlüssel (SKU), identifier, url_key, Eltern-Referenzen und Medien-Assets. Ohne die könnte das Zielsystem die Datentypen nicht sicher zuordnen.
+ WAS ÜBERTRAGEN WIRD
Einmal konfiguriert, danach ein Klick
Die folgenden Schritte 1 bis 3 werden nur einmalig durchgeführt. Schritt 4 macht die Redaktion danach jeden Tag.
SCHRITT 01 — EINMALIG
Zielsystem anlegen und Verbindung testen
Basis-URL eintragen, Authentifizierung wählen – wahlweise ein statischer Integration Access Token oder Admin-Zugangsdaten. Zugangsdaten liegen verschlüsselt vor und werden im Backend maskiert angezeigt.
Der Button Test Connection pingt das Ziel an und meldet sofort zurück, ob die Leitung steht – aus der Übersicht heraus oder direkt im Formular.
Es können mehrere Zielsysteme konfiguriert und für Daten-Synchronisationen genutzt werden.
Zielsystem konfigurieren: Name, Basis-URL, Auth-Typ, Timeout, aktiv ja/nein.
SCHRITT 02 — EINMALIG
Sync-Vorlage definieren
Eine Vorlage legt fest, was übertragen wird und wohin: Datentyp (Entity), die Felder und Attribute per Mehrfachauswahl, ein oder mehrere Zielsysteme sowie die Optionen für Medien und Page-Builder-Referenzen.
Werden keine Felder ausgewählt, greifen die Standardwerte. Für jeden Entitätstyp gibt es eine eigene Vorlage – die Feldliste filtert sich entsprechend.
Vorlage anlegen: Entitätstyp wählen, Felder picken, Ziele zuordnen.
SCHRITT 03 — EINMALIG
Globale Einstellungen
Timeout für die Verbindung, maximale Mediengröße für den base64-Transfer, Log-Level und die Frage, ob fehlende Attribute im Ziel automatisch angelegt werden sollen. Alles unter Stores › Configuration › CLEVER+ZOEGER › Smart Data Synchronizer.
Zentrale Einstellungen inklusive Log-Level für var/log/cleverzoeger_datasync.log.
SCHRITT 04 — TÄGLICH
Smart Data Synchronizer starten
Der Button "Data Sync" sitzt in der Toolbar jeder unterstützten Bearbeitungsmaske. Ein Klick öffnet ein Fenster mit den aktiven Vorlagen für diesen Entitätstyp. Vorlage wählen, Run Sync drücken – und im selben Fenster steht, was im Ziel passiert ist.
Kein Kontextwechsel, keine Datei, kein Warten auf die Technik.
Vorlage wählen, Sync starten. Das Ergebnis erscheint direkt im Dialog.
Der Button ist überall dort, wo Sie ihn brauchen
Produkt
Kategorie
CMS-Seite
CMS-Block
+ DER SCHWIERIGE FALL
Page Builder überlebt den Umzug
Eine Landingpage mit einem Bild und einem eingebundenen CMS-Block ist genau der Inhalt, an dem klassische Import-Werkzeuge scheitern. Hier ist, was beim Übertragen tatsächlich passiert.
- Bilder werden gelesen und eingebettet. Sowohl https://<QUELLSYSTEM>/media/…-Direktiven als auch absolute …/media/…-Quellen in <img>-Tags. Im Ziel landen sie unter demselben Medienpfad.
- Absolute URLs werden normalisiert zu host-unabhängigen Direktiven – die Seite funktioniert im Ziel auch unter anderer Domain.
- Referenzierte CMS-Blöcke gehen zuerst. Sie werden einmalig über ihren identifier angelegt.
- Die numerische block_id im Widget wird umgeschrieben auf die lokale ID im Zielsystem.
Schematische Darstellung. Die tatsächliche Ausgabe steht im Job-Log und in var/log/cleverzoeger_datasync.log.
Ehrlich bleiben: Übergroße Bilder werden vom Größen-Schutz übersprungen und im Log als Warnung vermerkt. Verschachtelte Block-in-Block-Referenzen werden in der aktuellen Version eine Ebene tief übertragen.
Vorher: die Seite im Editor des Quellsystem.
Nachher: Die Seite im Frontend des Zielsystems – aus einem zuvor leeren Ziel heraus angelegt.
+ FUNKTIONSUMFANG
Alles, was zwischen mehreren Instanzen gebraucht wird
Mehrere Zielsysteme
Eine Vorlage kann beliebig viele Ziele bedienen. Nur aktive Ziele bekommen Daten – zum Pausieren genügt ein Schalter.
Feldgenaue Auswahl
Per Mehrfachauswahl bestimmen, welche Attribute mitgehen. Preise im Ziel behalten, nur Texte aktualisieren? Kein Problem.
Attribute anlegen
Auf Wunsch erzeugt das Zielsystem fehlende Attribute, Attributoptionen und Attributsets selbst, statt den Vorgang abzubrechen.
Medien-Dateien
Die Produktgalerie wird direkt in der Payload mit synchronisiert. Kein separater FTP-Sync, kein nachträgliches Bilderschieben.
Fehlerfreier Import
Eindeutige Zuordnung über SKU und identifier. Wiederholte Läufe aktualisieren, sie duplizieren nicht.
Verbindungstest
Ein Klick, eine Antwort. Aus der Zielübersicht heraus oder direkt im Formular – bevor die erste echte Entität losgeschickt wird.
Logging
Jeder Lauf mit Entitätstyp, Quellentität, Status je Ziel und Zeitstempel. Nachvollziehbar auch Wochen später.
Verschlüsselt
Access Token und Admin-Passwörter werden verschlüsselt gespeichert und im Backend nur maskiert angezeigt.
Entwickler-TLS
Für lokale Ziele mit selbstsigniertem Zertifikat lässt sich die TLS-Prüfung gezielt abschalten. Extra für Dev-Systeme.
+ SICHERHEIT
Sauber abgesichert
- Die Empfängerseite stellt zwei REST-Endpunkte bereit: GET /rest/V1/cz-datasync/ping für den Gesundheitscheck und POST /rest/V1/cz-datasync/import für den eigentlichen Import.
- Beide verlangen einen Bearer Token und die ACL-Ressource CleverZoeger_DataSync::sync. Kein offener Endpunkt, keine Hintertür.
- Zugangsdaten liegen verschlüsselt in der Konfiguration und werden im Backend maskiert.
- Ein Größenlimit für Mediendaten verhindert, dass ein einzelnes Bild den Transfer sprengt.
- Die Extension lässt sich global deaktivieren, einzelne Ziele und Vorlagen separat.
+ TECHNISCHE DATEN
Auf einen Blick
| Modulname | CleverZoeger_DataSync |
|---|---|
| Kompatibilität | Magento 2.4.x |
| Installation | auf Quell- und Zielsystem |
| Entitätstypen | product · category · cms_page · cms_block |
| Transport | Magento WebAPI (REST), Bearer Token |
| Mediadaten | base64 in Payload, Größenlimit konfigurierbar |
| Backend-Pfad | CLEVER+ZOEGER › Smart Data Synchronizer |
| Logdatei | var/log/cleverzoeger_datasync.log |
| Quellcode | unverschlüsselt, 100% Open Source |
Das Smart Data Synchronizer Log zeigt jeden Synchronisations-Durchlauf – schreibgeschützt, mit Status je Zielsystem.
+ HÄUFIGE FRAGEN
Bevor Sie kaufen
Muss die Extension auf beiden Systemen installiert sein?
Ersetzt das den CSV-Import von Magento?
Was passiert, wenn die Entität im Zielsystem schon existiert?
Gehen Bilder mit?
Was ist mit Attributen, die es im Zielsystem noch nicht gibt?
Bleiben Page-Builder-Widgets funktionsfähig?
Wie ist die Verbindung abgesichert?
Kann ich einen Sync nachvollziehen?
Brauche ich Programmierkenntnisse?
Bekomme ich Support?
+ NÄCHSTER SCHRITT
Schluss mit doppelter Pflege
Sehen Sie sich die vollständige Dokumentation an oder sprechen Sie mit uns über Ihr Setup. Beratung kostet bei uns nichts.
| Modul Version | 1.3.0 |
|---|---|
| CE | 2.4.x |
| EE | 2.4.x |
| Sprachen | englisch, deutsch |
Release Notes - Smart Data Synchronizer
Version 1.3.0 (16.09.2026)
- IMPROVEMENT Language settings updated
Version 1.2.0 (09.09.2026)
- CHANGE MARKETPLACE_PROJECT_NAME removed from the CI configuration
- IMPROVEMENT Documentation: the supported PHP versions are now listed in the module header
Version 1.1.0 (12.08.2026)
- FEATURE Sync traffic is restricted to licensed domains. A central
Service\License\LicenseGuardfetches the customer domains registered for the Data Sync licence via the newCleverZoeger_Base::getLicensedDomains(licence server endpoint/api/license/domains) and enforces them at three independent, fail-closed points: (1) when saving a target (the host of the base URL must be registered), (2) at sync time, immediately before sending to a target, (3) on the target side during import - an unlicensed installation rejects incoming syncs. Removing a single check is therefore not enough: an unlicensed target accepts nothing, an unlicensed remote is not served. An empty domain list (missing or invalid licence) and transport errors lead to rejection. The protection is always active and not configurable. RequiresCleverZoeger_Base>= 2.1.7. - BUGFIX More robust image import: images are saved one by one (a rejected image no longer aborts the whole media import). If Magento rejects an image as "executable code", it is re-rendered through the image adapter and uploaded again with several quality levels (same approach as the shop upload).
- BUGFIX Changed images are updated now: the deduplication compares the image content (SHA-256) instead of only the file name. If the content is identical the image is skipped; with the same name but changed content the old gallery image is removed and replaced by the new one (before it stayed unchanged). After changes the resized image cache of the product is regenerated so the storefront does not keep serving the old cached version.
Version 1.0.0 (17.07.2026)
- FEATURE Initial version: data synchronisation between two Magento 2 systems.
- FEATURE Sync targets (encrypted credentials, token or admin authentication, optional TLS verify toggle) and sync templates can be managed in the backend.
- FEATURE WebAPI endpoints (
/V1/cz-datasync/ping|import, ACL protected) with payload validation and strategy dispatch per entity type. - FEATURE Product sync: sync button and modal on the product, attributes per store (select/multiselect transferred portably - see the BUGFIX below for details), creation of attributes and options on the target, websites, category remapping, media as base64 (with deduplication), idempotent SKU upsert.
- FEATURE Page Builder content: media transfer and CMS block references
(
block_idis remapped to the target ID, the block is transferred first). - FEATURE Category, CMS page and CMS block sync (idempotent via identity).
- FEATURE Job and log grid (with direction
outbound/inboundand a source system column), identity mapping, dedicated log filecleverzoeger_datasync.log. - FEATURE Logging on the receiving side: every incoming synchronisation is recorded on the target system as an inbound job (including source system, entity type, source identity and result item) in the job and log grid - rejected requests included (schema, payload or importer errors). The logging is encapsulated and never aborts an import.
- FEATURE Template field selection: the former textarea was replaced by a searchable
multiselect picker that offers all available fields and attributes filtered by
entity_type(product: all EAV attributes; category/CMS: the supported fields). The CMS and category exporters respect the selection as well now (mandatory and identity keys are always kept). - FEATURE Sync modal: the selection in the template dropdown now directly shows the fields configured in the template (or "All fields" for an empty field list), so it is visible before the sync what will be transferred. Label/dropdown, field list and result are arranged as a table. After the sync the "Run Sync" button turns into a black "Close" button that closes the modal.
- FEATURE The job and log grid now records the admin user who triggered the sync: every sync job gets the user name of the admin who started it (new column "User"). Inbound jobs (WebAPI) stay without a user.
- FEATURE Configuration changes on templates and targets are written into the same
log grid as audit entries (direction "Configuration change") - creating, changing and
deleting (including mass delete), each with the admin user and a field diff in the new
column "Detail" (for example
name: 'A' -> 'B'; is_active: no -> yes). Target credentials (access token, remote admin user and password) are never logged in clear text: changes only appear asset/changed/cleared. - BUGFIX Admin grids (targets/templates/jobs): a missing
storageConfig/indexFieldmade the client data storage key all rows underentity_id(=undefined), so several rows were displayed as the same (last) row.indexFieldis now set to the respective primary field andrequestFieldNametoid(core default). - BUGFIX Product sync of select and multiselect attributes (for example
visibility) broke between systems with different languages. Until now the translated option label was always transferred and matched by text on the target side - an en_US sender sentvisibilityas"Catalog, Search", while a de_DE target only knows"Katalog, Suche"-> no match ->visibilitywas set tonull. The value is now transferred portably depending on the option source: attributes with a code-defined source model (visibility,status, ...) have stable option IDs across systems and are transferred and resolved by ID (locale independent); attributes with database options (table source, usually user-defined) have install-specific IDs and are still mapped by admin label (options are created when needed). For source model attributes the receiver additionally still accepts the label as a fallback for older payloads. Note: the complete cross-locale fix only takes effect once both sides are updated.