Die Datenmodellbewertung für WordPress als mögliche Zielplattform beginnt damit, die Quellstrukturen und ihre Beziehungen in der Zielrepräsentation einzuordnen. WordPress speichert einen großen Teil seiner sichtbaren Inhalte über wenige wiederverwendbare Kernstrukturen, doch dieselben Strukturen können sehr unterschiedliche Anwendungen tragen. Ein Datensatz in der Posts-Tabelle kann einen Blog Post, eine CMS Page, einen Medienanhang, einen Navigationseintrag, eine Revision oder einen benutzerdefinierten Beitragstyp darstellen. Eine Taxonomie kann redaktionelle Inhalte, Verzeichniseinträge, Kurse, Veranstaltungen oder Products klassifizieren. Metadaten können ein unkritischer Anzeigewert sein oder genau das Feld, das einen Datensatz mit einem Plugin, Template, einer Berechtigungsregel oder einem externen System verbindet.
Die entscheidende Frage bei der Migration lautet deshalb nicht, ob ein Wert in WordPress übernommen werden kann. Entscheidend ist, welchem WordPress-Objekt er gehören soll und welche Beziehungen den Datensatz verwaltbar machen. Eine „Seite“ im Quellsystem kann zu einer CMS Page, einem benutzerdefinierten Beitragstyp, einem Taxonomiearchiv, einem Plugin-Datensatz oder mehreren miteinander verknüpften Objekten werden. Ein „Kunde“ im Quellsystem kann als WordPress-Benutzer, als Customer eines Commerce-Plugins, als Mitgliedsprofil, als CRM-Kontakt oder auch ganz ohne WordPress-Konto abgebildet werden.
WordPress Core bietet wiederverwendbare Datensatztypen, kein universelles Geschäftsschema
WordPress Core trennt Inhalte, Klassifikation, Medien, Identität, Einstellungen, Kommentare, Routing und Darstellung. Plugins können neue Datensatztypen registrieren oder für spezialisierte Anwendungen eigene Tabellen anlegen. Themes und Block-Templates bestimmen die Ausgabe, sind aber nicht automatisch Eigentümer der zugrunde liegenden Geschäftsdaten.
| WordPress-Ebene | Kernbedeutung | Konsequenz für die Übertragung |
|---|---|---|
| Posts-Tabelle | Speichert mehrere Beitragstypen, darunter Posts, Pages, Anhänge, Revisionen, Menüeinträge und registrierte benutzerdefinierte Beitragstypen | Beitragstyp und Beziehungen sind wichtiger als der gemeinsame Speicherort in derselben Tabelle. |
| Taxonomien und Begriffe | Klassifizieren Datensätze über hierarchische oder flache Vokabulare | Eine Category aus dem Quellsystem lässt sich nicht sicher zuordnen, solange unklar ist, was sie klassifiziert und wie das Ziel sie verwendet. |
| Metadaten | Ergänzen Posts, Benutzer, Begriffe und Kommentare um Schlüssel-Wert-Daten | Dasselbe Speichermuster kann Anzeigefelder, Beziehungen, Berechtigungen, Plugin-Zustand oder externe Kennungen enthalten. |
| Benutzer, Rollen und Berechtigungen | Repräsentieren Identität und Autorisierung | Ein WordPress-Benutzer ist nicht automatisch Customer, Mitglied, Lernender, Spender, Anbieter oder Mitarbeiterprofil. |
| Optionen und Einstellungen | Speichern Website- oder Plugin-Konfiguration | Konfigurationsdatensätze dürfen nicht mit übertragbaren Inhaltsobjekten verwechselt werden. |
| Kommentare | Speichern Interaktionen, die Posts oder anderen unterstützten Objekten zugeordnet sind | Blog-Kommentare, Product-Bewertungen, Testimonials, Fragen und Diskussionen können unterschiedliche Ziel-Eigentümer benötigen. |
| Plugins und benutzerdefinierte Tabellen | Ergänzen domänenspezifische Datensätze und Verhalten | Commerce, Mitgliedschaften, Formulare, Veranstaltungen, Verzeichnisse, Lernsysteme und Buchungen müssen nach ihrem jeweiligen Eigentümer interpretiert werden. |
WordPress kann damit viele Datenarten aus einem Quellsystem aufnehmen. Das Zielmodell muss jedoch den vorgesehenen Beitragstyp, die Taxonomie, den Eigentümer der Metadaten, den Plugin-Eigentümer und die Route benennen. Fehlen diese Entscheidungen, können migrierte Inhalte zwar in der Datenbank vorhanden sein, aber im Editor, in Archiven, Templates, der Suche, in Berechtigungen oder im Anwendungsablauf fehlen.
Blog Posts, CMS Pages und benutzerdefinierte Beitragstypen tragen unterschiedliche Inhaltsbedeutung
WordPress Posts und Pages teilen sich Kernspeicher, erfüllen aber unterschiedliche redaktionelle Rollen. Blog Posts gehören typischerweise zu einem datumsbezogenen Veröffentlichungsstrom und können Categories, Tags, Autoren, Archive, Feeds und chronologische Navigation nutzen. CMS Pages repräsentieren meist relativ stabile Website-Inhalte und können Eltern-Kind-Hierarchien bilden. Benutzerdefinierte Beitragstypen modellieren strukturierte Domänen außerhalb gewöhnlicher redaktioneller Inhalte.
Eine Quellplattform kann jeden öffentlichen Datensatz als Seite bezeichnen, obwohl die Datensätze Veranstaltungen, Standorte, Fallstudien, Ressourcen, Mitarbeiter, Kurse, Immobilien oder Verzeichniseinträge darstellen. Werden sie alle als CMS Pages abgebildet, geht die Typgrenze verloren, die spezialisierte Felder, Archive, Filter, Templates und Verwaltungsoberflächen ermöglicht.
| Quelldatensatz | Mögliche WordPress-Zielstruktur | Beziehung, die die Wahl bestimmt |
|---|---|---|
| Nachrichtenartikel oder redaktioneller Beitrag | Blog Post | Veröffentlichungsdatum, Autor, Categories, Tags, Archive, Feeds und verwandte Inhalte |
| Über-uns-, Kontakt-, Richtlinien- oder Serviceseite | CMS Page | Stabile Hierarchie, Menüposition, Seitentemplate und Route |
| Veranstaltung | Benutzerdefinierter Beitragstyp für Veranstaltungen oder Plugin-Datensatz | Datum, Veranstaltungsort, Organisator, Wiederholung, Ticketing und Kalenderbeziehungen |
| Immobilien- oder Verzeichniseintrag | Benutzerdefinierter Listing-Beitragstyp oder Datensatz eines Verzeichnis-Plugins | Standort, Attribute, Taxonomiefilter, Eigentümer, Status und Suchbeziehungen |
| Kurs oder Lektion | LMS-eigener Beitragstyp und zugehörige Tabellen | Kurshierarchie, Einschreibung, Fortschritt, Tests, Zertifikate und Zugriffsregeln |
| Product | Product-Modell eines Commerce-Plugins | Product-Typ, Variante, Preis, Bestand, Tax, Versand sowie Customer- und Order-Beziehungen |
| Wiederverwendbarer Designabschnitt | Block-Pattern, Template-Part, Builder-Datensatz oder eingebettete Blocks | Wiederverwendung der Darstellung statt eigenständiger redaktioneller Identität |
Benutzerdefinierte Beitragstypen können zusammen mit anderen Beitragstypen gespeichert werden, doch gemeinsamer Speicher macht sie nicht austauschbar. Registrierte Berechtigungen, unterstützte Editor-Funktionen, Taxonomien, Metadaten, REST-Bereitstellung, Archivverhalten und Templates bestimmen, wie Redakteure und Anwendungen sie verwenden.
Taxonomien, Begriffe, Menüs und Archive hängen zusammen, sind aber nicht austauschbar
WordPress-Taxonomien klassifizieren Objekte. Categories sind standardmäßig hierarchisch, Tags flach. Plugins oder Themes können benutzerdefinierte Taxonomien für Themen, Marken, Standorte, Branchen, Ressourcentypen, Kursstufen oder Product-Attribute registrieren. Begriffe sind die einzelnen Werte innerhalb dieser Taxonomien.
Menüs und Navigation sind davon getrennt. Ein Menüeintrag kann auf eine CMS Page, einen Blog Post, ein Taxonomiearchiv, das Archiv eines benutzerdefinierten Beitragstyps, eine externe URL oder eine andere Route verweisen. Die Existenz eines Taxonomiebegriffs garantiert keinen entsprechenden Menüeintrag, und die Menühierarchie bildet die Inhaltshierarchie nicht zwingend ab.
| Quellstruktur | WordPress-Eigentümer | Problem bei der Übertragung |
|---|---|---|
| Redaktioneller Bereich | Category oder benutzerdefinierte Taxonomie | Beziehung zu den richtigen Beitragstypen und vorgesehenes Archivverhalten erhalten. |
| Schlagwort | Tag oder flache benutzerdefinierte Taxonomie | Keine tiefe Hierarchie erzeugen, wenn der Quellwert nur eine Kennzeichnung ist. |
| Marke, Region oder Ressourcentyp | Benutzerdefinierte Taxonomie, Commerce-Taxonomie oder Plugin-Klassifikation | Vokabulare getrennt halten, wenn sie unterschiedliche Filter oder Templates steuern. |
| Hauptnavigation | Navigations-/Menüdatensätze | Menüreihenfolge und Verschachtelung sind Darstellungsbeziehungen, keine Taxonomiezugehörigkeit. |
| Landingpage für eine Klassifikation | Taxonomiearchiv, CMS Page oder Plugin-Ansicht | Festlegen, welches Objekt Route, Inhaltskörper und gefilterte Ergebnismenge besitzt. |
| Nur intern verwendete Source Category | Metadaten oder externe Klassifikation | Einen operativen Code nicht standardmäßig als öffentliches WordPress-Archiv veröffentlichen. |
Auch Beziehungen zwischen Begriffen brauchen einen klaren Geltungsbereich. Ein Begriff für Blog Posts kann denselben Namen tragen wie ein Begriff für Products, aber beide können unterschiedlichen Taxonomien angehören und andere Anwendungen bedienen. Werden sie nur wegen identischer Namen zusammengeführt, können unabhängige Archive und Filter unbeabsichtigt verschmelzen.
Metadaten und benutzerdefinierte Felder können Anzeigedaten, Beziehungen oder Anwendungszustand tragen
Die WordPress-Metadaten-APIs erlauben zusätzliche Werte für Posts, Benutzer, Begriffe und Kommentare. Plugins und Themes verwenden Metadaten häufig für Untertitel, SEO-Werte, externe IDs, Template-Auswahl, Dateiverweise, Standorte, Termine, Preise, Sichtbarkeitseinstellungen, Beziehungs-IDs und serialisierten Anwendungszustand.
Das Speichermuster allein verrät nicht die Bedeutung. Ein Meta-Key kann einfachen Text, einen Verweis auf einen anderen Post, eine Liste von Term-IDs, eine Attachment-ID, ein strukturiertes Array oder einen Plugin-spezifischen Zustandsautomaten enthalten. Ein Feld, das im Quellsystem korrekt angezeigt wird, kann im Ziel unbrauchbar werden, wenn nur der sichtbare Wert kopiert wird, aber Felddefinition oder referenziertes Objekt verloren gehen.
| Metadatenmuster | Mögliche Bedeutung | Anforderung im Ziel |
|---|---|---|
| Klartext oder Zahl | Untertitel, Spezifikation, Datum, Bewertung, Code oder redaktionelle Kennzeichnung | Wert dem richtigen Objekt zuordnen und über die vorgesehene Bearbeitungsoberfläche verfügbar machen. |
| Post- oder Attachment-ID | Beziehung zu einem anderen Datensatz oder Medienelement | Verweis auf den Zieldatensatz übersetzen, statt die alte numerische ID zu kopieren. |
| Term-ID | Klassifikationsbeziehung | Wert mit der Zieltaxonomie und dem Zielbegriff neu verbinden. |
| User-ID | Autor, Eigentümer, Dozent, Anbieter, Prüfer oder Bearbeiter | Geschäftliche Rolle erhalten, nicht nur die Benutzer-ID aus dem Quellsystem. |
| Serialisiertes Array oder JSON | Wiederholfelder, Layouts, Einstellungen, Koordinaten oder Plugin-Zustand | Schema des besitzenden Plugins verstehen, bevor über die Übertragbarkeit entschieden wird. |
| Externe Kennung | CRM-, ERP-, PIM-, DAM- oder Altsystem-Schlüssel | Auf dem Zielobjekt stabil halten, das dasselbe Geschäftsobjekt repräsentiert. |
Felddefinitionen können genauso wichtig sein wie Feldwerte. Systeme, die benutzerdefinierte Felder registrieren, können Feldtyp, erlaubte Werte, Anzeigebezeichnungen, Eingaberegeln, Wiederholfelder, Gruppen, bedingte Logik und Beziehungen definieren. Werden nur Werte ohne diese Definitionen kopiert, können Administratoren Daten erhalten, die weder Editor noch Template sinnvoll verwenden können.
Blocks, Builder, Templates und Theme-Daten gehören zur Darstellungsebene
WordPress-Inhalte können als HTML des klassischen Editors, Block-Markup, Shortcodes, Builder-spezifische Strukturen, wiederverwendbare Blocks, Patterns, Template-Parts oder Theme-Einstellungen dargestellt werden. Diese Ebenen können auf dieselbe zugrunde liegende CMS Page oder denselben benutzerdefinierten Beitragstyp verweisen und die Darstellung trotzdem unterschiedlich kodieren.
Ein Page Builder im Quellsystem kann Layoutdaten in post_content, Metadaten, benutzerdefinierten Beitragstypen, Optionen oder benutzerdefinierten Tabellen speichern. Eine blockbasierte Website kann Inhaltsblocks im Datensatz speichern, während Site Editor und Theme die umgebenden Templates liefern. Das Zielmodell muss Inhaltseigentum und Darstellungseigentum getrennt halten.
| Darstellungsstruktur | Was sie besitzt | Was getrennt bleibt |
|---|---|---|
| Core Blocks im Beitragsinhalt | Strukturierte Inhalte und Blockattribute eines Datensatzes | Websiteweite Templates, Navigation, Plugin-Daten und externe Datensätze |
| Shortcodes | Platzhalteranweisungen, die von Plugin oder Theme interpretiert werden | Tatsächliche Plugin-Konfiguration oder die vom Shortcode abgefragten Daten |
| Page-Builder-Layout | Builder-spezifische Abschnitte, Widgets, Styles und Referenzen | Geschäftsdatensätze, die innerhalb des Layouts angezeigt werden |
| Template oder Template-Part | Websiteweite Darstellungsstruktur | CMS Page-, Blog Post-, Product-, Customer- oder Order-Daten |
| Theme-Option | Globale Design- oder Anzeigeeinstellung | Übertragbare redaktionelle Inhalte und Anwendungsdatensätze |
| Wiederverwendbarer Block oder Pattern | Wiederverwendbarer Darstellungsinhalt | Jede Instanz oder jedes Geschäftsobjekt, das über das Pattern angezeigt wird |
Das Ziel muss das interne Speicherformat eines Quell-Builders nicht erhalten, wenn im Ziel ein anderes Rendering-System verwendet wird. Erhalten werden müssen jedoch Inhalte, Medien, Links, wiederverwendbare Beziehungen und Datensatz-Eigentum, die die neue Implementierung benötigt.
Medienanhänge sind Datensätze mit Dateien, Metadaten und Elternbeziehungen
WordPress-Medien sind nicht nur ein Verzeichnis kopierter Dateien. Medienelemente können Attachment-Post-Datensätze mit Titeln, Bildunterschriften, Beschreibungen, Alt-Text, MIME-Typen, Dateimetadaten, Bildgrößen, Autor, Datum und Elternbeziehungen sein. Inhaltskörper, Featured-Image-Metadaten, Galerien, Blocks, Plugin-Felder und externe Systeme können auf diese Anhänge verweisen.
| Mediensituation im Quellsystem | WordPress-Darstellung | Konsequenz für Beziehungen |
|---|---|---|
| Beitragsbild | Attachment plus Featured-Image-Beziehung zu einem Inhaltsdatensatz | Sowohl Datei als auch Referenz müssen übersetzt werden. |
| In Inhalt eingebettetes Bild | Attachment oder externe Datei plus URL im Inhalt | Zielinhalt muss auf den richtigen Dateispeicherort verweisen. |
| Galerie | Mehrere Attachments plus Block-, Shortcode-, Builder- oder Plugin-Struktur | Reine Dateiübertragung erhält Reihenfolge, Bildunterschriften oder Galerieverhalten nicht. |
| Herunterladbares Dokument | Medienanhang, Datei-URL oder Plugin-eigener Download | Zugriffsregeln, Linkziele und Ersatzpfade bleiben Teil des Modells. |
| Product- oder Listing-Bild | Attachment mit Beziehung über Commerce- oder Verzeichnis-Plugin | Plugin-Beziehung unterscheidet sich von gewöhnlichen Medien einer CMS Page. |
| Extern gehostetes Asset | Remote-URL oder DAM-Referenz | Das Ziel muss den externen Eigentümer beibehalten, statt künstlich eine lokale Attachment-Beziehung zu erzeugen. |
Attachment-Parent-IDs bilden Eigentum nicht immer vollständig ab. Dasselbe Bild kann in mehreren Datensätzen vorkommen, und neuere Editor-Abläufe setzen nicht zwingend einen aussagekräftigen Parent. Das Ziel sollte Beziehungen aus tatsächlichen Referenzen, Featured-Image-Feldern, Galerien, Plugin-Datensätzen und Inhaltsmarkup ableiten und sich nicht ausschließlich auf die Parent-Spalte verlassen.
Benutzer, Rollen, Berechtigungen und Profile repräsentieren unterschiedliche Kontobedeutungen
WordPress-Benutzer liefern die Login-Identität, Rollen und Capabilities bestimmen erlaubte Aktionen. Benutzer-Metadaten ergänzen Profilwerte und Plugin-spezifischen Zustand. Plugins können Mitgliedschaften, Kurse, Communities, Commerce-Konten, Anbieterprofile, Mitarbeiterverzeichnisse, Abonnements oder Beziehungen zu geschützten Inhalten hinzufügen.
| Identität im Quellsystem | Mögliche WordPress-Darstellung | Eigentumsabgrenzung |
|---|---|---|
| Autor oder Redakteur | WordPress-Benutzer mit Autorenschaft und redaktionellen Berechtigungen | Beitragseigentum und Revisionshistorie können unabhängig vom Login-Status wichtig sein. |
| Website-Administrator | Benutzer mit administrativen Berechtigungen | Administrative Autorität ist nicht gleichbedeutend mit Customer- oder Mitgliedsstatus. |
| Newsletter-Abonnent | Externer Marketingkontakt, Plugin-Datensatz oder eingeschränkter WordPress-Benutzer | Marketingeinwilligung und Listenzugehörigkeit dürfen nicht aus einem Login-Konto abgeleitet werden. |
| Mitglied | WordPress-Benutzer plus Profil, Plan, Zugriffs- und Statusdatensätze eines Membership-Plugins | Der Benutzerdatensatz allein reproduziert das Mitgliedschaftsverhalten nicht. |
| Lernender | WordPress-Benutzer plus LMS-Einschreibung, Fortschritt, Tests und Zertifikate | Lernhistorie gehört zur LMS-Domäne. |
| Customer | Customer eines Commerce-Plugins, WordPress-Benutzer, Gastidentität oder externer CRM-Kontakt | Commerce-Eigentum muss ausdrücklich benannt werden. |
| Anbieter oder Marketplace-Verkäufer | Benutzer plus Plugin-eigene Anbieter- und Auszahlungsdatensätze | Rollenzugehörigkeit allein repräsentiert nicht das vollständige Geschäftskonto. |
Passwort-Hashes aus dem Quellsystem, Authentifizierungsanbieter, Mehrfaktor-Einstellungen und Single-Sign-on-Identitäten sind möglicherweise nicht als gewöhnliche Benutzerfelder übertragbar. Das Konto kann seine geschäftliche Identität behalten, auch wenn die Authentifizierungsbeziehung im Ziel anders dargestellt werden muss.
Kommentare, Revisionen und historische Datensätze benötigen eigenen Kontext
Kommentare können Blog-Diskussionen, Product-Bewertungen, Testimonials, Fragen, Supportnachrichten oder Plugin-Interaktionen darstellen. Revisionen sind frühere Versionen eines Inhalts, keine eigenständigen öffentlichen Datensätze. Autosaves, Papierkorbstatus, geplante Posts und private Posts tragen ebenfalls Lebenszyklusbedeutung.
| Historischer Datensatz | WordPress-Bedeutung | Grenze bei der Übertragung |
|---|---|---|
| Blog-Kommentar | Interaktion an einem Blog Post oder einer CMS Page | Autor, Datum, Status, übergeordnete Antwort und Beziehung zum besitzenden Inhalt erhalten. |
| Product-Bewertung | Kommentarähnlicher Datensatz eines Commerce-Plugins | Bewertung, Verifizierter-Käufer-Status, Product-Referenz und Moderationsbedeutung unterscheiden sich von gewöhnlichen Kommentaren. |
| Verschachtelte Diskussion | Kommentarhierarchie oder Datensatz eines Community-Plugins | Eltern-Kind-Antworten und Mitgliedschaftskontext können wesentlich sein. |
| Inhaltsrevision | Historische Version eines Posts | Revisionen nicht als doppelte öffentliche CMS Pages oder Blog Posts darstellen. |
| Entwurf, geplant, privat oder im Papierkorb | Lebenszykluszustand eines Inhaltsobjekts | Veröffentlichungsstatus von Menüsichtbarkeit und Zugriffsberechtigungen getrennt halten. |
Historische Datensätze können bewusst ausgeschlossen werden, wenn sie keinen fortbestehenden Geschäftswert haben. Sie dürfen jedoch nicht stillschweigend mit aktuellen Inhalten verwechselt werden. Das Zielmodell sollte klarstellen, ob es den aktuellen Datensatz, seine redaktionelle Historie oder beides repräsentiert.
Plugins und benutzerdefinierte Tabellen definieren anwendungsspezifisches Eigentum
WordPress-Plugins können benutzerdefinierte Beitragstypen, Taxonomien, Metadaten, Rollen, REST-Endpunkte, Einstellungen und geplante Ereignisse registrieren. Sie können außerdem eigene Datenbanktabellen anlegen, wenn die Domäne Strukturen benötigt, die nicht in die Kernmodelle für Posts und Metadaten passen. Formulare, Buchungen, Mitgliedschaften, Lernsysteme, Veranstaltungen, Verzeichnisse, Spenden, Redirects, Analysen, Automatisierung und Commerce ergänzen häufig eigene Datensätze.
| Plugin-eigener Bereich | Mögliche Datensätze | Anforderung bei der Übertragung |
|---|---|---|
| Formulare | Formulardefinitionen, Felder, Übermittlungen, Benachrichtigungen und externe Integrationen | Wiederverwendbare Formularstruktur von historischen Übermittlungsdaten und Zustellabläufen trennen. |
| Mitgliedschaften | Pläne, Abonnements, Zugriffsregeln, Benutzerbeziehungen und geschützte Inhalte | Eigentum an Identität, Berechtigung, Zahlung und Inhaltszugriff getrennt halten. |
| Lernsysteme | Kurse, Lektionen, Einschreibungen, Fortschritt, Tests, Versuche und Zertifikate | Beziehungen erhalten, die das Lernmodell im Ziel benötigt. |
| Veranstaltungen und Buchungen | Veranstaltungen, Termine, Ressourcen, Teilnehmer, Reservierungen, Zahlungen und Erinnerungen | Zeitpläne und Buchungsbeziehungen nicht zu generischen Posts verflachen. |
| Verzeichnisse oder Marketplaces | Einträge, Eigentümer, Standorte, Attribute, Ansprüche, Anbieter und Auszahlungen | Bestimmen, welche Datensätze Inhalt und welche Bestandteil des Anwendungsablaufs sind. |
| SEO und Redirects | Metadaten, Canonical-Werte, Schema-Felder, Redirects und Social Previews | Werte dem richtigen routenbesitzenden Datensatz zuordnen und websiteweite Einstellungen getrennt halten. |
| Benutzerdefinierte Tabellen | Individuelle Objekte, Historien, Beziehungen, Logs und Integrationsschlüssel | Geschäftsschema übertragen, statt Tabellenzeilen ohne die besitzende Anwendung zu kopieren. |
Plugin-Dateinamen und Listen aktiver Plugins sind nicht das Datenmodell. Die tatsächliche Eigentumsstruktur ergibt sich aus registrierten Beitragstypen, Taxonomien, Metadaten-Keys, benutzerdefinierten Tabellen, Benutzerrollen, Optionen, geplanten Ereignissen und externen Referenzen, die die Website verwendet.
URLs, Permalinks, Archive und Multisite-Grenzen sind Teil der Datensatzidentität
WordPress-Routen können von Beitragstyp, Slug, übergeordneter Page, Veröffentlichungsdatum, Category, benutzerdefinierter Taxonomie, Archiveinstellungen, Rewrite-Regeln, Website-Domain und Plugin-Endpunkten abhängen. Eine Quell-URL lässt sich deshalb nicht immer allein aus dem Zieltitel rekonstruieren.
| Routenelement | Datensatzbeziehung | Auswirkung im Ziel |
|---|---|---|
| CMS-Page-Pfad | Page-Slug plus Elternhierarchie | Wird die Page unter einen anderen Parent verschoben, kann sich der vollständige Pfad ändern. |
| Blog-Post-Permalink | Post-Slug plus konfiguriertes Permalink-Muster | Datums- oder Category-Segmente können Teil der historischen URL sein. |
| Taxonomiearchiv | Taxonomie-Rewrite und Term-Slug | Ein Begriff kann ein öffentliches Archiv besitzen, auch ohne eigenen Menüeintrag. |
| Archiv eines benutzerdefinierten Beitragstyps | Registrierter Post-Type-Rewrite und Archiveinstellungen | Routen für einzelne Datensätze und Archive können getrennte Identitäten benötigen. |
| Plugin-Endpunkt | Anwendungsroute an Konto, Product, Kurs oder anderem Bereich | Der Endpunkt ist keine gewöhnliche CMS Page. |
| Multisite-URL | Netzwerk-, Website-, Domain- und Pfadkontext | Datensätze können einer Website gehören, während Benutzer oder Plugins netzwerkweite Beziehungen haben. |
| Redirect | Beziehung von alter Route zu neuem Ziel | Der alte Pfad bleibt ein Kontinuitätsdatensatz, auch wenn sich der Ziel-Slug ändert. |
WordPress Multisite ergänzt eine weitere Eigentumsebene. Posts, Pages, Begriffe, Optionen und viele Plugin-Datensätze sind websitebezogen, während Benutzer im gesamten Netzwerk beteiligt sein können. Netzwerkweit aktivierte Plugins und gemeinsam genutzte externe Services können zusätzlichen Umfang erzeugen. Ein Quellexport ohne Website-Identität kann Datensätze zusammenführen, die bewusst getrennt waren.
WordPress Core und Commerce-Plugins müssen getrennte Modelle bleiben
WordPress Core stellt keine nativen Products, Warenkörbe, Checkout, Customers, Orders, Coupons, Zahlungs-, Versand-, Tax-, Bestands- oder Auftragsabwicklungsfunktionen bereit. Diese Objekte gehören WooCommerce oder einem anderen Commerce-Plugin. Sie können WordPress-Beitragstypen, Taxonomien, Benutzer, Metadaten, Kommentare und Tabellen verwenden, doch ihre geschäftliche Bedeutung kommt aus der Commerce-Anwendung.
| Commerce-Konzept | Beziehung zu WordPress Core | Tatsächlicher Eigentümer |
|---|---|---|
| Product und Variante | Kann benutzerdefinierte Beitragstypen, Taxonomien, Metadaten oder eigene Tabellen verwenden | Commerce-Plugin und seine Erweiterungen |
| Customer | Kann mit einem WordPress-Benutzer verbunden sein oder als Gasttransaktionsidentität bestehen | Commerce-Plugin, CRM, Mitgliedschaftssystem oder externe Kontoplattform |
| Order und Order-Position | Kann benutzerdefinierte Beitragstypen oder eigene Commerce-Tabellen verwenden | Commerce-Plugin und Zahlungs- oder Auftragsabwicklungserweiterungen |
| Product-Bewertung | Kann Kommentare plus Bewertungsmetadaten nutzen | Product-Bewertungsmodell des Commerce-Plugins |
| Abonnement-, Buchungs-, Bundle- oder Anbieter-Datensatz | Kann Products, Benutzer und Orders referenzieren | Spezialisierte Erweiterung oder Marketplace-Anwendung |
| Zahlungs-, Tax-, Versand- und Auftragsabwicklungskontext | Kann in historischen Transaktionsdatensätzen vorkommen | Commerce- und operative Integrationen, nicht WordPress-Core-Inhalt |
Eine WordPress-Migration und eine WooCommerce-Migration haben daher unterschiedliche Umfänge, selbst wenn beide dieselbe Installation nutzen. Bevor Products, Customers, Orders oder anwendungsspezifische Datensätze interpretiert werden, muss das Ziel das Commerce-Plugin, dessen Version und Speichermodell, installierte Erweiterungen und externe Systeme benennen.
Eine WordPress-Übertragungsmatrix muss Eigentum und Bearbeitbarkeit erhalten
Das Zielmodell ist kohärent, wenn jeder Datensatz einen benannten Typ, Eigentümer, ein Klassifikationssystem, einen Metadatenvertrag, eine Route und eine Bearbeitungsoberfläche hat. Ziel ist nicht, das Datenbankdesign des Quellsystems zu kopieren. Ziel ist, die Beziehungen zu erhalten, durch die Redakteure, Administratoren, Anwendungen und externe Systeme die Daten verstehen.
| Frage zum Quellsystem | Entscheidung für das Ziel |
|---|---|
| Ist der Datensatz redaktioneller Inhalt oder ein Anwendungsobjekt? | Kern-Beitragstyp, benutzerdefinierten Beitragstyp, Plugin-Datensatz oder externen Systemeigentümer wählen. |
| Klassifiziert eine Gruppierung Datensätze oder ordnet sie nur die Navigation? | Taxonomiebeziehungen von Menüs und Landingpages trennen. |
| Enthält ein benutzerdefinierter Wert Daten oder referenziert er ein anderes Objekt? | Sowohl Wert als auch Zielbeziehung übertragen. |
| Liegt das Layout im Inhalt oder in einem Builder-/Template-System? | Inhaltsbedeutung getrennt von der Darstellungsimplementierung erhalten. |
| Ist ein Konto nur eine Login-Identität oder Teil eines Mitgliedschafts-, Lern-, Commerce- oder Anbietersystems? | WordPress-Benutzer und Anwendungsprofil als getrennte, aber verbundene Datensätze erhalten. |
| Entsteht eine URL aus Slug, Hierarchie, Archiv, Plugin-Endpunkt oder Multisite-Kontext? | Routenbesitzende Beziehung erhalten, statt sich nur auf Titel zu verlassen. |
| Gehört das Objekt WordPress Core, einem Plugin, einer benutzerdefinierten Tabelle oder einer externen Plattform? | Tatsächlichen Eigentümer ausdrücklich halten und stabile systemübergreifende Kennungen bewahren. |
Diese Entscheidungen halten die migrierte Website verwaltbar. Redakteure finden die richtigen Datensätze, Templates können die vorgesehenen Objekte darstellen, Archive und Filter fragen die passenden Klassifikationen ab, Konten behalten ihre Anwendungsbedeutung und Integrationen identifizieren weiterhin dieselben Geschäftsobjekte.
Fazit
WordPress verändert Datenbedeutung, weil wiederverwendbare Kerntabellen viele Datensatztypen aufnehmen, während Plugins und benutzerdefinierter Code spezialisierte Anwendungen definieren können. Posts, CMS Pages, benutzerdefinierte Beitragstypen, Taxonomien, Metadaten, Attachments, Benutzer, Kommentare, Optionen, Plugin-Tabellen, Routen und Commerce-Objekte können Infrastruktur teilen, ohne dieselbe geschäftliche Bedeutung zu haben.
Eine kohärente Migration erhält dieses Eigentum. Inhalte bleiben mit dem richtigen Beitragstyp und der richtigen Taxonomie verbunden, Metadaten mit ihrem Feldvertrag und referenzierten Datensätzen, Medien mit den Inhalten, die sie verwenden, Benutzer mit Rollen und Anwendungsprofilen, Routen mit ihren besitzenden Objekten und Plugin- oder Commerce-Datensätze getrennt von gewöhnlichen WordPress-Core-Inhalten.
Häufige Fragen
Sind benutzerdefinierte WordPress-Beitragstypen dasselbe wie CMS Pages?
Nein. Beide können über das WordPress-Posts-System gespeichert werden, doch ein benutzerdefinierter Beitragstyp kann eigene Editor-Funktionen, Taxonomien, Berechtigungen, Metadaten, Archive, REST-Verhalten und Templates besitzen. Das Ziel sollte den Typ erhalten, der den geschäftlichen Zweck des Datensatzes repräsentiert.
Kann jede Source Category zu einer WordPress Category werden?
Nein. Die Gruppierung aus dem Quellsystem kann in eine Standard-Category, einen Tag, eine benutzerdefinierte Taxonomie, eine Commerce-Taxonomie, ein Navigationsmenü, ein Metadatenfeld, einen Plugin-Filter oder eine externe Klassifikation gehören. Die Wahl hängt davon ab, was die Gruppierung klassifiziert und wie das Ziel sie abfragen oder anzeigen muss.
Warum sind benutzerdefinierte WordPress-Felder beziehungsabhängig?
Ein benutzerdefiniertes Feld kann einen Literalwert, die ID eines anderen Datensatzes, eine Attachment-Referenz, einen Begriff, einen Benutzer, eine serialisierte Struktur oder Plugin-Zustand enthalten. Wird nur der sichtbare Wert kopiert, ohne Beziehung oder Felddefinition zu übertragen, können die Zieldaten unbrauchbar werden.
Besitzen Themes und Page Builder die zugrunde liegenden Geschäftsdatensätze?
In der Regel nicht. Sie besitzen Darstellungsstrukturen, Templates, Styles und Layoutreferenzen. CMS Page, Blog Post, Product, Veranstaltung, Listing oder anderes Objekt bleiben WordPress Core oder dem zuständigen Plugin zugeordnet, auch wenn ein Builder ihre Darstellung steuert.
Sollten WooCommerce Products wie gewöhnliche WordPress Posts behandelt werden?
Nein. WooCommerce kann WordPress-Infrastruktur nutzen, doch Products, Varianten, Customers, Orders, Coupons, Bestand, Zahlung, Versand, Tax und Erweiterungen gehören zum WooCommerce-Commerce-Modell. Ihre Beziehungen müssen commercebezogen interpretiert werden.
Wann gehören WordPress-Daten in eine benutzerdefinierte Tabelle oder ein externes System statt in einen Beitragstyp?
Der Eigentümer wird durch die Anwendung bestimmt, die den Datensatz verwaltet. Transaktionen mit hohem Volumen, spezialisierte Historien, komplexe Viele-zu-viele-Beziehungen, Integrationslogs oder domänenspezifische Abläufe können in Plugin-Tabellen oder externen Plattformen liegen. Das Migrationsmodell sollte das Objekt und seine Referenzen erhalten, ohne es in einen generischen Post zu zwingen, nur weil WordPress das Website-Framework ist.