Jag har en sida under utveckling där jag använder Drupal som CMS. Jag har hållit på med den sedan 2005 tror jag och den var klar att läggas ut med fin bild på Oliver som nyfödd någon gång runt 2006. Då kom det en uppgradering från Drupal 5 till Drupal 6 så jag satte mig och lekte med den uppgraderingen samtidigt som jag funderade på att ändra inriktningen lite på sidan. Jag insåg att alla roligt funktioner jag lagt till kanske inte var helt relevanta och att jag kanske borde lägga till några andra istället. Jag var faktiskt riktigt nöjd med hur det blev!!! Vid det laget hade jag börjat jobba skift, som sagt fått en ny bebis och började forskarstudier så hemsidan blev lite lagd åt sidan.

Så blev jag sjuk 2010. Jag vet att jag satt lite med den då, ville få till den så att jag kunde lägga ut den men jag orkade inte. Tappade koncentrationen och minnet. Det var ingen idé att börja eftersom jag inte kom ihåg var jag slutade. Det kan vara fatalt när man jobbar med CMSer. Att det kommer att krångla får man nästan räkna med, särskilt om man försöker sig på genvägar! Håller man inte reda på vad man gör eller hur långt man kommit så kan det bara sluta i katastrof.

Häromdagen kände jag i alla fall att jag ville testa att uppgradera den gamla dammiga hemsidan, jag tror jag kan klara det nu. Nu har det dessutom funnits en version 7 av Drupal ett tag, så pass länge att den kan antas vara hyggligt stabil och värd att använda även för den som inte är så hugad att peta en massa php (i ärlighetens namn krävs det en del kunskap i php och diverse skript för att man alls ska ge sig på Drupal enligt min erfarenhet även om de försöker göra den allt mer intuitiv och användarvänlig). Drupals egen upgrade.txt-fil har en mycket bra steg-för-steg-instruktion för den som vill uppgradera från D6 till D7.

Uppdatera moduler

Det första man måste göra är att uppdatera alla moduler till senaste 6.x-versionen. Det gick väldigt lätt! Förut har det kunnat krångla om man missat någon detalj. Nu var det bara att byta ut gamla moduler mot nya och köra uppdateringsskriptet för varje ny modul.

Gallra i moduler

Sedan kan man, om man vill, kolla vilka moduler som finns för D7 och avgöra om det är värt en uppgradering. Flera vanliga tilläggsmoduler finns nu i kärnan och dessa kan tas bort på en gång. ”Sites”-mappen kan man i stort sett spara orörd, åtminstone när det gäller moduler, de kan vara bra att ha kvar så att man ser vilka det var man använder. Ett alternativ är att göra skärmdumpar eller skriva ner en lista över moduler och inställningar.

När alla moduler är uppdaterade ska alla utom kärnmodulerna avaktiveras. Är det några man inte vill använda längre är det ett bra tillfälle att avinstallera dem och radera filerna nu. En del rekommenderar att tilläggsmodulerna raderas från filbiblioteket och att man bara spar det som finns i databasen men jag upptäckte att det är bra att ha kvar filerna eftersom de visas i modullistan så man ser vilka som behöver uppgraderas senare.

CKEditor kom jag fram till bör avinstalleras INNAN uppgraderingen eftersom det inte går efteråt och vid uppgradering från D6 till D7 måste man göra en ominstallation. Notera eventuellt inställningar först!

Gallra i teman

Man måste byta tema till Garland innan uppgraderingen! D7 har helt andra kärnteman än D6 och det är bara Garland som finns kvar. Jag hade en modifierad version av Garland (med bebisen på) som sparade bilder och färgscheman lite varstans så det var inte bara att byta till Garland utan jag var tvungen att ändra färginställningar för temat innan Drupal fattade att jag inte använde mitt egenjusterade version. Det tog några försök innan jag kom på det! Då är man tacksam för bra backuper gjord i rätt tid.

Teman som bygger på Garland kan ha en mapp som heter color i mappen där uppladdade filer sparas. Den måste tas bort för att Drupal ska förstå att det inställningarna från det egna temat inte gäller. Det kan vara lite trixigt, men det går om man byter tema fram och tillbaks och ändrar färginställningarna. Då fattar den till slut.

Backup

Gör en backup av både filbibliotek och databas! Det bästa är om man gör backuper med jämna mellanrum när man sedan uppgraderar tilläggsmoduler. Ju oftare desto mindre behöver man göra om – samtidigt som det finns en risk att det blir rörigt om man inte märker upp versionera noga!

Följ instruktionerna i UPGRADE.txt

Om man följer instruktionerna noga är det inga problem! Slarvar man eller inte läser så noga kan det däremot bli det.

.htaccess och robots.txt kan vara anpassade, de måste bytas ut men behöver kanske ändras på samma sätt som i D6. Det tog några försök innan jag kom på att det berodde på det när jag fick vita sidor överallt utom på förstasidan. När jag avkommenterat
RewriteBase /
fungerade det igen. Det beror på att jag använder mig av subdomäner och då behöver man tala om att Drupal ska se sin egen root som den verkliga rooten.

Kom ihåg att ändra till TRUE i settings.php på raden
107 $update_free_access = FALSE;
om du inte loggat in som admin av någon anledning. Kom ihåg att byta tillbaka när du är klar!

Gör en ny backup

När du uppgraderat kärnan kan det vara bra att göra en ny backup om det gått bra så här långt.

Teckenkodning i databasen

Minns inte när (och det är här det egentligen är bra med backuper så att man kan gå tillbaka) men ganska snart fick jag felmeddelandet
Notice: unserialize() [function.unserialize]: Error at offset 14 of 15 bytes in variable_initialize() (line 916 of /min sökväg/includes/bootstrap.inc)
Efter att ha sökt på nätet förstod jag att det kan bli krockar i teckenkodningen i databasen, om man till exempel har en kodning på databasen från början men råkar få en annan vid uppdateringen av kärna och/eller tilläggsmoduler så kan man få det felmeddelandet. Ibland kan man se var det blir fel genom att åäö och andra specialtecken ser konstiga ut, antingen på sidan eller i databasen. Mina gamla, ouppgraderade tabeller var kodade latin1_swedish_ci medan de nya fick utf8_general_ci. I settings.php kan man ställa in collation och ändra till den teckenkodning man föredrar. Jag har gjort ändringen men inte sett att det fungerar än. Tänkte installera några fler moduler för att se om felmeddelandena försvinner eller om de blir värre.

Ett annat spår är att tabellen ”variable” är problemet, att variabler (BLOBs) för gamla, oanvända, moduler och teman plötsligt spökar. Jag testade att ta bort några rader för teman jag absolut inte använder men märkte ingen skillnad. Kan hända att moduler som inte uppgraderats ställer till det så jag väntar med att göra något åt det tills vidare. I värsta fall får jag börja om med min backup.

Återkommer med resultat.

Uppgradera tilläggsmoduler

Om du sparat alla gamla moduler i /sites/all/modules (eller var du nu har dem) så kan du gå till modul-sidan och uppgradera dem en och en. Radera de gamla D6-modulfilerna innan du kopierar upp den nya versionen så det inte blir något skräp kvar som kan störa. Ta dem en och en, ibland finns det beroenden som gör att man måste hoppa lite, men gör det metodiskt. Kolla inställningarna för varje modul och testa så att de fungerar. Jag har inte hunnit kontrollera alla moduler än, men har hittills inte stött på några större problem.

CCK

CCK är ett kapitel för sig. Vissa av dess moduler ingår nu i kärnan så att man inte behöver uppgradera dem. Andra måste uppgraderas. Till hjälp finns det en uppgraderingsmodul för CCK i CCK-paketet. När man går till admin-sidan för uppgradering av CCK-fält är alla fält uppdelade i tre kategorier: Sådana som går att uppgradera, sådana som är uppgraderade och sådana som inte går att uppgradera. Går de att uppgradera är det bara att klicka i rutan och uppgradera, sedan hamnar de i listan över uppgraderade fält. Om de inte går att uppgradera står det (oftast) vilken modul som krävs för uppgradering, när den väl är installerad flyttas fälten upp till sådana som går att uppgradera, så är det bara att köra proceduren igen.

Views

Jag har inte riktigt kommit dit än, misstänker att det är en historia i sig. Det har varit så tidigare i alla fall. Återkommer.

Relaterade bilder: