Konvertering af indhold til Drupal

Der findes en hoben vejledninger og støttemoduler til at hjælpe med at hente indhold ind i Drupal. Konvertering fra ældre versioner af Drupal selv:
Drupal 5 -> Drupal 6 -> Drupal 7 -> Drupal 8
Der kan også konverteres fra andre platforme:
Konvertering fra Wordpress til Drupal.
Konvertering fra PHPbb til Drupal.
Konvertering fra Joomla til Drupal.
Konvertering fra Typo3 til Drupal
Konvertering fra allehånde andre datakilder eller Content Management Systemer til Drupal.

Noget sker med programmer eller moduler, der er skræddersyede til den bestemte konvertering, mens andre som f.eks. Drupals Migrate-modul er do-it-all-moduler, som kan håndtere en kolossal masse formater og kilder gennem et avanceret web-interface og en sindssyg masse indstillinger, konverterings- og rollback-funktioner.
Vores erfaring er at det er forbavsende besværligt og krævende at bruge disse køreklare systemer, og at resultatet ikke nødvendigvis bliver særligt godt.
Samtidig har den manuelle konvertering den fordel at der kan indbygges alle mulige former for filtre, der kan luge fejl ud, rette links, genoprette forbindelser til billeder, rette tegnsætsproblemer og meget andet, således at det konverterede kan blive bedre end kilden.

Alle kilder er forskellige <

Problemet er at alle kilder er forskellige. Ikke engang tidligere versioner af Drupal er så ensartede at overførslen med held kan automatiseres med generelle værktøjer, der kan styres pænt fra et webinterface.
Selv ret simple Wordpress-sites med en ganske enkel struktur og et begrænset omfang, bliver fanget i problemer med tegnsæt, sprog, rettigheder, roller, specielle felter, tilknyttede filer, billeder og masser af andre næsten uforudsigelige forhold, som man ikke kan forlange at et færdigt script kan håndtere.
Og bliver det blot lidt avanceret med mange specielle felter, mange typer indhold og brugere, avancerede rettigheder og den slags, så vælter læsset på et tidspunkt hvis man bruger de færdige funktioner.

Drupal til Drupal <

At konvertere Drupal til Drupal, fx Drupal 5 til Drupal 7, er forholdsvis nemt. Databasestrukturen er kendt og ret veldefineret, der er et veludviklet API til Drupal 7 og stort set alle elementer fra Drupal 5 eller 6 kan ret direkte overføres til Drupal 7 – og endda ofte blive bedre i processen. Drupal 8 er en smule anderledes, men der kan stadig laves en ret direkte overførsel, næsten 1:1.
Man kan uden problemer opsætte to parallelle databaser, der kan tilgås fra den modtagende Drupal 7- eller 8-installation, og dermed holde al kode inde i Drupals økosystem med adgang til Drupals API, entity-system, brugerstyring, filhåndtering osv.

Andre MySQL-systemer til Drupal <

Har man sine data i Wordpress, Joomla, Typo3 eller andre MySQL-baserede systemer, gælder det samme for databaserne: de kan leve side om side på en server, så Drupal kan læse direkte i dem under konverteringen. Desuden er de veldefinerede og nogenlunde fornuftigt struktureret, så man kan finde hoved og hale i dem uden at skulle splitte dem helt ad.
Datastrukturerne er forskellige i afgiver- og modtagersystem, og indholdet kan ikke nødvendigvis overføres 1:1, men skal tilpasses og ”oversættes” mellem de to systemer, og måske splittes op eller slås sammen på forskellige måder.
Men i langt de fleste tilfælde kan næsten alt indhold føres automatisk over til Drupal.

Andre databaser til Drupal <

Hvis vi bevæger os udenfor MySQL og arbejder med MSSQL-databaser, MS Access, Oracle eller andet, så skal der sikkert to databaseservere til. Det er muligt at sætte sin PHP og sin Drupal op så den kan læse i begge databaser – en ekstern og Drupals egen – men vi anbefaler normalt at man forsøger at overføre den eksterne database til en intern MySQL-database. Det gør opgaven meget lettere.
Overførslen til MySQL er ikke nødvendigvis nem, men på mange servere kan man sætte en ODBC-forbindelse op til en ekstern databaseserver og ved hjælp af forskellige databaseklienter eller -værktøjer trække data ind i en lokal MySQL udefra.
Det er hverken sjovt eller effektivt, men det er muligt.
En del af processen er at finde strukturen i kildedata. Måske har man et schema. Måske skal man selv rode sig frem til det. Måske har man adgang til den kode, der læste og skrev i databasen, typisk ASP eller .net, og så kan man måske reverse engineere datastrukturerne derfra.
Som sagt: det er ikke sjovt, det er ikke effektivt, men nogle gange er det den eneste løsning.

En skraber <

En skraber (scraper) er en løsning, der nogle gange kan være mere effektiv. En skraber gør det som ordet antyder: den skraber. Den tager synlige og usynlige data fra den gamle hjemmeside. Det sker simpelthen ved at de færdige sider læses og fortolkes over i nogle datastrukturer, der kan gemmes i en database.
Fordelen er, at alle hjemmesider kan skrabes, blot der er adgang til dem via en browser. Ulempen er, at mange sider er inkonsistente og dårligt opmærkede, og så bliver kvaliteten af de læste data ikke særligt god. En anden ulempe er, at interne data, f.eks. brugerrettigheder, interne links, skjulte felter og meget andet, ikke kan læses fordi det ikke kan ses ved at browse.
Skraberen kræver også specialprogrammering, men kan laves så den kan læse næsten perfekte data fra en hjemmeside, som er homogen, men ellers kan være svær at konvertere.
Dog kommer skraberen let til kort hvis der er meget stor variation i sidetyper og indhold og struktur på de enkelte sider. Det kan også være besværligt eller umuligt at skrabe data bag adgangskoder, fx. data fra intranet eller oplysninger om brugere, såsom brugerprofiler. Nogle gange er det muligt, mange gange er det ikke.

Manuel overførsel <

Det er ofte et værdigt alternativ at lave en simpel manuel kopiering. Hvis data er for inkonsistente eller skal igennem en større omstrukturering eller redigering alligevel, så kan det måske betale sig simpelthen at kopiere og indsætte, lave de nødvendige rettelser og gemme i det nye system.
Opgaven kan mange gange løses af "studentermedarbejdere", og kræver ikke nødvendigvis et dybdegående kendskab til indholdet, men blot disciplin og gode redigeringsevner.
Fordelen er at der kommer et menneskeligt øje på alt indhold, der konverteres.
Ulempen er at det kan tage tid og være kedeligt. Ofte er denne tid dog billigere end specialudvikling, og den endelige kvalitet af det konverterede kan blive bedre.

Kvalitetsforbedring <

Uanset om man bruger automatisk eller manuel konvertering, kan processen være en kærkommen lejlighed til at få ryddet op.
Vores erfaring er, at rigtigt mange hjemmesider rummer masser af fejl i tegnsæt, bogstavering, opmærkning, links, billedplacering, adressefelter og meget andet.
I processen med at konvertere kan man let programmere så rutiner, der retter disse fejl, og er de for komplekse kan man finde dem og lave en liste, som så kan gås igennem manuelt.

Brugere og rettigheder <

Hvis man har en stor brugerbase, så skal brugerne gerne med over. Adgangskoder kan ofte tages med, men i de bedst lavede systemer er det (heldigvis) ikke muligt. Adgangskoder bør i princippet aldrig kunne kopieres.
Mellem Drupal-versioner kan det gøres, men kun fordi nyere versioner af Drupal tillader at man logger ind med funktioner fra de tidligere versioner. Man kan med andre ord ikke se eller kopiere adgangskoderne, men man kan validere en gammel adgangskode med gammel teknologi, og dermed lukke gamle brugere ind.
Andre felter, såsom brugerprofiler, adresser, billeder og andet kan overføres til nyere Drupal-versioner uden problemer.

Noder og felter <

Drupal arbejder med indholdstyper og meget ofte med felter, der er lavet til formålet. I ældre versioner af systemet var dette en smule klodset opbygget, men i de seneste - Drupal 7 og 8 - er der et velstruktureret og veldokumenteret entity- og feltsystem, som der kan arbejdes direkte med via et API.
Andre kilder arbejder med lignende felt-baserede databasestrukturer.
Det nemmeste, hurtigste og bedste er i langt de fleste tilfælde at oprette den nye indholdsstruktur i det nye system, og så lave en håndkodet overførsel af data felt for felt. Dette sikrer kvalitet og konsistens i de enkelte felter, og giver mulighed for at lave en stram styring i konverteringen, filtrering, konvertering af tegnsæt, normalisering af felter og meget andet.
Ofte er de konverterede data bedre end kilden, selv efter en automatisk konvertering.

Billeder og andre filer <

Alle filer kan overføres og tilføjes til den nye Drupal. Hvis der er behov, kan de blot ligge på serveren og links fra artikler og andet indhold kan sikres gennem symlinks på serveren eller tilretning af henvisningerne i indholdet i forbindelse med konverteringen.
Filer, der har været styret af det gamle CMS, skal selvfølgelig styres af Drupal i det nye, og kan direkte overføres både med metadata og de fysiske filer. Adgangskontrol til filerne kan ofte bibeholdes 100% som den var, eller tilrettes og blive endnu bedre i det nye system.

Views <

Drupal-udviklere bruger meget ofte Views-modulet til at lave forskellige sider og mange Drupal-sites bruger Views. De kan også overføres til en ny Drupal.
Det bedste og nemmeste er simpelthen at lave dem igen. Man skaber dem simpelthen fra bunden med udgangspunkt i det gamle sites Views. Man kan bruge Features, som er et modul til håndtering af bl.a. Views som filer, men straffen ved at gøre det på den måde er en øget kompleksitet, afhængighed af Features og ofte en ringere kvalitet og konsistens i de færdigkonverterede Views.
Den håndholdte opbygning og konvertering sikrer kvalitet og giver samtidig anledning til at optimere og modernisere sine Views.

Menuer <

De genopbygges simpelthen manuelt. Hvis det ikke er overkommeligt, er de for komplekse, og bør alligevel forsimples i forbindelse med konverteringen. Der er meget få sites som har behov for så komplekse menuer at en automatisk konvertering giver mening.
Det samme kan siges om blokke og Panels. Disse elementer bruges til at opbygge sidestrukturen, og vil formodentlig alligevel skulle laves om i forbindelse med en konvertering. Ofte introducerer man alligevel et nyt tema med ny regioner og nyt layout, og så kan der alligevel ikke laves en direkte import.

Custom-moduler <

Drupal-moduler, der er udviklet specielt til det gamle site, skal opgraderes eller måske erstattes af contrib-moduler. Mange funktioner, som ikke fandtes, er nu lavet som moduler, der kan hentes og aktiveres og dække de behov, som specialudviklet kode lavede før.
Skal et modul med over, er en opgradering et teknisk krav fordi kodebasen er ændret, men også ønskværdig fordi det giver anledning til en opstramning af koden, effektivisering, bedre brug af abstraktionslag og API'er osv.

URL'er <

Vi har sagt det før: bevaring af de gamle URL'er er en del af enhver konvertering til et nyt system. Det har vi skrevet en hel artikel om.
Det er selvfølgelig også en del af enhver konverteringsproces.