Från Drupal till Middleman

anvandbart.se går på sitt tionde år, och har sedan starten använt Drupal som sitt publiceringssystem.

Drupal har alltid varit lite speciellt. Man kan säga att det är objektorienterat, men skapades i PHP innan det språket hade stöd för objekt. Drupal har därför uppfunnit sitt eget sätt att simulera samma sak, genom strikta konventioner för hur saker döpts och en härva av callbacks.

Det tog lite tid att fatta, men sedan dess har det tjänat mig väl. Flexibelt och kraftfullt.

Kanske lite för kraftfullt, insåg jag när det var dags att uppgradera till Drupal 7. Jag ägnade två dagar åt att försöka få något att fungera, men tvingades sedan att konstatera att det vuxit förbi min (erkänt begränsade) förmåga som programmerare. Det är säkert ett utmärkt system om man är proffs, men för mig hade det blivit för komplext.

Det logiska valet hade kanske varit att flytta till Wordpress. Men jag hade fått nog av PHP, som är ett inkonsekvent språk där det är lätt att göra fel och skapa svårfunna buggar.

Istället föll min blick på Middleman. Det är ett extremt back-to-basic publiceringssystem. Det saknar till exempel databas. Istället skapar man nya artiklar genom att skriva dem i sin favoriteditor och spara dem på hårddisken. Middleman tar hand om dem och gör om dem till html-sidor. Vanliga filer in, vanliga filer ut. Blixtsnabba sidor, eftersom de servas utan att något CMS eller någon databas behöver behandla och plocka samman dem. Väldigt säkert, av samma anledning.

”Movable Type” tänker kanske du som varit länge i bloggsvängen. Movable Type var ett CMS som var populärt i början av milleniet, och som även det producerade vanliga html-sidor.

Problemet med Movable Type var att varje gång man gjorde en ändring på en sida, var man tvungen att generera om sajten för att se hur det blev, något som var ganska tålamodsprövande i längden.

Det kluriga med Middleman är att mellan de extremt enkla in och ut, gömmer sig ett fullstort publiceringssystem. Men bara åtkomligt internt, för den som jobbar med sidan. Så om jag skriver på en artikel kan jag samtidigt se den växa fram i webbläsaren (och i mobilen). Publiceringssystemet är Ruby on Rails-liknande, men utan hanteringen av databas, behörighet och säkerhet, så därför mycket enklare. Det gör det möjligt att arbeta med avancerade mallar och att automatisk skapa kategori- och tidssidor såväl som helt nya sidor baserade på datafiler och externa databaser.

När jag sedan är nöjd med sidan, publicerar jag. Det är först då som html-sidorna skapas, och skickas upp till webbservern.

Foto: Feliciano Guimarães

Att jobba med Middleman är som att jobba med gamla tiders industrimaskiner. Här finns inga skyddskåpor, funktionen är rå men synlig (till skillnad från Drupal, där det ofta var snudd på omöjligt att lista ut var något hände eller hur det gjordes). Grafisk gränssnitt saknas – man styr applikationen med kommandon från terminalen. Är man inte är nöjd med hur något fungerar skriver man en bit kod (i Ruby) med en funktion som passar en bättre, och pluggar direkt in i maskineriet. Alla inställningar görs från en konfigureringsfil.

Det finns med andra ord inget insmickrande hos Middleman. Det är kraftfullt och otroligt flexibelt, man kan göra precis vad man vill – men vet man inte vad man sysslar med är risken stor att det inte fungerar.

Många funktioner kan hämtas direkt från webben. Middleman självt är lite egenskriven kod som fogar samman väl prövade komponenter. Så artiklarna kan skrivas i markdown eller textile, men även i några wikidialekter. Mallarna kan göras i erb, haml, erubis m.fl. CSS kan skrivas rått eller med Sass eller Less. Javascript med CoffeeScript. Och så vidare.

Versionshanering, av såväl sajt som artiklar, sköter man med git och sidorna laddas upp till webbservern med till exempel ftp eller rsync.

Vill man sedan bygga sin sajt responsivt finns ett flertal ramverk redan färdiga. Vill man ha även bilderna responsiva slänger man in Clowncar (och ja, jag vet att bilderna på den här sajten just nu är alldeles för stora för mobilen, men ha lite tålamod så fixar det sig).

Även funktioner kan droppas in, till exempel en blogg. Eller så kan man utnyttja att man har vanliga html-sidor, skippa sin internetleverantörs dyra databasbaserade tjänst och istället serva sidorna snabbt, pålitligt och billigt från Amazon S3.

Räcker inte detta är det relativt enkelt att leta upp ett Ruby-gem med den funktion man behöver och integrera det. Eller att skriva sin egen kod från scratch.

Själv har jag till exempel skrivit en snutt kod som gör att jag kan skriva i min favoritordbehandlare, Scrivener utan att ens behöva exportera sidorna. Middleman läser källfilen och gör webbsidan medan jag skriver.

Middleman är långt ifrån rätt verktyg för alla situationer, tvärtom är det specialiserat. Eftersom sajten inte har kontakt med någon databas, så begränsas mängden interaktivitet. Det passar en blogg men är otänkbart för en e-handelsplats. Och även om det i princip går att arbeta flera med samma blogg, så tror jag man snabbt skulle börja sakna den ordning som en databas medför.

Tveklöst kan man bygga mer avancerade webbplatser med ett traditionellt publiceringssystem. Men så länge man inte är uppe och tävlar bland de mest funktionsrika, ligger den statiska sajtens styrka i vad man får ut i förhållande till arbetsinsatsen.

En anledning att det numera ofta fungerar riktigt bra att ha statiska sidor är att många funktioner ändå flyttats bort från den egna server och till molntjänster. För kommentarer använder jag till exempel sedan länge Disqus och för statistiken Google Analytics, två javascript-baserade lösningar som fungerat bättre än Drupals inbyggda motsvarigheter.

Men för mig är det framförallt tre känslonära argument som gör att jag är nöjd med mitt byte.

• Jag älskar själv att se hur de statiska sidorna bara ”snäpper” på plats, nästan ögonblickligen. (Jag vet att även konventionella publiceringssystem kan nå samma hastighet, men det kräver en noga intrimmad cachning. Och jämfört med Drupal är det här en fartdemon.)

• Att slippa PHPs krokiga spikar och istället få jobba i Ruby är helt klart ett lyft. Likaså att få jobba i direkt kontakt med maskineriet istället för lager på lager av välvillig men ofta förvirrande abstraktion.

• Sist, men inte minst: I en databas sugs allt in i databasen, och vill man veta vad som finns där får man gå in och titta på sidor med rapporter och listor. Med Middleman har jag kvar mina textdokument och mina bilder på disk. Funktionellt är det kanske inte så stor skillnad, men det är så mycket mer tillfredsställande att kunna handskas med dem direkt – nästan som när man jobbar med på papper. Det känns helt enkelt konkretare och verkligare.