Innledning
I Odoo bestemmer modeller hvordan informasjon lagres i databasen. Alle forretningselementer — sider, produkter, kontakter — lever i modeller som definerer struktur og regler for disse dataene.
Å kjenne Odoo‑modeller er viktig både for utviklere og funksjonelle konsulenter. Modellene utgjør kjernen i datamodellen og styrer felt, relasjoner og den innebygde forretningslogikken.
Denne artikkelen konsentrerer seg om website.page‑modellen. Den ligger til grunn for statiske sider i Odoo‑nettsider og er relevant når du lager landingssider, holder innhold oppdatert eller kobler innhold mot andre systemer.
Hva er modellen website.page?
website.page representerer statiske nettsider i Odoo. Den er en del av Website‑appen og brukes til sider du oppretter manuelt — for eksempel «Om oss», kontaktsider eller spesiallagde landingssider.
Modellen bygger på Odoos arve‑mekanismer. Den knytter seg til ir.ui.view via _inherits, slik at hver website.page peker til en ir.ui.view som inneholder QWeb‑templaten (arch) og tilhørende metadata.
Dynamiske sider som produktkataloger eller bloggoppslag blir bygget på andre måter og behandles ikke som website.page‑poster.
Med andre ord: website.page brukes kun for statisk innhold som redigeres i nettsidebyggeren — ikke for automatisk genererte lister og feeds.
Viktige felt i modellen
Her er felt som er særlig nyttige når du jobber med website.page. Å forstå dem gjør det enklere å administrere sider, SEO og synlighet.
1. name
Type: Char. Sidens tittel. Vises i nettleserfanen, menyer og søk; verdien hentes fra den tilknyttede ir.ui.view.
2. url
Type: Char. Sidens sti i nettadressen. Skal begynne med en skråstrek, for eksempel /kontakt eller /om‑oss — det er denne stien besøkende bruker.
3. view_id
Type: Many2one (ir.ui.view). Obligatorisk. Kobler siden til QWeb‑visten som inneholder innholdet (arch) og nøkkelen. Sletter du visten, fjernes siden.
4. website_id
Type: Many2one (website). Angir hvilket nettsted sidene tilhører. I oppsett med flere nettsteder kan sider være knyttet til ett nettsted eller være delte.
5. is_published
Type: Boolean. Angir om siden er synlig for besøkende. Usynlige sider gir 404 eller blir omdirigert — nyttig for å ta sider av lufta uten å slette dem.
6. website_indexed
Type: Boolean. Styrer om søkemotorer kan indeksere siden. Sett False for takk‑sider eller interne sider du ikke vil ha i søkeresultater.
7. date_publish
Type: Datetime. Publiseringsdato. Brukes til planlagt publisering og for å vise når innholdet gikk live.
8. header_visible
Type: Boolean. Bestemmer om nettsidens topp (header) skal vises. Praktisk for landingssider eller fullskjermoppsett der du skjuler standard topp.
9. footer_visible
Type: Boolean. Bestemmer om bunntekst (footer) vises. Gir fleksibilitet for sider uten standard footer.
10. is_homepage
Type: Boolean. Beregnet felt. Sann når siden er satt som nettstedets forside. Én forside per nettsted.
11. is_visible
Type: Boolean. Beregnet. Viser om siden faktisk er synlig, basert på publiseringsstatus, dato og synlighetsregler.
12. menu_ids
Type: One2many (website.menu). Menyelementene som peker til siden. En side kan dukke opp i flere menyer eller ingen.
13. create_date
Type: Datetime. Når posten ble opprettet. Håndteres automatisk og er nyttig for revisjon og rapportering.
14. write_date
Type: Datetime. Når posten sist ble endret. Også automatisk — hjelper deg å spore oppdateringer.
15. arch
Type: Text. QWeb XML‑templaten som beskriver HTML‑strukturen og Odoo‑snippets. Ligger på den tilknyttede ir.ui.view og kan redigeres via nettsidebyggeren.
16. key
Type: Char. Unik id for visten brukt i modul‑XML og ved arv. Typisk format: modul.view_navn.
17. type
Type: Selection. Vistype. For nettsider er dette qweb. Andre visningstyper er f.eks. form, tree eller list.
18. active
Type: Boolean. Soft‑delete‑flag. Når False arkiveres posten og siden serveres ikke lenger.
19. website_meta_title
Type: Char. SEO‑metatittel. Overstyrer standard tittel i søkeresultater og er viktig for synlighet i søk.
20. website_meta_description
Type: Text. SEO‑beskrivelse. Snutten som vises i søkemotorer — hold den rundt 150–160 tegn for best visning.
21. website_meta_keywords
Type: Char. Meta‑nøkkelord. Mindre viktig i moderne SEO, men enkelte systemer bruker det. Komma‑separert.
22. header_overlay
Type: Boolean. Angir om header plasseres over innholdet. Nyttig for hero‑seksjoner hvor headeren ligger på toppen av banneret.
23. header_color
Type: Selection. Fargevalg for header: f.eks. transparent, lys eller mørk. Påvirker kontrast og lesbarhet.
24. visibility
Type: Selection. Tilgangsstyring. Valg inkluderer Offentlig, Innlogget, Begrenset gruppe eller Med passord — avgjør hvem som ser siden.
25. redirect_type
Type: Selection. Ved endring av URL bestemmer dette om det skal være 301 permanent, 302 midlertidig eller ingen omdirigering — viktig for SEO når sider flyttes.
Slik brukes modellen i forretningsprosesser
1. Landingssider og kampanjer
Markedsførere oppretter landingssider som egne website.page‑poster. Her styrer du URL, innhold og publiseringsdato — planlagt publisering bruker date_publish.
2. Bedriftssider
Sider som «Om oss», kontaktinfo, vilkår og personvern opprettes vanligvis som website.page‑poster. Oppdateres ved behov, og plassering i menyer håndteres via menu_ids.
3. Takk‑ og bekreftelsessider
Sider som «Skjema mottatt» eller «Bestilling registrert» bør ha website_indexed = False, slik at de ikke dukker opp i søkemotorer.
4. Flere nettsteder og lokalisering
I multi‑site‑oppsett avgjør website_id hvilket nettsted som viser siden. Du kan kopiere sider per nettsted for lokaliserte versjoner.
5. Beskyttet innhold og begrenset tilgang
Visibility‑feltet gjør det enkelt å lage sider kun for innloggede brukere eller bestemte grupper — nyttig for medlemsområder eller intern dokumentasjon.
Hvordan utviklere utvider modellen
Utviklere kan bygge videre på website.page med ulike mønstre, der arving av modellen er det vanligste grepet.
Modellarv
Sett _inherit = 'website.page' for å utvide funksjonalitet. Du kan legge til nye felt, overstyre metoder eller legge på valideringer. Å arve modellen i egen modul gjør vedlikehold enklere ved oppgraderinger.
Legge til felt
Definer nye felt i din arvede modell med riktig datatype: Char, Many2one, Boolean, Integer, Text eller Selection. Tenk også på website‑avhengige felt ved multi‑site.
Python‑utvidelser
Overstyr create, write eller unlink for å legge inn logikk. Husk å kalle super(). Vær forsiktig med view_id‑relasjonen og kaskadeeffekter ved sletting.
Odoo Studio
Odoo Studio er nyttig for raske endringer uten kode, men for mer kompleks funksjonalitet eller API‑drevet innhold er egne moduler mer robuste og vedlikeholdsvennlige.
Beste praksis
- Bruk URL‑vennlige slugs: unngå mellomrom og spesialtegn; bruk bindestrek for lesbarhet.
- Sett website_indexed til False for takk‑sider, bekreftelsessider og interne sider slik at de ikke indekseres.
- Når du endrer en URL, aktiver omdirigering (301 eller 302) for å bevare SEO‑verdi og unngå brutte lenker.
- Fyll ut website_meta_title og website_meta_description for alle offentlige sider for å forbedre søkesynlighet.
- Ved opprettelse via API eller XML‑RPC: opprett først ir.ui.view, deretter website.page med korrekt view_id. Sørg for at visten har type qweb og en unik key.
Vanlige feil
- Å opprette en website.page uten en gyldig view_id. Visten må eksistere og ha type qweb for at siden fungerer.
- Å bruke URLer uten innledende skråstrek. Odoo forventer stier som /kontakt, ikke kontakt.
- Å glemme å sette website_indexed på takk‑sider. De kan ellers dukke opp i søkeresultater og svekke SEO.
- Å endre en side‑URL uten omdirigering. Gamle lenker vil bryte og søkemotorenes kobling går tapt.
- Å endre arch i en view som ble redigert i nettsidebyggeren. Noupdate‑flagget i ir.model.data kan forhindre at XML‑endringer anvendes — da må det håndteres.
Oppsummering
website.page er kjernen for håndtering av statiske sider i Odoo. Den lagrer metadata, URL‑styring og publiseringsinnstillinger, mens det faktiske HTML‑innholdet ligger i den tilknyttede ir.ui.view.
Å forstå feltstrukturen og arvforholdet til ir.ui.view gir deg kontrol og fleksibilitet når du konfigurerer, tilpasser eller integrerer Odoo‑nettsider — uavhengig om du jobber funksjonelt eller teknisk.
Trenger du hjelp med Odoo‑implementasjonen din?
Dasolo hjelper bedrifter med å implementere, tilpasse og optimalisere Odoo. Vi har spisskompetanse på API‑integrasjoner og utvikling, samt dyp innsikt i Odoo‑datamodellen og modeller som website.page.
Trenger du hjelp med Odoo‑implementasjon, tilpassede nettsider eller integrasjoner, så kan vi bistå. Book en demo for å diskutere prosjektet ditt.