Umstieg von DataPress
Wie sich die Konzepte von AlexaCRM DataPress (WordPress.org-Slug integration-cds) und seines älteren Vorgängers, des Plugins Dynamics 365 Integration (integration-dynamics), auf WBS Connect for Dataverse übertragen lassen, dazu der Ablauf einer realen Migration und eine ehrliche Liste dessen, was noch keine Entsprechung hat.
Zuordnung der Konzepte
| DataPress / älteres Plugin | WBS Connect | Hinweise |
|---|---|---|
| Twig-View oder Template, das Datensätze auflistet | Collection | Wird auf dem Tab "Collections" konfiguriert: Tabelle, Spalten, Statusfilter, Suche, Filter, Sortierung, Paging. Keine Template-Sprache; das Markup liegt in PHP-Templates, die Sie überschreiben können. |
| Eigenes Formular (Twig oder Formular-Builder) | Typisiertes Formular | Geordnete Feldliste mit Typen, auf dem Server validiert; Create- oder Update-Modus; Turnstile; Erfolgsmeldung und Weiterleitung. |
| Tabellenbindung einer Seite an einen Datensatz | Detailseite per Slug | Dieselbe Seite rendert das Grid und mit ?dvc=<slug> einen einzelnen Datensatz. Eine Slug-Spalte sorgt für lesbare URLs; GUIDs funktionieren weiterhin. |
| Benutzerbindung (WordPress-Benutzer an Kontakt) | Business-Tarif | Spezifiziert mit den Bindungsmodi E-Mail, Spalte und benutzerdefiniert; in Entwicklung, siehe Pro und Business. |
| Twig-Zugriff auf Image- und File-Spalten | "Image column" und File-Spalten | Werden über eine REST-Route auf Ihrer Website ausgeliefert, mit Prüfung gegen den Statusfilter; keine direkten Dataverse-URLs auf der Seite. |
| Cache-Panel mit Leeren nach Typ | Cache-Lebensdauer je Collection | Dazu ein seitenweiter Standardwert und der Button "Flush cache". |
| Verwaltung von Webhooks | Tab "Webhooks" | form.created, health.failure, health.recovery; signiert mit einem HMAC; Test-Link. |
| Monaco-Twig-Block im Block-Editor | Drei Blöcke mit Dropdowns | Die Blöcke Collection, Record und Form wählen konfigurierte Elemente aus; kein Code im Editor. |
| Integrationen für Formular-Builder | Pro: Contact Form 7 und Gravity Forms; kostenlos: die WBS-Forms-Bridge | Je Formular zugeordnet, typisiert wie die eingebauten Formulare. |
| Registrierungs- und Aktivierungsserver (Premium) | Offline-Lizenztoken | Kein Phone-home; der Token wird mit einem eingebetteten Schlüssel geprüft. |
| In Dataverse importierte DataPress-Lösung | Nichts zu importieren | Anwendungsbenutzer und Rolle sind die einzige Einrichtung auf Dataverse-Seite. |
Alte [msdyncrm_twig]-Shortcodes | [wbsdvc_collection], [wbsdvc_record], [wbsdvc_form] | Oder die passenden Blöcke. |
Schritte der Migration
- Bestandsaufnahme. Listen Sie jede Seite mit einem DataPress- oder Legacy-Shortcode auf und notieren Sie Tabelle, Spalten, Filter und ob die Seite auflistet, einen einzelnen Datensatz zeigt oder schreibt.
- Identität. Legen Sie für WBS Connect eine eigene App-Registrierung und einen eigenen Anwendungsbenutzer mit einer Rolle nach dem Prinzip der minimalen Rechte an. Verwenden Sie die DataPress-Zugangsdaten nicht weiter; eine getrennte Identität macht den Wechsel umkehrbar und hält den Audit-Trail sauber.
- Zuerst die Collections. Bauen Sie jede Auflistung als Collection nach und prüfen Sie das Grid auf einer Entwurfsseite. Ergänzen Sie Slug-Spalte, Suche, Filter und Sortierung und vergleichen Sie anschließend die Anzahl der Datensätze mit der alten View.
- Formulare. Bauen Sie jedes Formular als typisiertes Formular nach oder behalten Sie einen Formular-Builder und ordnen Sie ihn zu (Pro: CF7 und Gravity Forms; kostenlos: die WBS-Forms-Bridge). Testen Sie eine Einsendung je Formular und prüfen Sie den Datensatz in Dataverse, einschließlich Auswahlfeldern und Lookups.
- Seiten umstellen. Ersetzen Sie die alten Shortcodes durch die neuen (oder durch Blöcke) und behalten Sie die Seiten-Slugs bei, damit Links und Rankings erhalten bleiben. Richten Sie 301-Weiterleitungen für Detail-URLs ein, deren Form sich ändert.
- Das alte Plugin abschalten. Deaktivieren Sie es, sobald nichts mehr darauf verweist, und tragen Sie die Alert-E-Mail ein, damit die neue Verbindung meldet, wenn etwas ausfällt.
Praxisbeispiel: kraftfahrer-jobs.com
Leopold Michel rekrutiert Berufskraftfahrer über kraftfahrer-jobs.com. Die Bewerbungsformulare auf acht Landingpages in Deutsch, Englisch und Kroatisch waren Formulare des älteren Plugins Dynamics 365 Integration und schrieben in eine eigene Bewerbungstabelle in Dynamics 365. Eines Tages funktionierten sie nicht mehr. Die Ursache, Wochen später gefunden: Das Client Secret der App-Registrierung des alten Plugins war abgelaufen, und nichts hatte darauf hingewiesen.
Die Migration in der Reihenfolge, in der sie stattfand:
- Eine neue App-Registrierung und ein neuer Anwendungsbenutzer mit einer eigenen Rolle, die Create und Append auf der Bewerbungstabelle sowie Read und Append To auf der Stellentabelle erlaubt, auf die die Bewerbungen verweisen. Eine Spalte war feldgesichert; ein Feldsicherheitsprofil gab dem Anwendungsbenutzer Zugriff darauf. Die Zugangsdaten kamen als Konstanten in die
wp-config.php. - Ein WBS-Forms-Formular je Sprache, nach dem Vorbild der laufenden Formulare eins zu eins nachgebaut (die alten Formulare hatten nie Uploads gespeichert, also wurden auch keine ergänzt). Die Meldungen jedes Formulars lokalisiert.
- Ein Bridge-Mapping je Formular-Slug, deklariert in einem kleinen Must-use-Plugin über den Filter
wbs_dataverse_connect_bridge_maps: Strings für Namen und Adresszeilen, E-Mail, ein Datum für den Geburtstag, Auswahlfelder für Anrede und Empfehlungsquelle mit aus den Tabellenmetadaten erzeugten Zuordnungen von Beschriftung zu Wert (die deutschen und englischen Formulare nutzen unterschiedliche Auswahlspalten), Mehrfachauswahl für Führerscheinklassen und LKW-Erfahrung, ein Ja/Nein für die Datenschutzeinwilligung, ein Lookup für die über den Namen aufgelöste Stelle und zwei feste Standardwerte. - Der alte Shortcode jeder Landingpage ersetzt durch
[wbs-form slug="job-application"], der bisherige Inhalt in einem Backup-Feld aufbewahrt. Landingpages, die eine bestimmte Stelle bewerben, wählen sie über ein Shortcode-Attribut vor. - Drei echte Einsendungen, eine je Sprache, in Dataverse Spalte für Spalte geprüft und anschließend gelöscht. Das alte Plugin deaktiviert.
Was sich für den Kunden geändert hat: Bewerbungen landen als typisierte Datensätze in Dataverse, ein Dataverse-Workflow legt den Kontakt an und benachrichtigt das Recruiting, und die Verbindung wird zweimal täglich geprüft. Ein abgelaufenes Secret erzeugt jetzt innerhalb von Stunden eine E-Mail statt Wochen später einen Supportfall. Die Formulare nehmen weiterhin Bewerbungen an, auch wenn Dataverse kurzzeitig nicht erreichbar ist; der Fehler wird protokolliert und gemeldet, und die eigene E-Mail des Formulars geht trotzdem raus.
Was noch keine Entsprechung hat
- FetchXML. Collections erzeugen OData-Abfragen aus der Konfiguration; eine FetchXML-Abfrage lässt sich nicht einfügen. Filter beschränken sich auf Suche, typisierte Spaltenfilter und einen Statusfilter.
- Gespeicherte Ansichten. Spalten und Filter werden je Collection konfiguriert und nicht aus Dataverse-Ansichten gelesen.
- Ninja Forms. Unterstützte Builder sind Contact Form 7, Gravity Forms und WBS Forms.
- Twig-Templates. Das Markup wird stattdessen über PHP-Templates im Theme angepasst.
- Benutzerbindung, Ansichten eigener Datensätze und bedingter Zugriff. Business-Tarif, in Entwicklung.
- Elementor-Widget. Verwenden Sie das Shortcode-Widget.
- Rendering modellgesteuerter Formulare mit Lookup-Dialogen. Lookups werden als Auswahlliste mit bis zu 200 Namen gerendert.
Wenn einer dieser Punkte Ihre Migration blockiert, sprechen Sie uns an; für die meisten Lücken gibt es eine Antwort in der Konfiguration, und die Roadmap wird von realen Migrationen bestimmt.