Divi

Divi er et visuelt design- og page-builder-system til WordPress fra Elegant Themes. Det kan bruges som Divi-tema og som Divi Builder til at bygge sider visuelt. Divi er dermed ikke et CMS i sig selv; WordPress er stadig systemet, der håndterer indhold, brugere, indlæg, medier og resten af den grundlæggende platform.

Divis idé er, at designet kan bygges direkte i en visuel editor. Du arbejder med en hierarkisk struktur af sektioner, rækker, kolonner og moduler. Et tekstmodul indeholder tekst, et billedmodul viser et billede, og andre moduler kan håndtere eksempelvis knapper, formularer, galleri og forskellige indholdstyper. Den visuelle editor viser ændringerne, mens du arbejder.

Det gør Divi velegnet til virksomheder, der ønsker et skræddersyet WordPress-layout uden at hver side skal håndkodes. Men ligesom andre page builders flytter Divi ikke de grundlæggende webdesignbeslutninger væk. Typografi, hierarki, afstande, konverteringspunkter og responsivt design skal stadig planlægges. Værktøjet gør beslutningerne nemmere at udføre; det træffer dem ikke for dig.

Divi har også en Theme Builder, som kan bruges til at opbygge templates til blandt andet header, footer, blogindlæg, kategorier, produktsider og 404-sider. Dermed kan samme visuelle builder styre både individuelle sider og de dele af sitet, som går igen på tværs af indholdstyper.

Et andet centralt element er Divi Library. Her kan moduler, rækker, sektioner og hele layouts gemmes til genbrug. Globalt eller synkroniseret indhold kan bruges flere steder, så en ændring ikke behøver udføres på hver side. Det minder om tankegangen bag et designsystem: ens elementer bør have en fælles kilde, når de faktisk skal opføre sig ens.

Divi forbindes ofte med temaet, men en praktisk vurdering bør handle om hele løsningen. Hvilke templates findes? Hvad er globalt? Hvilke moduler kommer fra Divi selv, og hvilke funktioner kommer fra andre plugins? Ligger der special-CSS eller kode i enkelte moduler? Det er den slags spørgsmål, der afgør, om sitet er let at overtage og vedligeholde.

For en virksomhed er den vigtigste fordel derfor ikke antallet af designmuligheder. Det er muligheden for at bygge et gennemgående WordPress-site, hvor indhold og layout kan redigeres visuelt, og hvor gentagne dele kan samles i templates og bibliotekselementer.

Begynd med de globale beslutninger. Definér de vigtigste farver, fonte, knapper, indholdsbredder og afstande, før du designer 25 individuelle undersider. Hvis hver side udvikler sit eget lille regelsæt, bliver Divis store frihed hurtigt til vedligeholdelsesarbejde.

Byg derefter de gentagne dele som genbrugelige elementer. Hvis den samme CTA ligger nederst på 18 sider, bør den ikke være 18 uafhængige kopier, hvis teksten og designet skal ændres samlet. Divi Library og globale elementer er netop lavet til at genbruge moduler, rækker og sektioner.

En praktisk arbejdsgang kan være:

1. Fastlæg den visuelle retning og de globale regler.
2. Byg header, footer og relevante skabeloner i Theme Builder.
3. Lav genbrugelige sektioner til CTA, kontakt, cases eller andre gentagne elementer.
4. Brug sideniveauet til det indhold, der faktisk er unikt for siden.
5. Kontrollér de responsive indstillinger på desktop, tablet og mobil.
6. Test frontend efter ændringer og opdateringer.

Divis responsive værktøjer gør det muligt at kontrollere design ved forskellige viewport-størrelser og ændre mange indstillinger pr. breakpoint. Det er nyttigt, men brug det med måde. Hvis næsten hvert modul har særlige mobilværdier, kan et simpelt layout ende med et komplekst lag af undtagelser. Før du laver en ny særregel, så undersøg om problemet kan løses i den overordnede række, kolonne eller template.

På et eksisterende site er det ofte en god idé at gennemgå Theme Builder og Divi Library før selve siderne. En header kan være styret globalt, mens en anden side har sin egen undtagelse. En CTA kan se ud som almindeligt sideindhold, men være et globalt bibliotekselement. Hvis man ikke kender strukturen, kan man enten rette det forkerte sted eller komme til at ændre 40 sider på én gang.

Hold også styr på specialkode. Divi giver mulighed for avancerede indstillinger, CSS-klasser og forskellige tilpasninger. Specialkode kan være helt rimelig, men den bør have et formål og være dokumenteret. Når tre udviklere over fem år har tilføjet hver deres CSS-fix, bliver problemet ikke Divi som værktøj; problemet bliver, at ingen længere ved, hvilke regler der gælder.

Performance bør vurderes på den færdige løsning. Cache, billedstørrelser, fontfiler, scripts, tracking, hosting og tredjepartsplugins kan være mindst lige så vigtige som builderen. Mål det faktiske site og brug blandt andet Core Web Vitals som en del af vurderingen frem for at konkludere ud fra platformnavnet alene.

Hvis du får lavet en ny hjemmeside i Divi, så aftal også hvad du selv skal kunne redigere efter lanceringen. Det er sjældent nødvendigt, at en almindelig redaktør skal kunne ændre Theme Builder, globale templates og special-CSS. En god løsning giver adgang til det relevante uden at gøre hele konstruktionen sårbar over for en lille tekstrettelse.

Ved overtagelse af et ældre Divi-site kan en teknisk oprydning være lige så værdifuld som et redesign. Et webbureau kan gennemgå templates, plugins, versionsstatus og sideopbygning og finde ud af, om det giver mening at bygge videre eller om dele bør struktureres på ny.

Forestil dig en lokal virksomhed med en Divi-hjemmeside på 50 sider. Sitet er vokset over seks år. Den oprindelige footer ligger i temaets standardområde, men senere er der kommet en anden footer i Theme Builder. Tre kampagnesider har deres egne footere, fordi en tidligere leverandør lavede undtagelser.

Samtidig findes der fem forskellige CTA-sektioner. De ligner hinanden, men telefonnummer, knaptekst og afstande er lidt forskellige. Da virksomheden får nyt telefonnummer, bliver fire af sektionerne rettet. Den femte bliver overset og ligger stadig online tre måneder senere.

I en oprydning bliver de gentagne dele kortlagt. Header og footer samles i klare Theme Builder-templates. Den primære CTA bygges som et genbrugeligt bibliotekselement, mens kampagner med reelt andre budskaber beholder deres egne lokale varianter. Der laves også et enkelt sæt designregler til knapper, typografi og afstande.

I et tænkt regneeksempel findes der 50 sider med i gennemsnit tre kopierede designsektioner. Det giver 150 steder, som potentielt kan udvikle sig forskelligt. Hvis halvdelen af dem kan erstattes af nogle få veldefinerede templates og globale elementer, falder antallet af manuelle rettesteder markant. Det er ikke en garanti for færre fejl, men strukturen gør dem langt lettere at opdage og rette.

Efter oprydningen bliver mobilen gennemgået. Flere moduler har individuelle negative marginer, som engang blev lagt ind for at få bestemte skærme til at se rigtige ud. I stedet justeres den overordnede struktur, og unødvendige undtagelser fjernes. Det giver et mere robust UI og en mere ensartet brugeroplevelse.

Det samme princip gennemgår vi i guiden om at skabe en brugervenlig hjemmeside, der fører til flere henvendelser. Builderen er et middel. Målet er stadig, at besøgende kan forstå virksomheden, finde det relevante og komme videre uden unødvendig friktion.

En klassisk faldgrube er at bygge alt lokalt. Divi gør det hurtigt at kopiere en sektion til næste side, men kopien mister forbindelsen til originalen. Når noget senere ændres, skal alle kopier findes. Brug globale eller genbrugelige elementer, når indholdet faktisk skal være fælles.

Den modsatte fejl er at gøre for meget globalt. Hvis en global sektion bruges på sider med forskellige mål, kan en lille ændring få uventede konsekvenser mange steder. Globalt indhold bør være globalt, fordi det har samme funktion og samme betydning — ikke bare fordi genbrug er teknisk muligt.

Pas også på gamle specialrettelser. Et Divi-site kan have indstillinger på modul-, kolonne-, række-, sektion- og templateniveau. Hvis du retter symptomet nederst i hierarkiet uden at forstå årsagen højere oppe, bliver næste rettelse endnu mere kompliceret.

En anden faldgrube er at skifte tema eller builder uden at undersøge afhængighederne. Divis layoutdata og moduler er en del af sidens opbygning. Et skifte til en helt anden løsning er derfor ikke det samme som at vælge et nyt farvetema. Indhold kan genbruges, men layout og særlige funktioner skal ofte bygges om eller migreres.

Endelig bør man ikke sætte lighedstegn mellem visuel editor og vedligeholdelsesfri hjemmeside. WordPress, Divi, andre plugins, PHP og servermiljø ændrer sig over tid. Opdateringer skal foretages, og kritiske sider bør testes bagefter. En visuel builder reducerer ikke behovet for backup og drift.

Divi udvikles løbende, og brugerfladen og responsive værktøjer kan ændre sig mellem generationer. Hvis du arbejder på et eksisterende site, er det derfor vigtigt at kende den konkrete Divi-version og ikke følge en gammel guide mekanisk. Dokumentationen fra Elegant Themes bør bruges som reference for den version, sitet faktisk kører.

Divi kan kombineres med et child theme, når der er behov for kodeændringer, som ikke bør ligge direkte i hovedtemaet. Det betyder ikke, at alle Divi-sites behøver et child theme, men ved mere avancerede tilpasninger kan det gøre ansvarsfordelingen tydeligere og beskytte ændringer mod temaopdateringer.

Ved overdragelse bør virksomheden have egne administratoradgange, licensoplysninger og dokumentation af Theme Builder, globale elementer og specialkode. På den måde kan en anden leverandør overtage uden først at skulle gætte sig til, hvorfor en bestemt menu kun findes på nogle sider.

Divi fungerer bedst, når sitet er bygget med få tydelige principper. Genbrug det, der skal være ens. Hold undtagelser lokale. Dokumentér specialtilpasninger. Og vurder altid løsningen ud fra brugerens oplevelse og virksomhedens mulighed for at drive den — ikke ud fra hvor mange moduler builderen tilbyder.