Alle

Min mor var maler og underviste en tid på teknisk skole. Hun morede sig altid over at nogle af eleverne - altid drengene - brugte mere tid på at lede efter nye måder at gøre tingene på end på at lære de rigtige teknikker til bunds. Personligt tror jeg jo, at dovenskaben er den væsentligste drivkraft for mennesket - at dovenskab er lige så vigtig som intelligens og faglig dygtighed. For ud af dovenskaben vokser kreativiteten... med mellemrum.

Ovenstående omgang lommefilosofi skriver jeg, fordi jeg nu igen, igen, igen sidder og skriver kravspecifikation på et site, som hvad funktionalitet angår ligner mange andre.

Kravspecifikationen er principielt nødvendig, fordi uden den kan udviklingshus og designer ikke give et prisoverslag eller et bindende tilbud, og kunden har ikke nogen leveringssikkerhed. Problemet er bare, at utrolig meget af den information man (som regel) putter i en kravspec er overflødig - og endda i ikke så få tilfælde skadelig, når man bygger et site på en platform som Drupal.

Kunsten er at økonomisere med detaljerne - for ofte risikerer man at beskrive funktionaliteter, som allerede findes i nært beslægtede former i form af moduler eller som lynhurtigt kan fremtrylles med Views, Rules, Pagemanager m.m. - vel at mærke hvis beskrivelsen tager udgangspunkt i den måde, Drupal fungerer på.

Med mindre man holder sig til meget generelle formuleringer og overlader meget til udviklernes fortolkning, er det derfor nødvendigt at kende Drupal godt, før man kan skrive en god kravspec. Derfor er det en rigtig dum ide at kaste sig ud i arbejdet, før man har brugt noget tid på at lære Drupal at kende.

I den bedste af alle verdener ville udviklingshusene være markant bedre til at hjælpe i specifikationsprocessen. Jeg savner skabeloner, hvor kernefunktionalitet er beskrevet i forvejen og hvor de mange spørgsmål, der skal tages stilling til er grupperet i nødvendige, vigtige og mulige. Hvor man for eksempel guides gennem processen med at definere roller, indholdstyper, menuer og taksonomier på en overskuelig måde. Udviklingshuset kunne sagtens begrænse valgmulighederne på forhånd og på den måde få en strømlinet proces - en fordel når man skal give et prisoverslag.

Det er naturligvis ikke alle sites, der passer i en skabelon. Men inden for særlige kategorier af sites - medier blandt andre - giver det ingen mening at starte på første linje hver gang.

Jeg er involveret i en række projekter, hvor jeg er pennefører på projektbeskrivelse og kravspecifikation og vil forsøge i løbet af de kommende måneder at uddrage nogle best practises som måske i samarbejde med et udviklingshus kunne lede til en strømlinet specifikationsproces.

Stay tuned.

• kravspecifikation

The European Drupal Design Camp have now officially changed its name to "Frontend United"
This time its gonna be the epic city of Amsterdam, that will follow up the last 2 camps in Berlin & Prague
If you take Amsterdam add a little Drupal & put some Frontend Love on top - What can then possible go wrong?

read more

Hello IE7 it was nice knowing you - but Enough is enough so now from 2012 me or my company geek Royale wont support ie7 for clients unless they are willing to pay for that "extra service".

read more

Drupal bliver jo kaldt et CMS - et content management system.

Men reelt er Drupal (som hovedregel) en webpubliceringsplatform - som dermed naturligvis også kan føde html til mobiler og tablets.

Den oprindelig grandiose ide med CMS er jo, at man gemmer alt sit indhold ét sted - i en database - og så ved hjælp af CMS'et distribuerer indholdet ud til de platforme, hvor det skal bruges - inklusive platforme, der indgår i arbejdsflowet (InDesign mm). Udover internettet handler det i særlig grad om, at indhold også ofte skal bruges på print.

Der findes en række systemer, som rent faktisk er CMS'er i den store betydning af ordet. Problemet er, at de typisk ikke er lige så gode til webpublicering som Drupal.

Heldigvis har leverandørerne af disse systemer selv indset problemet, så de nu er begyndt at spille sammen med Drupal og andre webpubliceringssystemer. De nyeste udgaver af de store "redaktionelle systemer" er relativt åbne og kan integreres noget mere smertefrit med andre systemer, end tilfældet var tidligere.

De problemstillinger har jeg helt inde på livet nu i forbindelse med et par spændende projekter, jeg er involveret i. Jeg har ikke tidligere været voldsomt imponeret over de redaktionelle systemer, man for eksempel bruger på dagbladene. Brugervenligheden har ofte været for dårlig, designet uindbydende og softwaren for ustabil. Derfor er det sjovt for mig nu at researche på, hvad der er sket i de senere år, hvor der helt klart er sket et kvantespring. Systemerne er stadig - efetr min vurdering - langt fra perfekte. Jeg har ikke set systemer, som får underkæben til at falde. Men vi er på vej - og integration med tredjeparts webpubliceringssystemer er et stort skridt i den rigtige retning.

Der er imidlertid også folk rundt omkring i verden, som begynder at bruge Drupal som "grandiost" CMS, som også styrer planlægning og workflow, når det gælder print.

Men det er en anden historie...

• redaktionelle systemer

Jeg drikker så meget Drupal-kaffe, at jeg har svært ved at sove om natten.

Gennem de seneste uger har jeg besøgt en række virksomheder, organisationer og udviklingshuse, og jeg har mailet med endnu flere - og alligevel føler jeg, at jeg stadig har meget at lære, før jeg kan sige, at jeg har det fulde overblik over den danske Drupal-scene.

I dag drak jeg kaffe med Peter Bruhn hos FDM, som med Peters ord måske har verdens mest komplicerede Drupal-installation kørende. Jeg ved ikke, om det er en overdrivelse, men der er i hvert fald tale om en løsning med mange avancerede integrationer. FDM har stor intern kompetence, og de har desuden brugt Propeople som ekstern leverandør.

Forleden var jeg til kaffe hos Morten Gade hos FDB - som også gennem den senere tid er gået Drupal-vejen - med Reload som dansepartner.

Jeg har også været til kaffe hos Bo Juni (Advice Digital, Eksponent, Obrigado - hvoraf sidstnævnte laver Drupal-løsninger) og hos Sune Toft og Simon Kampmann hos Headnet.

Jeg er samtidig selv blevet involveret i et par større Drupal-projekter, som skydes i gang for alvor i løbet af næste uge - jeg håber at kunne skrive meget mere om dem her på bloggen, hvor jeg også hen ad vejen fortæller mere om, hvad jeg lærte på kaffemøderne.

Jeg har også været  kontakt med en række mindre Drupal-huse rundt om i landet. Folk som jeg ikke tidligere havde hørt om, men som laver glimrende løsninger. Dem må jeg også se at få præsenteret ved lejlighed. Stay tuned.

• Kaffe
• projekter

• FDM
• Propeople
• FDB
• Reload

• Peter Bruhn
• Morten Gade

Drupal er født med en fingranuleret rettighedsstyring baseret på roller.

Man kan oprette så mange brugerroller man vil og derefter tildele de forskellige roller relevante rettigheder.

Når man opretter en ny bruger, kan man så tildele vedkommende én eller flere roller med tilhørende rettigheder.

På et mediesite kunne man på redaktionen for eksempel have tre forskellige roller: administratorer som får adgang til alt, redaktører som får adgang til at oprette og redigere alt indhold, og journalister som kun kan oprette og redigere egne artikler.

Hver gang man tilføjer indholdstyper eller anden ny funktionalitet giver Drupal mulighed for at begrænse tilgangen til den til udvalgte roller.

Det er altsammen i teorien fantastisk - men det kræver omtanke i planlægningsfasen at gennemføre en stringent brugerstyring - også selvom værktøjerne principielt er i orden. Og igen skal man være pragmatisk - vil man vedligeholde 27 forskellige brugerroller for at sikre sig mod misbrug og nedbrud - eller vil man hellere give adgang til for meget end for lidt og stole på sine brugere.

I dagligdagen kan en for restriktiv opbygget brugerstyring give problemer. Det er for eksempel et irritationsmoment, hvis den som opdager en fejl, ikke selv er i stand til at rette den. Derfor ender det i små organisationer ofte med, at de fleste får adgang til det meste, hvilket heller ikke er optimalt - det øger risikoen for at nogen klokker i det og for at ingen kan huske, hvorfor og hvordan bestemte indstillinger er sat, som de er. Generelt sikrer en kombination af grundig uddannelse, logik og pragmatisme de bedste løsninger, men det er ikke en let øvelse.

I større organisationer er man tvunget til at tænke i hierarkiske roller, som ofte udspringer mere eller mindre naturligt af organisationens workflow (mere om workflow i et senere indlæg).

• brugerstyring
• Introduktion til Drupal

Sometimes you get a really good question like: "Hey morten can you come and speak about some cool stuff at Drupalcamp Stockholm" see if theres a thing I can do & do it kinda okay - then its talking for days about cool stuff - The coolest stuff imho in the drupal world is offcourse Display Suite - yup its not the mothership its epic cool 24-7-365!

read more

Drupal har fantastisk godt fat i den danske mediebranche - og det handler ikke kun om store forkromede løsninger a la Berlingske og (nu også snart) TV 2. I Brande midt på den jyske hede sidder Tommy Styrbæk og laver Drupal-løsninger i den anden ende af medieskalaen. Han har gennem sit firma TS Grafisk Pro bygget brandebladet.dk på Drupal (6) og er nu i gang med websites til flere andre ugeaviser bygget på den samme løsning.

Jeg spurgte ham, hvilke fordele han ser ved Drupal for netop ugeaviser.

"En af de helt store fordele en lokal ugeavis får ved at vælge Drupal, må helt sikkert være systemets store fleksibilitet og skaleringsmuligheder.

Mange lokale ugeaviser er slet ikke på nettet endnu, eller også har de har kun deres avis liggende som e-paper. Drupal's fleksibilitet giver disse ugeaviser mulighed for at starte med en simpel løsning og så skalere den op senere uden at skifte platform. Jeg kalder det en fremtidssikret webløsning...

En anden fordel ved Drupal er brugervenligheden. For backend/administrationsdelen kan skræddersyes helt efter ønsker og behov, så de mange daglige opdateringer på sitet kan foregå hurtigt og let. Faktisk er det muligt at sammensætte en løsning, så journalister kan lægge f.eks. nyheder på sitet ved at sende en email fra deres mobiltelefon, når de er "ude i marken"."

Og Det er også en fordel for de små, at de store medier har valgt Drupal, mener Tommy Styrbæk.

"Kigger man på den hurtigt voksende liste over hjemmesider, som kører på Drupal, vil man se, at rigtig mange af dem tilhører medierne f.eks. Berlingske, Årshus Stiftidende, TV 2, B.T. osv. Så man kan vel på en måde sige, at Drupal er ved at blive standard-platformen, når det gælder medier, og det giver flere fordele for ugeaviserne.
Bl.a. bliver det mere simpelt at integrere og dele indhold mellem medie-sites, og man får lettere ved at finde kvalificerede udviklere med kendskab til mediebranchen."

Jeg bad Tommy Styrbæk give en guided tour rundt i maskinrummet og forælle lidt om de tekniske detaljer.

"Løsningen til Brande Bladet er efterhånden ved at have et par år på bagen, og mit kendskab til Drupal og ikke mindst de mange moduler er blevet væsentlig forbedret siden. Så de løsninger, jeg laver i dag, bliver strikket sammen på en lidt anden måde, da jeg har fået noget mere erfaring med bl.a. at finde og kombinere de rigtig moduler.

Min seneste avis-webløsning til galtenfolkeblad.dk, er en neddroslet udgave af www.brandebladet.dk, og indeholder nyheder, e-paper, billedgalleri og annoncer.

Nyhedsdelen
Til nyhedsdelen har jeg lavet en indholdstype (CCK), med mulighed for upload af fotos, der automatisk skaleres og optimeres med ImageCache.
Visning af de seneste nyheds-teasere på forsiden er opbygget med Views og igen ImageChache.

Muligheden for at skrive kommentar til nyhederne leveres at modulet Comments, der er standard i Drupal. Kommentarformularen er modificeret lidt med et par theme_hooks i template.php.

Alle kommentarer skal godkendes af redaktøren inden de offentliggøres, så hver gang der oprettes en kommentar, bliver der sendt en mail til redaktøren, og det styres af modulet Rules.

Der er også lidt integration med Facebook i form af en "Del på Facebook"-knap på alle nyheder, det er sat op med modulet Facebook Share. Desuden kopieres alle nyhedsteasere  over på avisens egen Facebook-side ved hjælpe af et feed lavet med Views, og en Facebook feed-importer.

E-paper (OnlineAvis)
Den trykte avis ligges online som epaper via en service fra www.swiflet.dk. Jeg har så lavet en arkivfunktion, der ved hjælp af modulet Feeds henter titel, udgivelsesdato og et foto af avisens forsiden fra et feed hos Swiflet.

Billedgalleri
Billedgalleriet er også en indholdstype opbygget med CCK. Det er muligt at upload flere billeder på en gang vha. modulet swfupload.
Visningen af gallerierne er lavet med Views, Imagecache, Galleria samt Lightbox.

Annoncer
Annoncerne er faktisk også et slags galleri, da det blot er jpg-filer af annoncer fra den trykte avis. Her har jeg også lavet en indholds-type, og til visningen er der brugt Views Slideshow samt Lightbox.

Kontaktformular og statiske sider
De forskellige kontaktformularer er lavet med Webform, og de statiske informationssider bygges op vha. wysiwyg og Tinymce, samt IMCE.

Stadig Drupal 6
Det skal nok lige nævnes at jeg stadig laver disse webløsninger i Drupal 6, da flere af de moduler, jeg bruger, ikke er 100% klar til Drupal 7. Men når jeg skifter vil flere af ovenstående moduler blive erstattet af nye."

• ugeaviser

• Tommy Styrbæk

• brandebladet.dk
• galtenfolkeblad.dk
• tsgrafiskpro.dk

Sometimes it happens that a beer + a talk about "all thats wrong" fires up my mind. Tonight was one of those nights, so instead of getting hammered on a thursday (yeah im getting old) I sat down & plotted out a very rough draft for a Dogme Ruleset. Its been discussed numerous times over the last 3 years in quite dark corners, between those called themers in the Drupalsphere

read more

Da jeg fornylig var på besøg hos den danske afdelig af Drupal-huset NodeOne, var jeg så heldig at få et eksemplar af Johan Falks nye Drupal-bog med hjem under armen.

Nu har jeg læst den, og synes jeg vil give den et par ord med på vejen. Men først et par ord om forfatteren, som jeg skylder en stor tak. Johan Falk er manden bag en nærmest endeløs række af fremragende screencast om Drupal. Med sin tørre svenske humor som trofast følgesvend, har han løftet sløret for mange af Drupals hemmeligheder for mig.

For mig var der en tid før Johan Falk og en tid efter. Her taler jeg ikke om videoernes uomtvistelige kvaliteter hver for sig, men om hele Johan Falks tilgang til Drupal-udvikling. Manden har, som ingen andre jeg kender til, faktisk sat sig ind i, hvad moduler som Views, Page Manager og Panels kan - hvad man alene ved at bruge de store generiske modulers user interfaces kan få et Drupal-site til at præstere. Og det er ikke småting, skulle jeg hilse og sige.

Falks tilgang til Drupal-udvikling er helt anderledes, end den jeg er stødt på hos mange danske udviklere, som ofte hellere vil skrive deres egen custom kode i stedet for at bruge de generiske moduler.

Nu er det ikke sådan, at der ikke kan være gode argumenter for custom kodning. For det første er kompleksiteten i administrationen af de store, generiske moduler så voldsom, at det ofte kan være hurtigere at skrive sin egen kode end at lære, hvordan man indstiller for eksempel Panels og Pagemanager. For det andet er der performance-spørgsmålet.

Vi ved fra software generelt (tænk Microsoft Word), at systemer som kan alt ofte ender med at blive klodsede. På plussiden er det fantastisk, hvad man kan præstere med Drupal uden at skrive en linjes kode. På negativsiden tæller, at det ikke er meget lettere at lære sig Rules, Views og Panels til bunds, end det er at lære at programmere. Kompleksiteten er også så høj, at argumentet om at almindeligt dødelige webredaktører selv har mulighed for at udvide et sites funktionalitet dør under fødslen - jeg kender ikke til mange webredaktører, som har tid til at sætte sig ind i Views for alvor.

Men (jeg er ude på et sidespor, men kører lige lidt videre) der er et argument, som trumfer alle andre i Falk-skolens favør: Den helt store fordel ved at bruge de generiske moduler er, at hvis det bliver de facto standarden, så vil det være langt lettere for udviklere at forstå og videreudvikle sites, de ikke selv har bygget fra scratch. Og så er det naturligvis også sværere at opdatere og vedligeholde sites med en stor custom kodebase. Sandsynligheden for at man kan installere nye moduler uden at sitet af den grund går i hårdknude er selvfølgelig også mindre, hvis alt så vidt muligt er bygget med de mest robuste moduler, Drupals community har skabt.

Derfor er jeg Johan Falk-mand. Let's do it the Drupal way. (Selvom vi så alle falder i og hacker noget hjemmebryg sammen fra tid til anden alligevel.)

Og så tilbage til det, jeg egentlig kom her for:

Drupal 7 - the essentials er en udmærket indføring i Drupal for begyndere. De basale koncepter som noder, blokke, taksonomi, felter, rettighedskontrol m.m. bliver altsammen gennemgået pædagogisk med udmærkede illustrationer. Bogen er en lærebog med masser af øvelser - det er ikke til mit temperament, men omvendt er bogen jo heller ikke henvendt til sådan en som mig.

Johan Falk får også plads til en ret grundig indføring i Views, og han runder i et langt appendix også Rules, Page Manager og Panels. Efter endt læsning har man en god fornemmelse for, hvad Drupal er for et bæst, og hvis man gennemfører øvelserne vil man være i stand til at opbygge relativt komplekse sites uden at programmere.

Jeg kan godt forestille mig, at jeg kunne komme til at bruge bogen - eller dele af den - som grundbog i forbindelse med kurser for nogle af mine kunder.

Det eneste problem jeg har med bogen er, at den ikke er nær så god som Johan Falks screencast. Bortset fra selv at eksperimentere findes der ingen bedre måde at lære på, end ved simplet hen at se med sine øjne hvordan man gør i real time, mens en kompetent instruktør fortæller om og uddyber, hvad der sker. Hvis Johan Falk skulle nedfælde indholdet i de mange screencast, han har begået, på A4-ark ville det blive en stabel højere end Rundetårn - og i det perspektiv kommer bogen til at virke som en delikat, men langtfra mættende forret.

I sidste ende er det måske ikke så dårligt, for jeg tror han og NodeOne opnår to ting med bogen: De fleste læsere vil få appetit på mer og samtidig vil de få en forståelse for, hvor fantastisk langt man kan komme med opbygningen af et Drupal-site, før man behøver at taste "<?php". 

• anmeldelser

• NodeOne

• Johan Falk

Now we have it again in the Drupalsphere and for the next couple of weeks there will be an endless promotion of drupalcon session from the speakers or their companies to enhance their chances for getting a spot as a speaker at DrupalCon.
when we finally get the session selection, there will be an outcry of angry, pisssed of & sad people in our community.

read more

Jeg er involveret i et par spændende projekter som viser at Drupal er ved at krydse nogle grænser i Danmark i forhold til vad man kan bruge systemet til.

Jeg blev af en kunde bedt om at finde eksempler på brugen af Drupal som "gruppeværktøj" - altså til et funktionaliteter som minder om dem man kan finde på sites som holdsport.dk, groupcare.dk m.fl.

En anden kunde vil starte en (ret speciel) webshop - så jeg researcher også på brugen af Drupal i den sammenhæng.

I forhold til Drupal som gruppeværktøj er det egentlig utroligt at Drupal ikke har større udbredelse i Danmark, når man tænker på den succes systemet har haft på andre områder. Fro Drupal er helt fra den første linjes kode tænkt som netop det - et værktøj som gør det muligt for forskellige typer af brugere at samarbejde om at oprette, redigere, distribuere og tilgå indhold på et website. Drupals fintgranulerede rettighedssystem gør det let at styre, hvilke typer af brugere, der skal have adgang til hvilke funktionaliteter.

Der er da også en lang række internationale eksempler, hvor Drupal-løsninger som Open Atrium og Acquia Commons er platforme for robuste gruppeværktøjer, intranet, ekstranet m.m.

Men Danmark er Sharepoint-, Lotus Notes- og Groupcare-land. Og mange organisationer og virksomheder har investeret meget store summer i tunge systemer, som integrerer med medlemsbaser, økonomisystemer, CRM og meget andet godt - og ofte har processerne været lange og yderst smertefulde. Man sidder måske tilbage med et system, som ikke fungerer optimalt, og som er dyrt i licenser og vedligeholdelse (Lotus Notes-konsulenter ved godt, hvad de skal tage i timen) - men alene tanken om at skulle igennem et platformsskifte får det til at sortne for IT-chefernes øjne.

Derfor er beslutningsprocesserne langsommelige og det tager meget længere tid for en ny spiller at æde sig ind på dette marked, end det gør på andre områder. Der er også en umiddelbart forståelig angst forbundet med at skulle være pioner - ingen har lyst til at være dem som skal betale udviklingshusenes lærepenge.

Den gode nyhed er, at der er en del Drupal-projekter i søen (og enkelte er i drift) allerede. Et eksempel er Arkitektforeningen, som allerede i dag bruger Drupal som gruppeværktøj. Jeg ved, at andre organisationer er på vej på Drupal og glæder mig til at kunne præsentere resultaterne her på sitet.

Jeg prædiker jo altid pragmatisme - så det vil jeg også lige gøre her: Integration er næsten altid smertensbarnet i projekter af denne type. Det skyldes sjældent, at Drupal eller de andre nyere CMS-systemer har svært ved at håndtere integration, men det har til gengæld de ofte ældre IT-systemer, de skal integreres med. Så en pragmatiske tilgang er:

1) Undgå integration hvis det er muligt.
2) Overvej om real-time integration virkelig er nødvendig eller om integrationen kan klares på andre måder.
3) Overvej om skiftet af CMS kan være anledningen til også at udskifte forældede medlemssystemer m.m., så det er muligt at tænke en helhedsløsning fra scratch.

Jeg er selv blevet meget klogere på Drupal som gruppeværktøj gennem de seneste par uger og fortsætter med at lede efter gode eksempler.

Når det gælder Drupal som webshop er problematikken måske lidt anderledes - jeg er ikke nået så langt i min research, at jeg kan drage overordnede konklusioner. Men umiddelbart ser det ud til, at Drupal her er oppe mod en helt anden form for konkurrence fra relativt billige systemer som til gengæld mangler den fleksibilitet, Drupal kan levere. Hvis man bare så hurtigt som muligt skal i luften med en shop er en platform som Magento tillokkende - og der er mange udbydere som for meget små summer kan få dig i gang med at sælge varer på nettet. Jeg tror, at det dækkerbehovet for mange. Problemerne opstår (og igen - jeg taler på baggrund af en relativt overfladisk research), når man har brug for avancerede CMS-faciliteter i samspil med webshoppen eller på anden vis har behov for en høj grad af fleksibilitet.

Jeg vender tilbage med eksempler på Drupal-webshops senere.

• webshops
• gruppeværktøj

• Magento
• Acquia
• Open Atrium

Jeg har tidligere fortalt om indhold og indholdstyper og forklaret, at en "node" er det centrale indholdselement på en side - det indhold, som hører til netop den url, som står i adresselinjen. På en artikelside er selve artiklen naturligvis det centrale indholdselement, men det er jo ikke det eneste indhold på siden.

Hvis vi tager udgangspunkt i den side, du kigger på lige nu (med mindre du læser artiklen i en RSS-læser) er der øverst på siden logo og navigation, i højre side er der nogle bokse med søgefelt og nøgleord og nederst på siden en footer.

Placeringen af navigationen, som jeg vender tilbage til i et senere indlæg, er her på Drupalog skrevet ind i sitets kode, så man ikke umiddelbart kan flytte rundt på den øverste del af siden. Men derudover er der stor fleksibilitet. Resten er siden er opdelt i en lang række områder, som i Drupal-terminologi kaldes "regioner" (regions). For eksempel ligger boksene med søgefelt og nøgleord til højre på denne side i regionen "Første sidebar".

I Drupal-termininologi hedder bokse ikke bokse men "blokke" (blocks). Det ville have været smartere, hvis vi på dansk havde kaldt dem for bokse - for så havde vi undgået forvekslingen blok/blog, som man også løber ind i på engelsk blog/block - men normen er altså, at de hedder blokke.

Der er (i skrivende stund) fem blokke i regionen "Første sidebar" på Drupalog. De fem blokke er allesammen blokke som Drupal automatisk har stillet til rådighed for mig og som jeg så har placeret i den specifikke region. Jeg kunne have valgt at placere dem til højre for indholdet i regionen "Anden sidebar" eller nedenunder indholdet i regionen "Sidefod". Ja, faktisk stiller det design jeg har på Drupalog ikke mindre end 15 forskellige regioner til rådighed på en side. På et så simpelt site som Drupalog har jeg ikke noget at putte i alle disse regioner - men på et mere avanceret site med meget indhold og mange forskellige funktionaliteter, kan der være behov for fleksibiliteten i designet.

Blokke er Drupals indbyggede måde at håndtere distribution af indhold på. Det er muligt at håndtere distributionen på andre måder ved hjælp af forskellige moduler, men når det gælder relativt simple sites, fungerer blok-systemet ganske fint.

Mens jeg skrev denne artikel gik det i øvrigt op for mig, at besøgende på Drupalog ikke kunne se søgefeltet øverst i højre spalte. Jeg havde ikke tænkt over det tidligere, for jeg kunne selv se feltet, fordi jeg altid er logget på som administrator, når jeg besøger sitet. Problemet skyldtes ikke en fejl i Drupal - det er en feauture og endda en meget brugbar én af slagsen. Som administrator har jeg nemlig mulighed for at indstille, hvem der skal have lov til at se de forskellige blokke, og hvem der skal have adgang til at udnytte de forskellige funktionaliteter på sitet. Hvordan det fungerer i detaljer koimmer jeg tilbage til - men i forhold til blok-systemet er det værd at nævne her, at man kan gøre blokke usynlige for bestemte grupper af brugere - for eksempel anonyme brugere, der ikke er logget ind på sitet.

Jeg vil lige have et enkelt stykke terminologi mere med i gryden, nu hvor jeg har introduceret blokke og regioner: Temaer.

Et tema (theme) i Drupal er et design. Et tema er den del af logikken på et Drupal-site, som er ansvarlig for at vise indholdet til brugerne. Så blokke hører altså hjemme i regioner som igen er del af et tema. Jeg vender tilbage til det altsammen i senere indlæg, men nogle gange er det lettere at forstå koncepterne, når man får dem præsenteret i praksis - i nedenstående video viser designeren Emma Jane Hogbin, hvordan hun inddeler et sidedesign i regioner og blokke, så det kan blive til et Drupal theme:

• blokke
• blocks
• Introduktion til Drupal

Man skal ikke have beskæftiget sig længe med Drupal i Danmark før navnet Mikkel Høgh popper op.

Mikkel er blandt andet formand for Drupal Danmark og er én af de teknisk set bedst funderede Drupal-udviklere i landet. Jeg har stillet ham en række spørgsmål om Drupal og udvikling i almindelighed. Enjoy:

Hvor længe har du arbejdet med Drupal - og hvordan blev du i sin tid introduceret til systemet?

Det er mere end seks år siden, jeg første gang prøvede Drupal. Begyndte dog først for alvor at lave sites med det for 5 1/2 år siden.
Jeg har bygget websites siden 1999, lavet mit eget CMS, og brændt fingrene på det.
I flere år søgte jeg efter det “rigtige” system - et som havde den rette balance mellem features og fleksibilitet. Før Drupal har jeg arbejdet med blandt andet Fundanemt, TYPO3 og Mambo/Joomla!

Hvad er dine styrker som udvikler?

Det er svært at sætte ord på, men jeg tror det er en kombination af overblik og alsidighed. Jeg har arbejdet på mange forskellige projekter med meget forskellige roller, og det har hjulpet mig til en forståelse for størstedelen af de mange discipliner, der indgår, når man skal have et webprojekt sat i søen - alt fra design til systemadministration. Samtidig har jeg, måske fordi jeg lavede mange puslespil med min søster i min barndom, et vist talent for at kunne overskue komplekse systemer og planlægge, hvordan man får lavet artitekturen, så man kan få alle brikkerne til at passe sammen og ikke maler sig op i et hjørne.

Kan du give nogle eksempler på spændende Drupal-projekter, du har været involveret i?

Det ubetinget største Drupal-projekt jeg har været involveret i er helt sikkert Ding.TING, som er drevet af et konsortium af folke- og forskningsbiblioteker og biblioteksrelaterede organisationer med henblik på at lave en open source platform for fremtidens bibliotekswebsites. Jeg var den primære udvikler på den første version, som blev lanceret i starten af 2010 - først på bibliotek.kk.dk og aakb.dk, og siden helsbib.dk, vejlebib.dk, roedovrebib.dk, billundbib.dk, koldingbib.dk m. fl. 
Det er nu inspirerende at vide, at det man har arbejdet så hårdt og længe på, bliver brugt af mange tusinde mennesker.
Jeg er også involveret i Ding2-projektet, som er en ny og gentænkt version af Ding.TING, som gerne skulle lanceres i starten af november.

Der ud over har jeg det seneste års tid været med til at arbejde på en online byggeordbog (altomhus.dk). Vidensformidling på så højt niveau er både spændende og udfordrende, og som med biblioteksprojektet er det meget professionelt tilfredsstillende at være med at bygge den slags almennyttige løsninger.

Hvilke Drupal-eksperter samarbejder du ofte med?

Reload er vores største samarbejdspartner, og det er da også gennem dem at vi er involveret i Ding.TING. I Drupal Danmark-regi har jeg fornøjelsen af at arbejde sammen med stort set alle Drupal-eksperter i Danmark fra tid til anden, så det er også et privilegie.

Du er gået fra Peytz & Co. til egen virksomhed, Reveal IT - hvad er fordele og ulemper ved at sidde i et større udviklingshus kontra et lille?

Min motivation for at starte egen virksomhed handlede meget om personlig frihed, et ønske om selv at kunne tage projekter ind (som jeg også gjorde, før jeg blev ansat hos Peytz & Co.), og så ønsket om at flytte tilbage til Lolland, hvor min hustru og mange af mine venner bor.
Den største fordel ved selvstændigheden er nok muligheden for at være agil med firmastrategi, opgave- og teknologivalg. Min kollega Jakob og jeg kan hurtigt beslutte, at nu vil vi prøve noget nyt af, tage en anden type af opgaver ind og lave strategiske sats, som for eksempel vores store satsning på Drupal Commerce.
Den primære ulempe er nok, at vi ikke har et salgsapparat. Jeg er ikke den store sælger, men vi har nu heller ikke rigtig haft behov for at sælge os selv i de tre år firmaet har eksisteret.

Kan du sige et par ord om din udviklings(projektledelses)filosofi - hvordan styrer man bedst et Drupal-projekt?

Jeg er forholdsvis udogmatisk når det kommer til projektstyrings-metoder. Som Poul-Henning Kamp engang skrev i et blogindlæg: “En stensikker opskrift på success i softwareudvikling er en kompetent og inspirerende leder, med op til et dusin motiverede medarbejdere.”

Det mest afgørende for et Drupal-projekt (eller bare software-projekter i al almindelighed), er at man har et godt og kompetent team. Kvalitet, ikke kvantitet. Agil udvikling er det hotte lige nu, og så længe det dækker over en fleksibel proces, der ikke forsøger at planlægge alt for langt ud i fremtiden, er jeg i det store og hele enig. Et af de mest udfordrende ting ved softwareudvikling, er at man stort set altid bliver klogere undervejs. Det kræver løbende justering af planer og/eller budgetter. Det kræver, at man er villig til at gå på kompromis.

Det er i mine øjne derfor, at offentlige IT-projekter næsten altid fejler. Man er ikke villig til at tilpasse projektet til virkeligheden, men forsøger i stedet at tilpasse virkeligheden til projektet. Man skriver store kravsspecifikationer, længe inden man egentlig har forstået problemstillingerne til bunds, og når man først har vundet udbuddet, så hænger man på det, og projektet bliver en lang dødsmarch mod et mål, som ofte er helt forkert formuleret.

• agile development
• Ding.TING

• Reveal IT
• Reload
• Peytz & Co.

• Mikkel Høgh

Som jeg nævnte i et tidligere indlæg, drak jeg for et stykke tid side en kop kaffe i det trendy kontorfællesskab Soho i Kødbyen med Rasmus Frey - direktør for den danske del af NodeOne, som ellers har kontorer i Stockholm og Göteborg.

Jeg er altid nysgerrig efter at høre om, hvordan folk blev drupaloger - så det første spørgsmål gav sig selv:

Hvordan opdagede du selv Drupal?

Jeg opdagede Drupal via en af vores udviklere i Sarajevo, Bosnien som blev ved med at sige til mig, at jeg skulle kigge på systemet. Vi ("vi" er egentlig Verk, som blev opkøbt af NodeOne. red.) valgte så at bruge det til et projekt, hvilket var alletiders i mange henseender, men også et mareridt i andre (sådan skal det være med ens første Drupal projekt). Det var Drupal 5.
Det, som har tiltrukket mig ved systemet, er helt klar den store fleksibilitet, man kan jo bygge alt… Her er i sandhed et system som lever op til udsagnet med en stor pose lego.
Ja, og så efter deltagelse i min første DrupalCon var jeg endnu mere tiltrukket, for omkring Drupal er der det mest fantastiske community.

Drupal har svagheder men de overskygges i allerhøjeste grad af styrkerne, det kan ikke betale sig ikke at være tiltrukket af Drupal.

Du siger at Drupal er en pose legoklodser. Hvordan ser du på hele diskussionen om, hvorvidt Drupal er en platform (et framework) eller et CMS? 

Det smukke ved Drupal er jo, at det er begge dele. Hvis man betraget Drupal på kodeniveau, og de mange projekter på drupal.org, så er det et framework. Men hvis du downloader Drupal og kører standard-installationen, så har du et CMS ud af kassen. Jeg sætter mig hverken i den ene eller anden lejr, for Drupal er, hvad du gør det til i den konkrete situation. I nogle tilfælde er det ren og skær framework mens det i andre er et CMS.
I sidste ende bygger man et system, som håndterer indhold, men det er ikke CMS i traditionel forstand for intet Drupal-site er ens hverken forfra eller bagfra.

Drupals community bliver ofte fremhævet - ja, der er dem der mener, at Drupal hverken er et CMS eller et framework, men derimod snarere et community, en bevægelse (en sekt?)
Hvor stort er det danske Drupal community, og hvordan ser du din egen rolle og NodeOnes rolle i det?

Det danske community er desværre ikke så voldsomt stort eller fasttømret endnu. Men alligevel er vi langt langt foran mange andre lande.

Vi var de første til at stifte en lokal forening for at varetage Drupals interesser. Foreningen er stadig lidt fragmenteret men der arbejdes ihærdigt på at skabe samling og sikre, at alle der arbejder med Drupal høres og er en del af foreningen. Så jeg vil mene, at når alt kommer til alt, har vi en solidt community i DK.
Jeg synes selvfølgelig min egen rolle er vigtig, jeg har været med fra starten i Drupal Danmark og har bidraget til alle drupalcamps både som sponsor og som hjælper. Jeg var med til at plante et frø, og pludselig stod vi med DrupalCon i Bella Center. Jeg mener, at jeg kan være med til at tage foreningen skridtet videre, og at jeg kan være med til at udbrede kendskabet endnu bredere. Men ikke alene, vi løfter i flok.

NodeOne spiller selvfølgelig en rolle, vi er et firma som sætter en stor ære i at støtte op om Drupal eco-systemet, og derfor stiller vi både arbejdskraft og sponsorater til rådighed, når der skal arrangeres Drupal-events, eller hvis der skal kodes lidt ekstra.

Kan du sige lidt overordnet om NodeOnes udviklingsfilosofi?

Hos NodeOne udvikler vi efter agile og scrum, fordi vores erfaring viser, at det giver de bedste resultat i den sidste ende. Både for kunde og for os selv.
Et projekt handler jo ikke kun om at levere et produkt. Det handler i lige så høj grad om at knytte en relation og kommunikere mennesker i blandt.

At køre korte itterationer giver den bedste kommunikation og den største tilfredshed med det arbejde som udføres. Ved større projekter vil der altid opstå behov for tilpasning i løbet af projektet, og når vi udvikler agilt og med korte iterationer er mulighederne for tilpasning til stede for hver sprint afslutning.

Vi har mulighed for at imødekomme ændringer hurtigt og effektivt.

Det er også vores oplevelse, at det giver en større indlevelse i projekterne både fra udviklere og fra kunden, simpelthen fordi alle parter kommunikere langt mere end når man arbejder efter vandfladsmodellen og med en striks topstyring fra en projektleder.

Med Drupal er der også ofte mange løsninger og mange forskelligeartede løsninger. Den klassiske vandfaldsmodel hvor man på forhånd bestemmer sig for, hvordan det skal være, fungerer ikke særlig godt sammen med Drupal. Her har vi behov for de forcer, der ligger i agil udvikling, nemlig at kunne afprøve flere løsninger på samme problem, tage stilling og tilpasse alt sammen i tæt kommunikation med kunden og inden for en kort udviklingsiteration. For os handler det om, at vi arbejder mod et fælles mål og udvikling efter agile/scrum-principper understøtter dette til det fulde.

Det er svært at udpege et specifikt Drupal projekt, de er jo alle sjove og har alle deres særpræg. Men egentlig synes jeg det bedste var at bygge vores eget interne vidensdelingsplatform på Drupal 6 tilbage dengang vi hed Verk.
Men det var nok mest fordi jeg fik lov til at lege med teknikken, det gør jeg jo sjældent i dag.

NodeOne er nye i Danmark, så kataloget over færdigudviklede sites er ikke stort. Eksempler: http://webmagasin.kvinfo.dk/, http://forside.kvinfo.dk/ og http://www.verdensskove.org/

Flere spændende sites er dog på vej. Stay tuned.

• agile development
• scrum

• NodeOne

• Rasmus Frey

One of the more annoying things about theming [Drupal][] sites is having to wade through the staggering amounts of wrapping <div> elements and containers. Some of these are are fairly easy to get rid of. Others require you to override core templates.

I recently found a clean way to get rid of a couple of those. These two were introduced in Drupal 7, and you will probably find them on almost all Drupal 7 sites – they look like this:

Or in markup:

Now, the last of these wrappers are actually useful, the rest stems from one of the changes in Drupal 7, namely that the main page content is now a block, that can be positioned on the page via Drupal’s block system.

Now, that's a nice concept, but all the site I've seen do business as usual, and get around this inconvenience by creating a block region called “content” and sticking the content-block in there as the only thing, leaving the region and block wrappers as more DIV-spam in your site’s markup.

So unless you're actually doing something different with the content block and/or region, you can just get rid of these extra wrappers by sticking the two following templates in your theme’s template folder:

(region--content.tpl.php) download 1 2 3 4 5 6 7 8 <?php /** * @file * Render the main content block region. * * We don't print all kinds of wrapper divs and titles, just the content. */ print $content; (block--system--main.tpl.php) download 1 2 3 4 5 6 7 8 <?php /** * @file * Render the main content block. * * We don't print all kinds of wrapper divs and titles, just the content. */ print $content;

Short and sweet :)

Som jeg tidligere har beskrevet opererer Drupal med indholdstyper.

Lad os antage, at du bygger et website, som handler om mad. Her kunne det være hensigtsmæssigt at oprette én indholdstype for opskrifter og én for nyheder. Måske har du brug for en tredje som skal bruges til restaurantanmeldelser og en fjerde, som kan bruges, når du skal lave beskrivelser af berømte danske kokke.

Når vi skriver noget i et tekstbehandlingssystem som Word, sætter vi typisk ikke indholdet i system på denne måde. Men på nettet er der en lang række fordele ved at strukturere indholdet. Dem vender jeg tilbage til - men først lidt mere om behovet for forskellige indholdstyper.

Indholdstyper er opbygget af felter (fields).

Som jeg forklarede tidligere har den simpleste indholdstype (basic page) faktisk kun to felter - titel og indhold (plus en række administrationsmuligheder og dato og forfatter-felter, men det er en anden historie).

Hvis man skriver en nyhed eller et blogindlæg har man muligvis ikke brug for yderligere felter. Men laver man en opskrift kan det være smart at inddele indholdet i for eksempel: "Kort beskrivelse", "Ingredienser", "Fremgangsmåde", "Servering", "Tidsforbrug", "Ophavsmand M/K". Det giver nemlig dels mulighed for at style hvert afsnit særskilt, så ingredienserne for eksempel står med kursiv eller fed skrift - eller i en særlig boks - og dels giver det mulighed for at hive indhold ud af de enkelte felter til brug for lister rundt om på sitet. Den korte beskrivelse kan bruges på oversigtssider og i søgeresultater. Tidsforbrug-feltet gør det muligt for brugerne at sortere opskrifterne efter, hvor lang tid det tager at lave maden. Hvis en bruger kunne lide Hanne Jensens frikadeller, kan han måske også lide hendes karbonader med ærter - og så er det smart, at vi har opskriftens ophavsmand skilt ud i et særligt felt og let kan generere en liste over alle de opskrifter, Hanne Jensen har leveret.

Drupal gør alt dette muligt, fordi man selv kan definere nye indholdstyper og tilknytte de felter, man har behov for. Felter kan genbruges i andre indholdstyper, så man ikke behøver at oprette et "Kort beskrivelses"-felt, hver gang man opretter en ny indholdstype.

Det er altsammen genialt. Men der lurer en fare - nemlig at der går inflation i antallet af indholdstyper på et site. Jeg har selv prøvet det et par gange. Tilsidst kan redaktørerne ikke længere overskue antallet af indholdstyper, og så begynder de at bruge dem forkert. De lægger nyheder ind som opskrifter og omvendt. Derfor er det vigtigt at holde antallet af indholdstyper på et begrænset niveau - og i stedet udnytte Drupals fantastiske nøgleord til at gøre forskel på indholdet med.

Jeg faldt over nedenstående fine forklaring om, hvordan man bedst bruger indholdstyper - på engelsk, men for en gangs skyld uden mange uforståelige Drupal-termer:

• Introduktion til Drupal
• indholdstyper
• felter

CBS Observer er en netavis henvendt til de 18.000 studerende, 1000 fastansatte og 800 deltidsundervisere på Copenhagen Business School. Siden 2008 har sitet kørt på Drupal 6, men nu er tiden inde til en opgradering - i den forbindelse har jeg stillet redaktionssekretær Jørn Albertus et par spørgsmål om projektet.

Hvorfor skifter I til Drupal 7 netop nu?

Den nuværende løsning er lavet af Steven Snedker, der stod for udvikling, og Lars Damgaard, der stod for design og style sheets tilbage i 2008. Den er blevet udviklet løbende, men designet er lavet for at ligne papiravisens (som ikke længere udkommer. red), og nu skal vi have noget, der kan stå for sig selv, er friskere og mere levende og moderne.

Og når vi nu alligevel skal gå over til nyt design, så er det et godt tidspunkt også at opgradere CMS’et. Drupal 7 kan mere og har flere af de moduler, vi anvender på sitet, lagt ind i kernen, så jeg forventer et lavere supportbehov for os på længere sigt. Samtidig er CBS site, cbs.dk, også ved at blive lagt over på Drupal 7, og jeg forventer, at flere af CBS’ subsites og intranet vil blive lagt over i Drupal 7 senere. Så selv om CBS Observer ikke ligger på CBS’ servere og heller ikke skal det, så synes jeg, at det er meget fedt, hvis vi anvender samme CMS.

Vi vil måske på et tidspunkt kunne købe os til support inhouse, og vi vil under alle omstændigheder kunne videndele med folk i vores it-afdeling, som i øvrigt også har brugt mig dengang de stadig overvejede, hvilket CMS, CBS nu skulle have. Det er godt med en standard for CMS på sådan et stort sted, og den standard skal selvfølgelig være Drupal 7."

Hvor lang tid regner I med, at projektet vil tage, og hvordan planlægger I arbejdet med opgraderingen?

Vi gik i gang midt i august. Lasse Gejl er ved at lave design. Han er næsten færdig med forside og artikelside, så Steven og jeg satte os for nylig og besluttede, hvordan de enkelte elementer på disse to sider skulle fungere. Sideløbende arbejder Lasse videre med at designe nyhedsbrev og andre undersider. Når designet er færdig, bruger vi Lars Damgaard til at style og lægge det i html. Vi regner med at være færdige i december, hvor vi så også går i luften med det nye design."

CBS Observer er en universitets(net)avis, der blev grundlagt for 33 år siden af en kreds af tillidsfolk og studenterpolitikere og andre, der var interesseret i at få et internt blad på Handelshøjskolen i København. Sidenhen er avisen blevet professionaliseret og har i dag to fastansatte. Derudover arbejder såkaldte VIP-(videnskabeligt personale), TAP- (teknisk-administrativt personale) og studenterredaktører som skribenter på timebasis.

CBS Observer har sin egen tillidsmands- og studenterudpegede bestyrelse, hvor der også sidder en repræsentant for CBS’ direktion. Avisen er redaktionelt uafhængige, og Bjørn Hyldkrog (ansvarshavende) refererer ikke til CBS' ledelse, men til CBS Observers bestyrelse. Indtil oktober sidste år var CBS Observer en tabloidavis, der blev udgivet ni gange om året. 

• CBS

• Jørn Albertus
• Steven Snedker
• Lars Damgaard
• Lasse Gejl

• cbsobserver.dk