Joomla bildet eine Website weder als eine einzige Sammlung von Seiten ab noch stellt es ein universelles Commerce-Schema bereit. Das Datenmodell trennt Inhaltsdatensätze, Kategoriehierarchien, Menürouten, Module, Template-Zuweisungen, Benutzer, Zugriffskontrollen, Sprachen, Medien, benutzerdefinierte Felder und erweiterungseigene Entitäten. Eine im Browser einfach wirkende Seite kann deshalb von mehreren Datensätzen mit unterschiedlichen Verantwortlichen abhängen.
Wenn Joomla als potenzielle Zielplattform bewertet wird, muss die Migrationsplanung Beziehungen übersetzen und nicht lediglich Textfelder kopieren. Ein Artikel kann den Hauptinhalt enthalten, während ein Menüeintrag die öffentliche Route bestimmt, eine Kategorie den organisatorischen Kontext liefert, eine Zugriffsebene die Sichtbarkeit steuert, ein Modul ergänzende Inhalte bereitstellt und eine Erweiterung den Geschäftsprozess hinter der Seite besitzt. Nur den sichtbaren Inhaltskörper zu erhalten, kann daher Datensätze erzeugen, die im Ziel vorhanden sind, aber ihre Navigations-, Berechtigungs-, Sprach- oder Anwendungsbedeutung verloren haben.
Joomla trennt Inhalte, Routing, Darstellung und Anwendungsdaten
Joomla Core stellt wiederverwendbare Strukturen bereit, doch jede Struktur hat eine eigene Aufgabe. Artikel und andere Komponenten-Datensätze speichern Inhalte. Kategorien gruppieren Datensätze innerhalb der jeweils zuständigen Komponente. Menüs erzeugen geordnete Navigation und Routenbeziehungen. Module platzieren wiederverwendbare Ausgabe um eine Seite. Templates und Overrides bestimmen die Darstellung. Benutzer, Gruppen und Zugriffsebenen steuern Identität und Sichtbarkeit. Komponenten, Plugins und individueller Code fügen anwendungsspezifische Datensätze hinzu.
| Joomla-Ebene | Primäre Bedeutung | Konsequenz für die Übertragung |
|---|---|---|
| Artikel und Komponenten-Datensätze | Bearbeitbare Inhalte oder anwendungseigene Datensätze | Das Ziel muss den tatsächlichen Besitzer des Datensatzes bestimmen, statt jede sichtbare Seite als Artikel zu behandeln. |
| Kategorien | Hierarchische Gruppierung innerhalb einer bestimmten Komponente | Eine Content-Kategorie und eine Commerce-Kategorie können gleich heißen und trotzdem unterschiedlichen Datenbereichen angehören. |
| Menüs und Menüeinträge | Navigation, Route, Alias, Sprache, Zugriff und Seitenkontext | Öffentliche URLs und Einstiegspunkte können von Menübeziehungen statt nur von Artikeltiteln abhängen. |
| Module | Wiederverwendbare Blöcke mit Positions- und Seitenzuweisung | Ergänzende Inhalte können einen eigenen Zieldatensatz und eine eigene Platzierungsbeziehung benötigen. |
| Templates und Overrides | Layout und gerenderte Ausgabe | Sie sind Darstellungsressourcen und kein Ersatz für migrierte Inhalte oder Anwendungsdaten. |
| Benutzer, Gruppen und Zugriffsebenen | Identität, Berechtigungen und Sichtbarkeit | Ein Joomla-Konto darf nicht automatisch als Commerce-Customer oder Geschäftssegment interpretiert werden. |
| Komponenten, Plugins und individuelle Tabellen | Domänenspezifisches Verhalten und Datensätze | Commerce, Mitgliedschaften, Formulare, Verzeichnisse, Downloads und Integrationen erfordern eine besitzerspezifische Interpretation. |
Dieses Schichtenmodell ist der zentrale Unterschied bei Joomla-Migrationen. Dasselbe Quellfeld kann je nach Funktion im Ziel zu Core-Inhalt, Menüparameter, benutzerdefiniertem Feld, Komponenten-Datensatz, Benutzerbeziehung oder Implementierungsanforderung werden.
Artikel, Kategorien und Menüeinträge tragen unterschiedliche Beziehungen
Ein Artikel ist ein Inhaltsdatensatz. Eine Kategorie gruppiert Datensätze, die zur selben Joomla-Komponente gehören. Ein Menüeintrag ist ein Navigations- und Routing-Datensatz, der auf einen Artikel, eine Kategorieansicht, eine externe Komponente, einen Systemlink oder ein anderes Ziel verweisen kann. Diese Objekte können gemeinsam eine öffentliche Seite beschreiben, sind aber nicht austauschbar.
Joomla-Kategorien sind komponentenbezogen. Der Kategoriebaum für Core-Inhalte ist von Kategoriepartitionen anderer Komponenten getrennt, auch wenn diese Joomla-Kategorien unterstützen. Das ist wichtig, wenn die Quellplattform nur eine universelle Taxonomie kennt. Eine Source-„Category“ kann im Ziel als Joomla-Content-Kategorie, Commerce-Kategorie, Tag, Menüast oder Kombination mehrerer Datensätze erscheinen müssen.
Menüeinträge enthalten strukturelle Informationen, die Inhaltsdatensätze nicht besitzen. Aliase können URL-Pfade bilden, Parent-Child-Beziehungen Menübäume erzeugen, Sprach- und Zugriffsangaben Verfügbarkeit bestimmen, Komponentenverweise die geöffnete Ansicht festlegen und Template-Stil-Zuweisungen die Darstellung einer konkreten Route verändern.
| Source-Konzept | Mögliche Joomla-Abbildung | Bedeutung, die ausdrücklich erhalten bleiben muss |
|---|---|---|
| Redaktionelle Seite | Artikel plus ein oder mehrere Menüeinträge | Der Artikel besitzt den Inhalt; der Menüeintrag besitzt den navigierbaren Einstiegspunkt und Routenkontext. |
| Landingpage einer Product Category | Commerce-Kategorie plus Joomla-Menüeintrag | Commerce-Gruppierung und öffentliche Navigation bleiben getrennte Beziehungen. |
| Bereich einer Ressourcenbibliothek | Kategorie, getaggte Artikel, Menüeintrag und Module | Klassifizierung, Inhalt, Route und ergänzende Anzeigen können unterschiedliche Verantwortliche haben. |
| Direkter URL-Alias | Menüalias, Komponentenrouter-Ausgabe oder Redirect-Datensatz | Der öffentliche Pfad darf nicht sicher allein aus einem Titel abgeleitet werden. |
| Verborgene Landingpage | Veröffentlichter Datensatz ohne sichtbaren Menüeintrag oder mit verborgenem Menüeintrag | Sichtbarkeit in der Navigation ist nicht dasselbe wie Veröffentlichungsstatus oder URL-Erreichbarkeit. |
Ein Zielmodell sollte daher Datensatzidentität und Routenidentität getrennt erhalten. Werden sie zu früh zusammengeführt, können Aliase, Parent-Pfade, sprachspezifische Einstiegspunkte, Breadcrumbs, Zugriffsverhalten oder interne Links beschädigt werden.
Module, Templates und Overrides sind keine Seitenkörper
Joomla setzt Seiten aus mehr als der primären Komponenten-Ausgabe zusammen. Module können Navigation, Banner, Formulare, Suche, Kontozugriff, Sprachumschaltung, verwandte Inhalte, Custom HTML oder erweiterungsspezifische Blöcke bereitstellen. Ihre Bedeutung hängt von Modultyp, Position, Veröffentlichungsstatus, Sprache, Zugriff und Menüzuweisung ab.
Eine Quellplattform kann sämtlichen Seiteninhalt in einem Layout-Datensatz speichern, während Joomla dasselbe Ergebnis auf Artikel oder Komponentenansicht und mehrere Module verteilt. Umgekehrt kann eine Joomla-Seite aus mehreren Modulen bestehen und im Ziel zu einer einzigen strukturierten Seite werden. Die Migration muss entscheiden, ob ein Modul ein wiederverwendbarer Block bleibt, in Inhalte eingebettet wird, einem Ziel-Widget entspricht oder Teil einer separaten Design-Implementierung ist.
Templates und Layout-Overrides bilden eine weitere Verantwortungsgrenze. Ein Template-Stil kann über Menüeinträge zugewiesen sein, und ein Override kann die Ausgabe einer Komponente oder eines Moduls verändern, ohne den zugrunde liegenden Datensatz zu ändern. Der Product-, Artikel-, Customer- oder Order-Datensatz kann weiterhin migrierbar sein, auch wenn die alte Darstellung nicht als Daten reproduziert werden kann.
| Joomla-Darstellungsobjekt | Was es besitzt | Was es nicht besitzt |
|---|---|---|
| Modul | Wiederverwendbarer Anzeige-Datensatz und Zuweisungskontext | Den primären Geschäftsdatensatz, den eine Komponente rendert |
| Modulposition | Platzierungsbezeichner, den ein Template erwartet | Den Inhalt innerhalb des Moduls |
| Template-Stil | Visuelle und Layout-Konfiguration für ausgewählte Routen | Bedeutung von Artikel, Product, Customer oder Order |
| Layout-Override | Veränderte Rendering-Logik | Standardmäßig keinen portablen Zieldatensatz |
| Custom-HTML-Modul | Wiederverwendbarer Inhalt außerhalb eines Artikels | Vollständige Seitenroute oder Anwendungsverhalten |
Diese Grenzen zu erhalten verhindert, dass Darstellungsartefakte mit fehlenden Inhalten verwechselt oder Geschäftsdatensätze in einer Diskussion über Design-Neuaufbau verborgen werden.
Joomla-Benutzer, Gruppen, Zugriffsebenen und Customers sind getrennte Konzepte
Ein Joomla-Benutzer ist in erster Linie eine Identität für die Anmeldung an Website oder Administrationsbereich. Das Konto kann Benutzername, E-Mail, Status, Einstellungen, Gruppenmitgliedschaft und Berechtigungskontext tragen. Die Joomla Access Control trennt anschließend, was ein Benutzer sehen darf, von dem, was er tun darf.
Dieses Modell entspricht nicht einem Commerce-Customer-Modell. Eine Commerce-Erweiterung kann Customer-, Adress-, Shopper-Group-, Abonnement-, Mitgliedschafts- oder Order-Datensätze mit einer Joomla-User-ID verbinden, diese Datensätze bleiben aber Eigentum der Erweiterung. Ein registrierter Joomla-Benutzer muss nie etwas gekauft haben; eine Guest Order kann Käuferdaten enthalten, ohne dass ein dauerhaftes Joomla-Konto existiert.
| Identitätsbezogener Datensatz | Bedeutung in Joomla | Häufige Abweichung vom Source-Modell |
|---|---|---|
| User | Login-Identität und Core-Kontoattribute | Wird als vollständiges Customer-Profil behandelt, obwohl Commerce-Details anderswo liegen |
| User Group | Berechtigungsgruppe für Joomla ACL | Wird mit Marketingsegment, Preisgruppe oder B2B-Unternehmen verwechselt |
| Viewing Access Level | Legt fest, welche Gruppen ein Element sehen dürfen | Wird zu einem einfachen public/private-Flag abgeflacht und verliert mehrstufige Sichtbarkeitsregeln |
| Administrator permissions | Aktionen, die ein Benutzer in einer Komponente ausführen darf | Werden mit Status des Shop-Kontos verwechselt |
| Extension Customer | Käufer- oder Mitgliedsdatensatz, gegebenenfalls mit Joomla User verknüpft | Geht verloren, wenn nur die Core-User-Tabelle übertragen wird |
| Guest buyer | Historische Käuferdetails, die mit einer Order gespeichert sind | Wird fälschlich zu einem permanenten Joomla-Benutzerkonto gemacht |
Das Zielmodell sollte Identität, Autorisierung, Käuferprofil, Adresse, Organisation und historische Transaktionsverantwortung getrennt erhalten. Werden diese Konzepte zusammengeführt, können geschützte Inhalte offengelegt, legitime Zugriffe entfernt, Customers dupliziert oder Orders von ihrer korrekten historischen Identität getrennt werden.
Benutzerdefinierte Felder, Tags, Medien und Metadaten ergänzen strukturierte Bedeutung
Joomla benutzerdefinierte Felder können strukturierte Werte an unterstützte Datensatztypen wie Artikel, Benutzer oder Kontakte anhängen. Ihre geschäftliche Rolle ist sehr unterschiedlich: redaktionelle Kennzeichnung, technische Spezifikation, Verzeichnisdaten, externe Identifikatoren, Mitgliedsattribute, Integrationsschlüssel oder strukturierter Seiteninhalt. Die Feldbezeichnung allein bestimmt nicht die Zielabbildung.
Tags ermöglichen flexible Klassifizierung über Kategorien hinweg. Medien und Dateipfade können Inline-Bilder, Galerien, Downloads, Dokumente oder Erweiterungsressourcen unterstützen. Metadaten können an Artikeln, Kategorien, Menüeinträgen oder Erweiterungsdatensätzen liegen und Such-Snippets, Sharing, Indexierung und Routing beeinflussen.
| Datenbereich | Beziehungsfrage | Interpretation im Ziel |
|---|---|---|
| Benutzerdefiniertes Feld | Welche Komponente und welcher Datensatztyp besitzt den Wert? | Abbildung auf natives Zielfeld, strukturiertes Inhaltselement, Erweiterungsfeld oder externe Datenbeziehung. |
| Tag | Dient es Navigation, Filterung, Related Content oder redaktioneller Kennzeichnung? | Nur die tatsächlich ausgeübte Geschäftsbeziehung erhalten. |
| Medienobjekt | Welche Datensätze verwenden die Ressource wieder, und ist der Pfad im Inhalt eingebettet? | Anhangs- und Wiederverwendungsbeziehungen erhalten statt Dateien ohne Referenzen zu kopieren. |
| Metadaten | Gehört der Wert zu Inhalt, Route, Kategorie oder Komponente? | An das Zielobjekt hängen, das die entsprechende öffentliche Ausgabe steuert. |
| Externer Identifikator | Welches System nutzt den Wert als Schlüssel? | Identifikator stabil halten und am richtigen Zielobjekt bewahren. |
Eine Feldzuordnung, die die Komponentenverantwortung ignoriert, kann einen gültigen Wert auf das falsche Objekt setzen. Der Wert erscheint dann eventuell im Ziel, während Filterung, Integration, Zugriff oder Bearbeitungsverhalten verloren gehen.
Mehrsprachige Daten verwenden Sprachen, Zuordnungen, Routen und Erweiterungsunterstützung
Joomla unterscheidet Benutzeroberflächenübersetzung und Inhaltssprache. Inhaltsdatensätze können einer Sprache zugewiesen werden, während mehrsprachige Associations äquivalente Datensätze miteinander verbinden. Menüstrukturen, Standardseiten, Aliase, Module, Kategorien und Erweiterungsdatensätze können ebenfalls sprachabhängig sein.
Eine Quellplattform, die Übersetzungen als Spalten in einem einzigen Datensatz speichert, benötigt im Ziel möglicherweise mehrere miteinander verbundene Joomla-Datensätze. Eine andere Source kann bereits separate Datensätze verwenden, aber keine Joomla-Associations besitzen. Erweiterungen können mehrsprachige Felder über Joomla Core, eigene Tabellen oder Übersetzungssysteme Dritter verwalten.
| Mehrsprachiges Element | Bedeutung im Datenmodell |
|---|---|
| Content Language | Kennzeichnet die Sprache eines Content- oder Komponenten-Datensatzes |
| Language Association | Verknüpft äquivalente Datensätze, ohne daraus einen Datensatz zu machen |
| Sprachspezifischer Menüeintrag | Stellt Route und Navigationskontext einer Sprache bereit |
| Sprachspezifisches Modul | Stellt ergänzende Inhalte für ausgewählte Sprachrouten bereit |
| Erweiterungsübersetzung | Enthält übersetzte Commerce- oder Anwendungsdaten entsprechend dem Erweiterungsdesign |
| Language Override | Ändert Oberflächentext statt Geschäftsinhalte zu migrieren |
Das Zielmodell muss übersetzte Geschäftsinhalte von Interface-Strings und Routenbeziehungen unterscheiden. Text ohne Associations kann doppelt wirkende Seiten erzeugen, die nicht als Sprachäquivalente verbunden sind. Associations ohne zugehörigen Menü- und Modulkontext können einen Sprachzweig unvollständig lassen.
Erweiterungen definieren die Grenzen von Commerce und anderen Anwendungen
Joomla Core definiert keine nativen Products, Warenkörbe, Customers, Orders, Abonnements, Veranstaltungen, Verzeichnisse oder Marketplace-Datensätze. Diese Entitäten gehören installierten Komponenten oder individuellen Anwendungen. Zwei Joomla-Websites können deshalb ähnlich aussehen und Commerce-Daten dennoch in völlig unterschiedlichen Tabellen und Beziehungen speichern.
Die zuständige Erweiterung definiert Product-Typen, Kategorien, Options- oder Variantenverhalten, Preise, Bestand, Customer-Verknüpfung, Order Lines, Statushistorie, Zahlungsreferenzen, Versandreferenzen, benutzerdefinierte Felder und Integrationsidentifikatoren. Plugins und Module können weitere Datensätze hinzufügen oder deren Interpretation verändern.
| Commerce-Konzept | Position in Joomla Core | Tatsächlicher Datenbesitzer |
|---|---|---|
| Product und verkaufbare Auswahl | Kein universelles Core-Product-Schema | Commerce-Komponente und ihre Erweiterungen |
| Customer und Adresse | Core User stellt gegebenenfalls nur Identität bereit | Commerce-Komponente, Membership-Komponente oder individuelle Anwendung |
| Order und Order Line | Kein universelles Core-Order-Schema | Commerce-Komponente oder externes Order-System |
| Preisgruppe oder B2B-Regel | Standardmäßig nicht gleichbedeutend mit Joomla User Groups | Commerce-Erweiterung, Preis-Plugin oder externes System |
| Checkout-Feld | Standardmäßig kein Core-User-Feld | Commerce-Komponente, Formular-Plugin oder individuelle Tabelle |
| Zahlungs- und Versandreferenz | Historischer Kontext beim Commerce-Besitzer | Commerce-Komponente plus Gateway- oder Carrier-Plugin |
„Joomla-Daten“ ist deshalb keine ausreichende Umfangsdefinition. Das Migrationsinventar muss Komponenten, Plugins, Module, individuelle Tabellen und externe Systeme benennen, die kommerziell wichtige Datensätze besitzen.
Individuelle Implementierungen und externe Identifikatoren benötigen eine Verantwortlichership Map
Lang laufende Joomla-Websites enthalten häufig individuelle Komponenten, modifizierte Erweiterungstabellen, Template-Overrides, Event-Plugins, geplante Aufgaben, API-Integrationen und direkte Datenbankbeziehungen. Manche individuellen Werte dienen nur der Darstellung, andere sind maßgebliche Geschäftsschlüssel.
Eine nützliche Verantwortlichership Map identifiziert Datensatz, Tabellen- oder API-Besitzer, Parent-Entität, konsumierendes externes System und Zielobjekt, das den Wert tragen muss. Das ist besonders wichtig für ERP-IDs, CRM-IDs, Dokumentreferenzen, Mitgliedschaftsstatus, Marketplace-Seller-IDs, Fulfillment-Schlüssel und Synchronisationszeitpunkte.
| Verantwortlichership-Signal | Warum es die Übertragung verändert |
|---|---|
| Individuelle Tabelle mit Fremdschlüsseln zu Core Users oder Articles | Der Geschäftsdatensatz kann verschwinden, wenn nur Joomla-Core-Tabellen interpretiert werden. |
| Plugin-erzeugtes Feld oder Event-Datensatz | Der Wert kann von Plugin-Verhalten statt von einem nativen Zielfeld abhängen. |
| Identifikator, den ein externes System wiederverwendet | Neue IDs können Abstimmung oder Synchronisation beschädigen. |
| Override, das nicht standardmäßige Spalten liest | Die sichtbare Seite kann von Daten abhängen, die in gewöhnlichen Komponentenansichten nicht erscheinen. |
| Mehrere Erweiterungen verwenden denselben User | Identität muss geteilt bleiben, während jedes Erweiterungsprofil getrennt bleibt. |
Das Ziel muss nicht jedes Joomla-Implementierungsdetail reproduzieren. Für jede Beziehung mit geschäftlicher, Zugriffs-, Inhalts- oder Integrationsbedeutung muss jedoch eine bewusste Zielrepräsentation existieren.
Fazit
Eine Joomla-Migration ist im Kern eine Übersetzung zwischen Ebenen. Artikel, Kategorien, Menüeinträge, Module, Templates, Benutzer, Zugriffsebenen, Sprachen, benutzerdefinierte Felder, Medien, Erweiterungen und externe Systeme besitzen jeweils unterschiedliche Teile der Website-Bedeutung.
Ein kohärentes Zielmodell erhält diese Verantwortungsgrenzen, bevor entschieden wird, wie einzelne Datensätze dargestellt werden. So bleiben Inhalte mit Routen, Identitäten mit Berechtigungen, Übersetzungen mit Sprachstruktur, Commerce-Datensätze mit ihrer zuständigen Erweiterung und externe Identifikatoren mit den Systemen verbunden, die darauf angewiesen sind.
Häufige Fragen
Stellt Joomla ein natives Product- und Order-Modell bereit?
Nein. Joomla Core stellt Inhalte, Identität, Zugriff, Routing und Erweiterungsinfrastruktur bereit. Products und Orders gehören einer Commerce-Komponente oder individuellen Anwendung; ihre Migrationsbedeutung muss aus dem Schema dieses Besitzers abgeleitet werden.
Sind Joomla-Kategorien dasselbe wie Menüeinträge?
Nein. Kategorien gruppieren Datensätze innerhalb einer Komponente, während Menüeinträge Navigation und Routenbeziehungen erzeugen. Eine öffentliche Kategorieseite kann von beiden Objekten abhängen, sie sollten im Ziel jedoch getrennt bleiben.
Kann jeder Joomla-Benutzer als Customer migriert werden?
Nein. Ein Joomla User ist Login-Identität und Berechtigungssubjekt. Commerce-Customers, Adressen, Mitgliedschaften und Orders können getrennte erweiterungseigene Datensätze sein; Guest Buyers besitzen möglicherweise gar kein Joomla-Konto.
Wie sollten Module und Template-Overrides abgebildet werden?
Module sollten nach wiederverwendbarem Inhalt und Zuweisungsbeziehungen klassifiziert werden. Templates und Overrides gehören normalerweise zur Darstellungsimplementierung statt zur Geschäftsdatensatzmigration. Inhalte innerhalb individueller Module müssen dennoch berücksichtigt werden.
Warum sind mehrsprachige Joomla-Daten besonders beziehungsabhängig?
Sprachzuweisungen, verbundene Datensätze, sprachspezifische Menüs, Module, Aliase und Erweiterungsübersetzungen können gemeinsam eine Sprachversion bilden. Übersetzter Text allein erhält diese Beziehungen nicht.
Wann benötigen individuelle Joomla-Daten ein separates Zieldesign?
Wenn wichtige Werte in individuellen Tabellen, Erweiterungsfeldern, Plugin-Datensätzen, Overrides oder externen Integrationen liegen, die keinem Standard-Zielobjekt entsprechen. Das Zieldesign sollte die geschäftliche Bedeutung und Zuständigkeit erhalten, nicht blind die Source-Speicherstruktur kopieren.