Slik setter du opp et enkelt testmiljø for WordPress uten å rote til produksjonssiden

Mange gjør endringer direkte på WordPress-nettstedet som allerede er publisert. Det kan fungere en stund, helt til en plugin-oppdatering eller designendring plutselig gir nedetid eller ødelagt layout.

Et eget testmiljø gir deg mulighet til å prøve nye temaer, plugins og oppdateringer i fred. Her går vi gjennom en praktisk måte å komme i gang, uten å måtte bli fullblods utvikler.

Hva er et testmiljø, og hvorfor bruke det?

Et testmiljø er en kopi av WordPress-nettstedet ditt, vanligvis skjult for vanlige besøkende. Her kan du teste oppdateringer, nye løsninger og design før du legger dem ut «på ordentlig».

Poenget er å redusere risiko: Du vil vite om en endring skaper feil, treghet eller konflikter, før kundene eller leserne dine merker det.

Velg type testmiljø: lokalt, subdomene eller staging

Det finnes flere måter å sette opp et testmiljø på, og hva som passer avhenger av hvor teknisk du vil bli og hva webhotellet ditt tilbyr.

Grov inndeling ser slik ut:

• Lokalt miljø på egen PC:Alt kjører på din maskin. Ingen ser testene dine, men du må selv håndtere opplasting til server senere.
• Subdomene:For eksempeltest.dittdomene.no. Ligger på samme webhotell som hovedsiden, men separert.
• Staging-løsning fra webhotell:Noen leverandører har egen staging-funksjon i kontrollpanelet, gjerne med «kopier til produksjon»-knapp.

Hvis webhotellet ditt tilbyr staging, er det ofte den enkleste inngangen. Hvis ikke, er subdomene en fleksibel og grei løsning for de fleste små og mellomstore nettsteder.

Slik lager du et testmiljø på subdomene

Oppsett varierer litt fra leverandør til leverandør, men prosessen har som regel disse stegene: opprett subdomene, opprett database, kopier filer og data, og beskytt testmiljøet.

Start i kontrollpanelet til webhotellet, og opprett et subdomene somstaging.dittdomene.noellertest.dittdomene.no. Noter hvilken mappe på serveren som hører til dette subdomenet.

1. Ta sikkerhetskopi av nåværende nettsted

Før du begynner å kopiere noe som helst, ta en full backup av både filer og database. Mange webhotell har innebygget backup i kontrollpanelet, eller du kan bruke en etablert backup-plugin.

Kontroller gjerne at backupen faktisk kan lastes ned eller gjenopprettes ved behov. Ikke stol blindt på at den bare eksisterer i en liste et sted.

2. Kopier WordPress-filene

Bruk FTP eller filbehandler i kontrollpanelet til å kopiere alle WordPress-filene fra hovedmappen til mappen som hører til subdomenet. Det inkludererwp-content, temaer, plugins og opplastede filer.

Hvis du har mye innhold, kan denne kopieringen ta litt tid. La den fullføre helt før du går videre.

3. Lag ny database og koble testmiljøet til den

Opprett en ny database i webhotellpanelet. Lag et nytt databasebrukernavn og passord, og noter detaljene. Deretter åpner duwp-config.phpi testmiljømappen og endrer databaseinnstillingene til å peke mot den nye databasen.

For å få en kopi av innholdet, eksporter databasen fra produksjonssiden (for eksempel via phpMyAdmin) og importer den inn i den nye databasen for testmiljøet.

Unngå at testmiljøet krangler med produksjon

Når filene og databasen er kopiert, må du sørge for at WordPress i testmiljøet vet at det bor på en annen adresse. Dette går via adresseinnstillingene i databasen.

Bruk for eksempel et verktøy i kontrollpanelet (ofte phpMyAdmin) til å oppdateresiteurloghomeiwp_options-tabellen, slik at de peker tilhttps://test.dittdomene.no.

Justér e-post og integrasjoner

Det er lurt å hindre at testmiljøet sender ut ekte nyhetsbrev, ordrebekreftelser eller andre automatiske meldinger. Sjekk e-postrelaterte plugins og integrasjoner, og vurder å deaktivere eller sette dem i «sandbox» hvis mulig.

Har du integrasjoner mot betaling, CRM eller andre systemer, bør du også sjekke om de kan settes til testmodus, slik at du ikke legger inn falske data i virkelige systemer.

Beskytt testmiljøet mot søkemotorer og nysgjerrige

Du vil vanligvis ikke at testmiljøet skal indekses i Google. En enkel start er å hake av for «Be søkemotorer om å ikke indeksere dette nettstedet» underInnstillinger > Lesingi WordPress.

I tillegg er det lurt å legge på enkel passordbeskyttelse, for eksempel med HTTP-auth via webhotellet, eller en plugin som begrenser tilgangen til innloggede personer.

Hvordan bruke testmiljøet i praksis

Poenget med testmiljøet er at det skal bli en naturlig del av arbeidsflyten, ikke et engangsprosjekt. Lag en enkel rutine for når og hvordan du bruker det.

Et typisk mønster kan være:

• Oppdater tema og plugins i testmiljøet først.
• Test sentrale funksjoner, for eksempel skjemaer, innlogging, netthandel og søk.
• Hvis alt fungerer, gjør tilsvarende oppdateringer på produksjonssiden.

Når bør du oppdatere testmiljøet?

Et testmiljø blir fort utdatert hvis du aldri synkroniserer innhold og database på nytt. Hvor ofte du bør oppdatere avhenger av hvor mye som skjer på nettstedet.

For en aktiv nettbutikk kan du vurdere hyppigere synkronisering, men da må du også ha en tydelig plan for hva som skal gå den andre veien. Som regel bør du unngå å «pushe» databasen fra test til produksjon etter at det har kommet inn ekte ordre, reservasjoner eller skjemainnsendinger.

Typiske feil og hvordan unngå dem

Én vanlig feil er å glemme at testmiljøet fortsatt peker til filer eller tjenester på produksjonssiden. Det kan gi misvisende testing, fordi du i praksis tester blanding av to miljøer.

En annen gjenganger er at noen ved et uhell jobber i feil miljø, for eksempel at innhold havner i staging i stedet for på hovedsiden. Løsningen er tydelig adressering, ulike farger i admin (via en enkel plugin) eller egne innloggingsrutiner.

Start enkelt og bygg videre ved behov

Du trenger ikke et avansert oppsett for å få stor gevinst. Et enkelt testmiljø på subdomene, med egen database, passordbeskyttelse og en enkel rutine for oppdateringer, kan spare deg for mye frustrasjon.

Etter hvert som nettstedet vokser, kan du vurdere mer avanserte oppsett, flere miljøer eller automatiserte verktøy. Men det viktigste skrittet er å slutte å teste direkte i produksjon.