Uppgradering av EPiServer CMS 6 till EPiServer 7 CMS

Förutom att jag utvecklar EPiServer på Avantime, så arbetar jag på fritiden även med Stockholm Pride och deras webbplats. Den byggdes 2007 med EPiServer 5 och har genom åren successivt uppgraderats till 6 och nu till EPiServer 7 CMS.

Webbplatsen är i sig inte så avancerad så uppgraderingen innefattade inte så mycket arbete. Däremot fanns det en del saker som ändrats sedan EPiServer CMS 6 och 7. Bland annat delar av API:t som nu är föråldrad där man fått förnya sina implementationer.

Som mål hade jag att projektet inte skulle ha några varningar om att jag använder föråldrad kod i EPiServer CMS:s API. Jag ville även byta ut många av de Dynamic Content som fanns i projektet till Block.

Bakåtkompabilitet

Bland de största skillnaderna var att man i EPiServer 7 gjort plattformen mer möjlig att byta ut beståndsdelar såsom språkhantering, hantering av innehåll etc. Detta gör att man kan göra koden mer testbar. För större system hjälper tester att säkerställa att man vid nyutveckling och underhåll inte råkar ha sönder befintlig funktionalitet.

Trots denna omarbetning har EPiServer lagt ner mycket arbete så att det ska gå smidigt att uppgradera från EPiServer CMS 6 till 7 så att man inte gjort samma misstag som vid skiftet från EPiServer 4 till 5.

Har man en webbplats på EPiServer 5 kan man utan större bekymmer uppgradera från 5 till 6, för att sedan lyfta upp till EPiServer 7. Vad man bör tänka på är att beroende på hur komplex webbplatsen är så kan det alltid dyka upp bekymmer.

Har man en webbplats på EPiServer 4 är det bästa alternativet däremot att bygga en ny webbplats på EPiServer 7 och undersöka hur mycket av design och bakomliggande logik som går att återanvända.

Vid en uppgradering från EPiServer 6 finns de flesta gamla funktionerna kvar för vara bakåtkompatibelt.

Exempevis finns LanguageManager.Instance.Translate(“/xPath”) kvar och går under ytan till den nya funktionen LocalizationService.Current.GetString(“/xPath”).

För att förbereda sig för den dagen de plockas bort kan det vara bra att kapa mellanhanden och gå mot de nya funktionerna på en gång.

Det som lagras i EPiServer är inte bara sidor

Länge har konceptet varit att en sida i EPiServer inte måste vara en sida på webbplatsen som en besökare surfar till. Ett återkommande exempel är att kommentarer till en sida eller inlägg i ett klotterplank lagras ner som undersidor till en sida i trädstrukturen.

För att det ska bli mer tydligt har då EPiServer bytt ut nästan alla implementationer där man refererar innehållet som Page till att istället använde begreppet Content.

PageReference och PageData finns fortfarande kvar men strukturen har blivit att dessa är subdefinitioner av ContentReference och ContentData. PageReference och PageData används alltså då man faktiskt menar en sida som en besökare surfar till.

De vanligaste formerna av Content är sidor och block men även mapparna där man bygger upp strukturen för block.

Block

Att lägga in moduler, puffar, banners (kärt barn har många namn) har alltid varit en historia i sig. EPiServer Composer är ett tillägg som har levt väldigt länge men har ibland varit väldigt omständigt att arbeta med. Många EPiServer partners har byggt sin egna modulhantering och de flesta bygger ofta på samma sätt.

Genom EPiServer CMS 6 kom Dynamic Content som tillät redaktörer att lägga in innehåll med egen presentation och logik i brödtext. Men för en webbplats som har många Dynamic Content kan det också bli väldigt omständigt då det inte finns något bra sätt att hantera listan som redaktören kan välja från samt att en Dynamic Content inte är återanvändbar.

En av de stora nyheterna i EPiServer 7 CMS är då Block som generellt sett är en gruppering av egenskaper. Ett block kan antingen läggas in på en sidtyp och redigeras tillsammans med de övriga egenskaperna på sidan. Dessutom kan ett block skapas separat och läggas till på sidan genom en egenskapstypen ContentArea.

Då presentationen av både Block och Dynamic Content består av User Controls i .ascx-filer kan man relativt enkelt konvertera logiken för Dynamic Content till Block utan att behöva programmera om hur de ska visas upp. Detta beror då självklart på hur komplicerat leverantören har byggt webbplatsens Dynamic Content.

Däremot är konverteringen av innehållet av Dynamic Content hyffsat klurigt så för att minska risken att något går fel skulle jag rekommendera att redaktören själv migrerar innehållet.

Sammanfattning

Själva uppgraderingen av Stockholm Pride har totalt tagit runt en till två veckor för en person. Större delen av tiden har gått till att ta sig förbi hinder samt att undersöka vilka skillnader som finns i EPiServer 7 och hur man ska bemöta dessa.

Det finns många nya tekniska leksaker som kan förenkla för redaktören jämfört med vad som fanns i EPiServer 7 så som hur man i EPiServer 7 arbetar med anpassade Egenskaper på sidtyper eller hur man kan använda sig av “Gadgets” i redaktörsgränsnittet. Ett gott samarbete med redaktören i vilka förändringar man tänkt genomföra och vad man vill erbjuda vid en uppgradering.

En av nyheterna i EPiServer 7 är att man som utvecklare kan definiera sidtyper genom kod liknande hur man gör med PageTypeBuilder. Detta underlättar för att ge utvecklarna en blick över webbplatsens sidtyper samt minskar att man missar något vid driftsättningar. Därför gick kvällarna till att justera Erik Nordins funktion för att skapa klasser som genererar sidtyper så att den genererar kod för EPiServer 7 istället för Joel Abrahamssons verktyg PageTypeBuilder. Läs mer om detta på min egna blogg.

Som sagt är webbplatsen rätt grundläggande och använder sig inte av EPiServers mer avancerade funktioner så som PageProviders eller liknande och jag har ännu inte kontrollerat vilka skillnader det skulle kunna röra sig om, om man uppgraderar en sådan webbplats.

Alf Nilsson, utvecklare