Aktiveres under fanen "Wordpress" i kontrollpanelet ditt på syse.no.
Når man aktiverer staging opprettes det en virtualhost som heter det samme som den du stager fra, men med «-staging» appended til navnet, så staging for www heter www-staging.
Det tas en kopi av alt innholdet, og det opprettes en ny database med samme innhold som den opprinnelige. Dette er en fullverdig database, men den er en extension på hoveddatabasen og er gratis.
Du kan ikke endre passord eller kvote på denne separat. Endring av kvote/passord på master-databasen synces til staging databasen.
Etter kopiering byttes connection-info i wp-config ut med den nye staging-databasen (i staging-området altså).
Staging er tradisjonelt forbundet med et par problemer vi har forsøkt å løse. Blant annet kan du tenke deg hva som skjer hvis du lager en staging-kopi av siden din, og den får en alternativ url. Da vil antakelig WordPress eller Apache redirect deg rett tilbake til den faktiske siden.
SSL er også et issue som må løses. På grunn av disse utfordringene har vi gjort det slik at staging vises på samme url som selve siden, dersom man går dit på en hemmelig url.
(Se under, den som begynner med /StagingOn/<UUID>).
https://123456-www.web.tornado-node.net/StagingOn/6028ffad-523f-4890-9183-256146d58338 (Dette er ett eksempel, din unike link finner du i kontrollpanelet på syse.no)
Når man går på denne URL’en settes det en cookie (Tornado-Staging=UUID) som gjør at Apache henter data fra staging-området istedenfor fra den opprinnelige rooten. For å komme tilbake til live-siden må denne cookien slettes, og det skjer automatisk hvis man går på url’en /StagingOff. Begge staging-control-url’ene redirecter tilbake til / for convenience.
For å indikere at man er i staging mode setter vi også en http header (Staging=Active), slik at applikasjoner også kan sjekke om de er i staging-mode hvis de trenger.
Kontrollpanelet: Etter at Staging er opprettes viser vi info om Staging-databasen, samt gir en mulighet for å kopiere Staging tilbake til Live. Da sletter vi innholdet i rooten, samt dropper/lager databasen på nytt, før vi kopierer innholdet fra staging-rooten og importerer en dump av staging-databasen. Til sist skrives connection-stringen om til å bruke master-databasen, som nå har samme innhold som staging-databasen.
Man kan deretter velge å slette staging-området og opprette det på nytt. Dette kan være aktuelt hvis man vil fortsette utviklingen senere, men basert på det faktisk kjørende innholdet på live-siten.