Von einzelnen Ortsseiten zur strukturierten Reiseplattform
OJ Destination entstand für ein Reiseportal mit vielen miteinander verbundenen Orts- und Reisedaten. Statt Länder, Regionen, Destinationen, Inseln und Strände als lose Joomla-Beiträge zu pflegen, wurde ein eigenes Datenmodell mit Taxonomien, Relationen, Features und Import-/Export-Pipeline aufgebaut.
Ausgangslage
Ein wachsendes Reiseportal benötigt mehr als statische Inhaltsseiten. Orte stehen in Beziehungen, teilen Merkmale, brauchen filterbare Taxonomien und sollen aus mehreren Quellen importiert sowie SEO-fähig veröffentlicht werden.
Geografische Hierarchie
Land, Region, Destination, Insel und Strand müssen fachlich konsistent miteinander verbunden sein.
Dynamische Merkmale
Ausstattung und Eigenschaften sollen je Inhaltstyp unterschiedlich sein, ohne ständig neue Datenbankspalten einzubauen.
Große Datenmengen
CSV-, JSON- und externe Quellen müssen idempotent und nachvollziehbar importiert werden können.
Viele öffentliche Seitentypen
Jede Entität benötigt eigene URLs, Metadaten, Listen und Sitemap-Ausgabe.
Die technische Struktur
Jeder fachliche Inhaltstyp besitzt eine eigene Tabelle und eigene Verwaltungslogik.
Feature Groups, Features und Taxonomien bleiben dynamisch und können typabhängig verwendet werden.
Beziehungen zwischen Destinationen und weiteren Entitäten werden explizit statt über Freitext modelliert.
Import/Export und externe Source-Manager bauen auf derselben normalisierten Datenbasis auf.
Wichtige Meilensteine
Länder, Regionen und Destinationen bildeten die erste hierarchische Datenstruktur.
Destination Types, Features, Feature Groups und Taxonomy erweiterten das Modell dynamisch.
Entitäten konnten fachlich miteinander verbunden werden.
CSV- und JSON-Pipelines wurden schrittweise ergänzt und gehärtet.
Das Modell wurde um neue eigenständige Reiseentitäten erweitert.
Source Manager und API-Verbindungstests legten die Basis für externe Datenquellen.
Was technisch besonders interessant war
Während der Entwicklung traten typische Evolutionsprobleme wie fehlende Default-Werte, doppelte Spalten oder geänderte Provider-Felder auf. Sie wurden durch versionierte Migrationen und reale Upgrade-Tests schrittweise bereinigt.
Listenfilter mussten nicht nur UI-seitig sichtbar, sondern serverseitig korrekt an Query und Pagination gekoppelt werden.
Dynamische Seitentypen benötigen verlässliche Ersetzung von Platzhaltern in Title und Meta-Daten sowie eigene Sitemap-Ausgaben.
Tests und belastbare Nachweise
Importe wurden mit wiederholten Läufen und bereits vorhandenen Datensätzen getestet, um Duplikate und Schemafehler früh zu erkennen.
Externe Source-Endpunkte wurden über Verbindungstests mit HTTP-Status und konfigurierbarem Source Key geprüft.
Beziehungen wie Destination ↔ Insel ↔ Land/Region werden serverseitig auf Konsistenz geprüft.
Ein erweiterbares Domänenmodell statt wachsender Beitrags-Sonderlösungen
OJ Destination zeigt, wie ein Joomla-Projekt von einfachen Inhaltstabellen zu einer domänenspezifischen Plattform wachsen kann. Entscheidend war, Entitäten, Taxonomien, Features, Relationen und Datenquellen voneinander zu trennen, damit neue Reisetypen ergänzt werden können, ohne das Grundmodell neu aufzubauen.
Sie planen ein Portal mit vielen strukturierten Datentypen?
Die Architektur von Destination lässt sich auf Reise-, Branchen-, Immobilien- oder andere Verzeichnisprojekte übertragen, bei denen Relationen, Filter und Importe wichtiger sind als klassische Beitragsseiten.