Einleitung
In Odoo bestimmen Modelle die Struktur und Speicherung Ihrer Geschäftsdaten. Alles, was Sie im Tagesgeschäft an Informationen anlegen — Seiten, Produkte, Kontakte — lebt in einem oder mehreren Modellen.
Ein solides Verständnis der Odoo‑Modelle ist sowohl für technische Entwickler als auch für funktionale Berater unerlässlich. Modelle legen die Felder, Beziehungen und die Geschäftslogik fest, auf denen die gesamte Odoo‑Datenarchitektur aufbaut.
Dieser Beitrag konzentriert sich auf das website.page‑Modell. Es bildet die Grundlage für statische Seiten auf Ihrer Odoo‑Website. Ob Sie Landingpages erstellen, Content pflegen oder externe Systeme anbinden: mit diesem Modell werden Sie häufig arbeiten.
Was ist das website.page‑Modell?
Das website.page‑Modell bildet statische Seiten der Website ab. Es gehört zur Website‑Applikation und speichert jene Seiten, die Sie per Website‑Builder anlegen — etwa "Über uns", Kontaktseiten oder spezielle Kampagnen‑Landingpages.
Technisch betrachtet nutzt das Modell Odoos Vererbungsmechanismen. website.page ist mit ir.ui.view verknüpft (mittels _inherits). Jede Seite referenziert eine ir.ui.view, die das QWeb‑Template (arch) und Metadaten enthält.
Dynamisch erzeugte Seiten wie Shop‑Listings oder Blogübersichten werden anders behandelt und nicht über website.page persistiert.
Nur statische, manuell erstellte Seiten werden als website.page‑Einträge gespeichert. Dynamische Listen oder Routinen werden zur Laufzeit generiert und gehören nicht in dieses Modell.
Wichtige Felder im Modell
Im Folgenden die zentralen Felder des website.page‑Modells. Wer diese Felder kennt, kann Seiten sicher konfigurieren, auslesen und automatisieren.
1. name
Typ: Char. Der Seiten‑Titel; sichtbar im Browser‑Tab, in Menüs und bei Suchergebnissen. Dieser Wert stammt in der Regel aus der verknüpften ir.ui.view.
2. url
Typ: Char. Pfad der Seite im Web. Muss mit einem Schrägstrich beginnen (z. B. /kontakt, /ueber-uns). Besucher rufen die Seite über diesen Pfad auf.
3. view_id
Typ: Many2one (ir.ui.view). Obligatorisch. Verweist auf die QWeb‑View mit dem Seiteninhalt. Die View enthält die arch (XML) und den eindeutigen key. Beim Löschen der View wird die Seite üblicherweise mit gelöscht.
4. website_id
Typ: Many2one (website). Die Website, zu der die Seite gehört. In Multi‑Website‑Setups lassen sich Seiten einer bestimmten Website zuordnen oder, bei leerem Wert, als geteilt behandeln.
5. is_published
Typ: Boolean. Steuert, ob Besucher die Seite sehen. Unveröffentlichte Seiten liefern 404 oder Weiterleitungen; so kann man Inhalte verbergen, ohne sie zu löschen.
6. website_indexed
Typ: Boolean. Legt fest, ob Suchmaschinen die Seite indexieren dürfen. Für Dankeseiten oder interne Inhalte sollte dieses Feld typischerweise auf False gesetzt sein.
7. date_publish
Typ: Datetime. Veröffentlichungsdatum. Nützlich für zeitgesteuerte Veröffentlichungen und zur Anzeige, wann ein Inhalt live ging.
8. header_visible
Typ: Boolean. Bestimmt, ob der Website‑Header angezeigt wird. Praktisch für Landingpages oder Fullscreen‑Layouts, bei denen der Header ausgeblendet werden soll.
9. footer_visible
Typ: Boolean. Bestimmt, ob der Footer sichtbar ist. Erlaubt ebenfalls das Erzeugen von Seiten ohne Standard‑Footer.
10. is_homepage
Typ: Boolean (berechnet). True, wenn die Seite als Startseite der Website gesetzt ist. Pro Website darf nur eine Seite als Homepage fungieren.
11. is_visible
Typ: Boolean (berechnet). Zeigt an, ob die Seite nach Publikationsstatus, Datum und Sichtbarkeitsregeln tatsächlich sichtbar sein sollte.
12. menu_ids
Typ: One2many (website.menu). Verknüpfte Menüpunkte, die auf diese Seite zeigen. Eine Seite kann in mehreren Menüs auftauchen oder in keinem.
13. create_date
Typ: Datetime. Zeitpunkt der Erstellung des Datensatzes. Wird automatisch verwaltet und ist wichtig für Audits und Berichte.
14. write_date
Typ: Datetime. Zeitpunkt der letzten Änderung. Ebenfalls automatisch und nützlich zum Nachverfolgen von Updates.
15. arch
Typ: Text. Das QWeb‑XML‑Template, gespeichert in der verknüpften ir.ui.view. Enthält HTML‑Struktur und Odoo‑Snippets; editierbar über den Website‑Builder.
16. key
Typ: Char. Eindeutiger Bezeichner der View, genutzt in Modul‑XML und bei Vererbung. Übliches Format: modul.view_name.
17. type
Typ: Selection. Typ der View. Für Website‑Seiten ist dies immer qweb; andere Typen sind z. B. form, list oder tree.
18. active
Typ: Boolean. Soft‑Delete‑Flag (Archivierung). Stammt aus ir.ui.view; archivierte Seiten werden nicht mehr ausgeliefert.
19. website_meta_title
Typ: Char. SEO‑Meta‑Title. Überschreibt den Standard‑Titel in Suchergebnissen und ist wichtig für Auffindbarkeit.
20. website_meta_description
Typ: Text. SEO‑Meta‑Description. Textauszug, den Suchmaschinen anzeigen. Optimal sind ca. 150–160 Zeichen.
21. website_meta_keywords
Typ: Char. Meta‑Keywords. Heute nur noch selten relevant, können aber von einigen Tools genutzt werden. Kommagetrennte Liste.
22. header_overlay
Typ: Boolean. Definiert, ob der Header über dem Content liegt. Nützlich für Hero‑Bilder, bei denen der Header über dem Banner schwebt.
23. header_color
Typ: Selection. Farbschema des Headers (z. B. transparent, hell, dunkel). Beeinflusst Lesbarkeit und Kontrast.
24. visibility
Typ: Selection. Zugriffskontrolle. Optionen: Öffentlich, Angemeldet, Bestimmte Gruppe oder Passwortgeschützt. Steuert, wer die Seite sehen darf.
25. redirect_type
Typ: Selection. Regel für URL‑Änderungen: 301 permanent, 302 temporär oder keine Weiterleitung. Wichtig für SEO beim Verschieben von Inhalten.
Wie dieses Modell in Geschäftsprozessen genutzt wird
1. Landingpages und Kampagnen
Marketing‑Teams legen Landingpages als website.page‑Einträge an. Dort steuern sie URL, Inhalt und Veröffentlichungszeitpunkt; geplante Veröffentlichungen nutzen date_publish.
2. Unternehmensseiten
Seiten wie "Über uns", Kontakt, AGB oder Datenschutz sind typischerweise website.page‑Datensätze. Sie werden einmal angelegt und bei Bedarf aktualisiert; die Menüzuordnung erfolgt über menu_ids.
3. Dankeseiten und Bestätigungen
Seiten wie "Kontaktformular erfolgreich versendet" sollten als website.page angelegt und für Suchmaschinen ausgeblendet (website_indexed = False) werden, damit sie nicht in den Ergebnissen auftauchen.
4. Multi‑Website und Lokalisierung
In Multi‑Website‑Szenarien steuert website_id, welche Site die Seite anzeigt. Für sprachliche Anpassungen kann man Seiten pro Website duplizieren und lokalisierte Inhalte pflegen.
5. Geschützte Inhalte und Zugriffsbeschränkungen
Mit dem visibility‑Feld lassen sich Seiten nur für eingeloggte Nutzer oder bestimmte Gruppen freigeben — sinnvoll für Member‑Bereiche oder interne Dokumentationen.
Wie Entwickler das Modell erweitern
Entwickler erweitern website.page mit mehreren Mustern; die Odoo‑Modellvererbung ist dabei das zentrale Werkzeug.
Modell‑Vererbung
Erweitern Sie das Modell mit _inherit = 'website.page', um zusätzliche Felder, Validierungen oder Methoden zu ergänzen. Solche Erweiterungen bleiben in Ihrem Modul und erleichtern Upgrades.
Felder hinzufügen
Definieren Sie neue Felder im geerbten Modell und wählen Sie passende Typen: Char, Many2one, Boolean, Integer, Text, Selection. Denken Sie an website‑abhängige Felder bei Multi‑Website‑Setups.
Python‑Erweiterungen
Überschreiben Sie create, write oder unlink, um eigene Logik einzubauen. Rufen Sie super() auf, um Originalverhalten zu bewahren. Achten Sie auf die view_id‑Beziehung und mögliche Cascade‑Effekte.
Odoo Studio
Odoo Studio ermöglicht Anpassungen ohne Code — ideal für Layout‑Änderungen. Für komplexe Logik, API‑Anbindungen oder wartbare Erweiterungen sind Custom‑Module jedoch langfristig die bessere Wahl.
Best Practices
- Verwenden Sie URL‑freundliche Slugs: keine Leerzeichen oder Sonderzeichen, stattdessen Bindestriche zur Lesbarkeit.
- Schalten Sie website_indexed für Dankeseiten, Bestätigungsseiten und interne Inhalte auf False, damit Suchmaschinen diese nicht indexieren.
- Bei URL‑Änderungen immer eine Weiterleitung (301 oder 302) einrichten, um SEO‑Wert zu erhalten und defekte Links zu vermeiden.
- Füllen Sie website_meta_title und website_meta_description für alle öffentlichen Seiten aus — das verbessert die Auffindbarkeit in Suchmaschinen.
- Wenn Sie Seiten per API oder XML‑RPC anlegen: erstellen Sie zuerst die ir.ui.view mit type = 'qweb' und einem einzigartigen key, danach die website.page mit view_id.
Häufige Fehler
- Einen website.page‑Eintrag ohne gültige view_id anlegen. Die zugehörige View muss existieren und type = 'qweb' haben, sonst funktioniert die Seite nicht.
- URLs ohne führenden Schrägstrich verwenden. Odoo erwartet Pfade wie /kontakt, nicht kontakt.
- Das Web‑Indexing für Dankeseiten vergessen. Solche Seiten können sonst fälschlich in Suchergebnissen landen und die SEO‑Qualität senken.
- Eine Seiten‑URL ändern, ohne eine Weiterleitung einzurichten. Dadurch brechen alte Links und Suchmaschinen verlieren die Verbindung.
- Die arch einer View verändern, die zuvor im Website‑Builder editiert wurde. Das noupdate‑Flag in ir.model.data kann dazu führen, dass XML‑Änderungen nicht angewendet werden — gegebenenfalls zurücksetzen.
Fazit
Das website.page‑Modell ist der zentrale Baustein für statische Seiten in Odoo. Es verwaltet Metadaten, Pfade und Publikationsoptionen; die eigentliche HTML‑Struktur liegt in der verknüpften ir.ui.view.
Wer die Felder kennt und die Verknüpfung zu ir.ui.view versteht, kann Odoo‑Webseiten sicher konfigurieren, erweitern und integrieren. Dieses Wissen spart Zeit und vermeidet typische Fehler — sowohl für Berater als auch Entwickler.
Brauchen Sie Unterstützung bei Ihrer Odoo‑Einführung?
Dasolo unterstützt Unternehmen bei Implementierung, Anpassung und Optimierung von Odoo. Unser Fokus liegt auf API‑Integrationen und maßgeschneiderter Odoo‑Entwicklung; wir kennen die Datenarchitektur und Modelle wie website.page sehr gut.
Wenn Sie Hilfe bei Ihrer Odoo‑Implementierung, individuellen Webseiten oder Integrationen benötigen, unterstützen wir Sie gerne. Demo buchen um Ihr Projekt zu besprechen.