Kom godt i gang med Drupal: Vær forberedt på muren og lær at hooke

Man kan godt lære CMS'et Drupal at kende på en sommerferie. Efter et vellykket ’Kod i Ferien’-projekt giver ITU-studerende Jacob Ringbo her sine erfaringer videre.

Jacob Ringbo studerer spil design og teknologi på IT Universitetet og skulle i forbindelse med ’Kod i Ferien’-projektet lære CMS-systemet Drupal at kende. Og det var på både godt og ondt, for han fandt ud af, at man skal tænke helt anderledes, end når man koder i Joomla! og andre CMS’er.

Jacob Ringbos opgave var at lave et CMS-modul til artikeleksporten fra borger.dk, som for eksempel er smart, når der skal laves RSS-feeds. Hans kontaktperson fra IT- og Telestyrelsen ville gerne have, at modulet blev lavet i open source CMS-systemet Drupal, der kodes i PHP.

»Jeg begyndte at læse en del på nettet om hele Drupal-strukturen. Jeg kan godt kode i PHP, men i Drupal har de deres helt egen struktur. Hvis man vil lave noget nyt, så skal man bruge deres hooks,« siger han til Version2.

De steder, hvor kode kan eksekveres, kaldes ‘hooks’ og er defineret ved et fikseret interface. Hooks er således den måde, hvorpå moduler kan interagere med kernekoden i Drupal, og de gør det muligt at definere nye URL’er og sider inde på websiden, samt at tilføje indhold.

»Men hver eneste gang man bruger noget af deres funktionalitet som menuer, overskrift og links, så skal man hele tiden lave en hook til det, og det skal man lige vænne sig til,« siger Jacob Ringbo til Version2.

Jacob Ringbo er ellers vant til at arbejde med mange forskellige CMS’er, for eksempel Wordpress, Joomla, Magento, Prestashop og CakePHP.

»Jeg synes, at den største udfordring helt klart er at komme til at lære det. Problemet er, at man ikke bare kan lære én ting, for det hænger sammen med noget andet. Så det er lidt irriterende, at man skal lære utroligt meget, som man ikke skal bruge, for at lave utroligt lidt. Ulempen er altså, at indlæringskurven er stejl, men når man er i gang, så er det let.«

Kommandoerne bliver genbrugt, men alligevel er det irriterende, at man skal lære det hele på en gang, for det afholder formentligt flere fra at lære Drupal, forudser Jacob Ringbo.

»Der er nok mange, der prøver, men som giver op, fordi de møder en mur.«

Godt med strikse spilleregler

Men hvad er fordelen så ved Drupal?

»Når man først kommer i gang med det, er tingene forholdsvist strukturerede, fordi der er strikse regler i forhold til i Joomla! Man bliver nødt til at spille efter Drupals spilleregler, og det gør det både svært, men det gør også, at man kan holde det struktureret,« siger han til Version2 og fortsætter:

»Det er også smart, at det er open source, så man har adgang til alt kildekoden. Så man kan bare gå ind og lure kildekoden af, og kopiere det, man vil bruge. Det kan man lære mange ting af, og mange avancerede ting, jeg ellers ikke ville have fundet ud af.«

Følg forløbet

Kommentarer (27)

Lars K. Hansen

er meget stejl for Drupal. Men når først man har forstået deres hook_ system flyver man afsted.

The "Drupal way" er at bruge de hooks - ellers gør man det meget svært for sig selv.

David Rechnagel Udsen

Hooks må været noget de har taget fra MediaWiki. Ikke en dårlig idé, så der er ingen grund til at Drupal ikke skulle tag den. Desværre sutter Drupal enormt meget. Det er tydeligvis ikke skrevet af en person med datalogisk indsigt i at skrive store projekter som andre skal bruge.

Noget så simpelt som at tvinge kun én brugers blogindlæg på forsiden af gangen (som det var på det gamle Version2 (Version1)) er nærmest umuligt. Der er ikke et konfigurationsflag som man ville forvente det fra f.eks. MediaWiki, som har et ocean af konfigurationsflag og de er alle veldokumenteret.

Så for at skulle undgå at overhovedet at arbejde med Drupal, så plejer jeg normalt altid at kode funktionaliteten selv. Det ender normalt mere lykkeligt.

Mikkel Høgh

Hooks må været noget de har taget fra MediaWiki.

Drupal er fra 2001, MediaWiki er fra 2002. Om noget har MW ladet sig inspirere af Drupal. Det er dog ikke nogen ny idé, så de kan sagtens have fundet på det hele selv.

Det er tydeligvis ikke skrevet af en person med datalogisk indsigt

Dries Buytaert har en ph.d. i datalogi.

Noget så simpelt som at tvinge kun én brugers blogindlæg på forsiden af gangen (som det var på det gamle Version2 (Version1)) er nærmest umuligt.

Din indsigt i Drupal er tydeligvis ret begrænset.

et konfigurationsflag som man ville forvente det fra f.eks. MediaWiki

Drupal kan ikke have indstillingsmuligheder til alle de obskure ting man kunne tænkes at ville lave med det. Så skulle vi have ~150.000 sådanne flag. Man kan ikke rigtig sammenligne MW med Drupal. Det ene er et Wiki-system, det andet er et content management framework.

så plejer jeg normalt altid at kode funktionaliteten selv. Det ender normalt mere lykkeligt.

http://en.wikipedia.org/wiki/Not_Invented_Here

Eller måske et Holberg-citat: “Enhver bliver lykkelig i egen nathue.”

David Rechnagel Udsen

Drupal er fra 2001, MediaWiki er fra 2002. Om noget har MW ladet sig inspirere af Drupal. Det er dog ikke nogen ny idé, så de kan sagtens have fundet på det hele selv.

Men er hooksne også fra 2001? Jeg ved det ikke.

Dries Buytaert har en ph.d. i datalogi.

Jeg så så gerne at han også brugte den til noget.

Din indsigt i Drupal er tydeligvis ret begrænset.

Så fortæl mig i såfald hvordan. Det nager mig at man kan sikre sig en plads på forsiden ved bare at spamme i sin blog.

Drupal kan ikke have indstillingsmuligheder til alle de obskure ting man kunne tænkes at ville lave med det. Så skulle vi have ~150.000 sådanne flag. Man kan ikke rigtig sammenligne MW med Drupal.

Er det virkelig det der holder dem tilbage? Tsk tsk.

http://en.wikipedia.org/wiki/Not_Invented_Here

Eller måske et Holberg-citat: “Enhver bliver lykkelig i egen nathue.”

Hey, det virker i det mindste.

David Rechnagel Udsen

Forstår ikke helt det du ønsker. Kan du uddybe?

I gamle dage på Version 2, så ville en blogger kun optræde én gang på forsiden, selvom de havde skrevet mange blogindlæg inde for det sidste døgnstid. I dag vil listen bare sorteres efter dato, men man kan ikke begrænse listen til at kun vise ét blogindlæg per blogger.

Hvis den kan, så vil jeg gerne høre det. Men min egen ekspert på Drupal påstår det ikke er muligt (eller i hvert fald ikke trivielt).

Kan du være mere specifik om hvordan han skulle bruge den? Hvad er det der er galt? Spørger af ren nysgerrighed.

Drupal er et CMS. Det skal og vil indeholde mange små funktioner. Folk vil gerne have muligheden for at skræddersy disse funktionaliteter til deres egen virke. Sådanne forhold bør blive forudset tidligt i processen.

Man bør derfor skabe et fleksibelt og elastisk system, der kan bibeholde over 100.000 forskellige funktionaliteter. Det lyder som meget, men Drupal er også et stort brød.

Og lad mig ikke komme i gang med t()-kommandoen. Ih ha. Værre måde at skabe lokalisation har vist kun Microsoft overgået.

Jens Beltofte Sørensen

I gamle dage på Version 2, så ville en blogger kun optræde én gang på forsiden, selvom de havde skrevet mange blogindlæg inde for det sidste døgnstid. I dag vil listen bare sorteres efter dato, men man kan ikke begrænse listen til at kun vise ét blogindlæg per blogger.

Hvis den kan, så vil jeg gerne høre det. Men min egen ekspert på Drupal påstår det ikke er muligt (eller i hvert fald ikke trivielt).

Nu er Drupal ikke kun CCK / Fields og Views. Man kan selv kode sine moduler, og lave en custom content pane til Panels, så man kan fint fikse det blog element på forsiden. Om du kan lave det i Views ud af boksen skal jeg ikke kunne svare på, men det kan fint klares på anden måde hvis man ønsker det.......

Mikkel Høgh

Man bør derfor skabe et fleksibelt og elastisk system, der kan bibeholde over 100.000 forskellige funktionaliteter. Det lyder som meget, men Drupal er også et stort brød.

Så fordi Drupal ud af boksen ikke har lige nøjagtigt den funktionalitet du ønsker dig, så er det pludselig ikke et fleksibelt system? Det du efterspørger er ikke trivielt, uanset systemet. En liste af poster, sorteret efter dato, med det filter at ingen af posterne har det samme forfatter-ID som nogen af de andre. Kan du gøre det med en enkelt databaseforespørgsel?

Missionen for Drupal core er at levere grundfunktionaliteten for at man kan bygge stort set hvad som helst oven på. Pt. er der mere end 8.500 udvidelsesmoduler, og det skulle ikke undre mig om der er et af dem, der kan det du efterspørgerr. Ellers er det jo ikke så svært at lave en custom-side i Drupal og så klare det fornødne med en smule PHP og SQL.

Og lad mig ikke komme i gang med t()-kommandoen. Ih ha. Værre måde at skabe lokalisation har vist kun Microsoft overgået.

Det er nu ikke noget Drupal har fundet på. GNU gettext er en af de mest udbredte lokaliseringssystemer: https://secure.wikimedia.org/wikipedia/en/wiki/GNU_gettext – at funktionen så hedder t() istedet for _() gør vel ikke nogen særlig forskel i sammenhængen?

David Rechnagel Udsen

Så fordi Drupal ud af boksen ikke har lige nøjagtigt den funktionalitet du ønsker dig, så er det pludselig ikke et fleksibelt system?

Det er ingenlunde det jeg antyder. Jeg antyder at den funktionalitet der eksisterer i 'boksen' bør være fleksible og i stand til at modtage megen ekstra funktionalitet på en ordentlig og skalérbar vis.

Det er nu ikke noget Drupal har fundet på. GNU gettext er en af de mest udbredte lokaliseringssystemer: https://secure.wikimedia.org/wikipedia/en/wiki/GNU_gettext – at funktionen så hedder t() istedet for _() gør vel ikke nogen særlig forskel i sammenhængen?

Nej, men GNU gettext er vist heller ikke den bedste måde at gøre det på. Og bare fordi nogle andre har gjort det før er det vel ikke grundlag for at man skal gøre det igen?

Man kunne have håbet at folkene bag Drupal havde set problematikken bag GNU gettext og derpå implementeret et mere moderne, fleksibelt og generelt bedre system.

Igen vil jeg sammenligne t() med MediaWiki's wfMsg() som er langt mere fleksibelt.

Philip Munksgaard
David Rechnagel Udsen
Mikkel Høgh

Du snyder jo, du bruger jo funktionalitet der findes i SQL! Det går virkelig ikke at du påstår at vi skal bruge SQL til andet end dum datahenter!

Sarkasme aside, så virker den tilgang I foreslår umiddelbart ikke:

SELECT DISTINCT(uid), nid, title FROM node WHERE type = 'word' ORDER BY created DESC;

giver:

+-----+-------+---------------------------+  
| uid | nid   | title                     |  
+-----+-------+---------------------------+  
|   1 | 17010 | Kolonihaveområde          |  
|   1 | 17008 | Landbrug                  |  
|   1 | 17006 | Tæt bymæssig bebyggelse   |  
|   1 | 17004 | Industriområde            |  
|   1 | 17002 | Sommerhusområde           |  
+-----+-------+---------------------------+

Og så mangler jeg stadig at høre din argumentation til hvorfor Drupal skulle være ufleksibelt bare fordi der ikke er en feature checkbox for din personlige kæphest. Hvad er det wfMsg() kan som ikke er muligt med t()?

David Rechnagel Udsen

SELECT DISTINCT(uid), nid, title FROM node WHERE type = 'word' ORDER BY created DESC;

DISTINCT er ikke en funktion, men et statement.

http://www.sql-tutorial.com/sql-distinct-sql-tutorial/

Hvad er det wfMsg() kan som ikke er muligt med t()?

wfMsg() er ikke defineret ud fra en engelsk sætning (det var t() da jeg brugte den i sin tid). Problemet er at engelsk nogle gange kan have sætninger der skrives ens, men ville skrives meget anderledens på et andet sprog. wfMsg() påkræver at du laver et variabelnavn for dine strenge.

Mikkel Høgh

DISTINCT er ikke en funktion, men et statement.

Det er sandt, men det er helt validt at bruge paranteser til at markere hvilket feltnavn det drejer sig om. Resultatet er det samme:

MariaDB [drupal6_abc]> SELECT DISTINCT uid, nid, title FROM node WHERE type = 'word' ORDER BY created DESC LIMIT 5;  
+-----+-------+---------------------------+  
| uid | nid   | title                     |  
+-----+-------+---------------------------+  
|   1 | 17010 | Kolonihaveområde          |  
|   1 | 17008 | Landbrug                  |  
|   1 | 17006 | Tæt bymæssig bebyggelse   |  
|   1 | 17004 | Industriområde            |  
|   1 | 17002 | Sommerhusområde           |  
+-----+-------+---------------------------+  
5 rows in set (0.01 sec)

wfMsg() er ikke defineret ud fra en engelsk sætning

Det har jo så den ulempe at man ikke kan slå lokaliseringssystemet fra hvis man alligevel bare gerne vil have siden på Engelsk (som man kan i Drupal). Det giver en lille performance-fordel.

Problemet du nævner med ens sætninger med forskellige betydninger afhængig af kontekst er løst i Drupal 7 ved brug af context-parametren til t(), så man kan skelne mellem "Order" (rækkefølge) og "Order" (bestilling).

David Rechnagel Udsen

Det er sandt, men det er helt validt at bruge paranteser til at markere hvilket feltnavn det drejer sig om. Resultatet er det samme:

Måske er det på tide at få opgraderet dit databasesoftware.

Det har jo så den ulempe at man ikke kan slå lokaliseringssystemet fra hvis man alligevel bare gerne vil have siden på Engelsk (som man kan i Drupal). Det giver en lille performance-fordel.

Gisp ja! Der er en stor del performance vundet ved kun at bruge ét sprog! Fordi nu skal systemet ikke tjekke for hvilket sprog der er valgt. Jeg er sikker på det er ret ressource-krævende. Især fordi den jo også have andre brugerindstillinger samtidigt.

Tror du virkelig MediaWiki indlæser alle sprogpakkerne hver gang?

Problemet du nævner med ens sætninger med forskellige betydninger afhængig af kontekst er løst i Drupal 7 ved brug af context-parametren til t(), så man kan skelne mellem "Order" (rækkefølge) og "Order" (bestilling).

Det lyder som en elegant løsning... oy vey.

Mikkel Høgh

Måske er det på tide at få opgraderet dit databasesoftware.

Jeg kører nyeste stable release af MariaDB, 5.2.8.

Jeg tror at vi er nået frem til at din primære anke mod Drupal er at det ikke er lige som MediaWiki. Du synes øjensynligt at Drupal er lige så ugennemskueligt og kluntet som jeg synes MediaWiki eller WordPress er. Fint nok, to each his own.

Måske skulle du prøve at bygge dit eget CMS med MediaWikis API'er – det er jo en fri verden vi lever i.

David Rechnagel Udsen

Jeg kører nyeste stable release af MariaDB, 5.2.8.

Ah, så skal jeg ikke bruge MariaDB, når det ikke opfylder definitionen af DISTINCT. Jeg er sikker på de ser på den.

Jeg tror at vi er nået frem til at din primære anke mod Drupal er at det ikke er lige som MediaWiki. Du synes øjensynligt at Drupal er lige så ugennemskueligt og kluntet som jeg synes MediaWiki eller WordPress er. Fint nok, to each his own.

Måske skulle du prøve at bygge dit eget CMS med MediaWikis API'er – det er jo en fri verden vi lever i.

Åh gisp nej. MediaWiki er for wiki'er, ikke et CMS. Jeg bygger mine egne CMS'er. Jeg har allerede mit eget API, som jeg har skræddersyet over flere år. Bare rolig, hvis jeg opdager at mit design er 'flawed' så ændrer jeg skam det hele. Det jo kun mig der bruger der!

Jesper Louis Andersen

SELECT DISTINCT(uid), nid, title FROM node WHERE type = 'word' ORDER BY created DESC;

Det er tæt på. Syntaksen er "SELECT DISTINCT ON ( ... columns ... ) ... query ..." i PostgreSQL 9.1. Jeg aner ikke om MariaDB kan, eller om du kommer på arbejde med at lave et passende avanceret query.

SELECT DISTINCT ON (uid) uid, nid, title  
FROM posts  
ORDER BY uid, created DESC;

Giver:

 uid | nid | title    
-----+-----+--------  
   1 |   2 | Kanel  
   2 |   1 | Drupal  
   3 |   4 | Treaps

for min lille test-table. Koden og INSERT data for tabellen findes her: https://gist.github.com/1235378

Grunden til at det virker er at DISTINCT ON (row) vælger den første række equal-to "row". Vi sikrer så, med et passende ORDER BY, at den første række er den vi er interesseret i. Der er regler: Det ORDER BY vi laver skal have "row" på førstepositionen, men det har det også i vores eksempel.

Mikkel Høgh

så skal jeg ikke bruge MariaDB, når det ikke opfylder definitionen af DISTINCT

Har du egentlig læst definitionen af DISTINCT? SQL standarden er desværre ikke offentligt tilgængelig, men MySQLs manual siger: “DISTINCT specifies removal of duplicate rows from the result set.” http://dev.mysql.com/doc/refman/5.5/en/select.html#id824140

PostgreSQL siger noget af det samme, og fortsætter med at beskrive den DISTINCT ON (row) syntaks som Jesper beskriver ovenfor, som MySQL ikke understøtter.

Hvad var det du sagde ovenfor? Jeg tror ikke umiddelbart det er MariaDB der er noget galt med :)

Der er mange cowboy-kodere derude som foretrækker at lave deres eget CMS. Der har jeg også selv været engang. Det fungerer også meget fint, så længe det drejer sig om enmands-projekter.

Jeg foretrækker dog at slå mine kræfter sammen med andres, så jeg kan fokusere på at lave det jeg synes er spændende, og overlade andre områder i koden til folk som er eksperter på området.

Man kan sige meget om Drupal. Det er bestemt ikke perfekt, men det er der ikke ret meget software der har mødt den virkelige verden der er.

Jesper Louis Andersen

PostgreSQL siger noget af det samme, og fortsætter med at beskrive den DISTINCT ON (row) syntaks som Jesper beskriver ovenfor, som MySQL ikke understøtter.

Heldigvis smed jeg en løsning via SubQueries i min gist også, så du kan bare bruge den i stedet. Der er ideen at vi laver et selvjoin mod tabellen. Det vi joiner med er et Sub-SELECT der finder tidspunktet for den sidste posting og bruger det. Hvis en bruger laver to posts på samme tid fungerer det ikke, men det kan fjernes ved at kræve created UNIQUE.

Og det burde, muligvis med lidt modifikation, virke i MariaDB også.

Mikkel Høgh

Nu vi er ved det, vil jeg også kraftigt anbefale MariaDB som drop-in replacement for MySQL. Jeg har for et halvt års tid siden lavet det skift, både på udviklings- og driftmiljøer, og vi har ikke på tværs af de 40+ Drupal-sites vi hoster plus diverse andre applikationer oplevet kompatibilitetsproblemer mellem de to, kun at vores svartider og loadet på databaseserveren er faldet :)

Til mere avancerede databaseapplikationer (CMS er typisk ret simpelt) foretrækker jeg da også PostgreSQL :)

Tine Müller

Der mangler drupal-udviklere i allerhøjeste grad, så hvis du er arbejdsløs eller trænger til jobskifte så giv PHP + Drupal en chance og du kan få fast job samt høj løn i morgen eller start som freelancer.

Twitter-besked ang. jobs
RockyMtnPige Amelia Berkeley
So, to sum up: Drupal development jobs available at @peytz, @nodeone_dk @reloaddk @adaptdk and @tv2danmark. Yowza!

Jeg kæmper stadigvæk en brav kamp selv med at forstå dette fantastiske CMS-system som kan ALT, men jeg kan desværre ikke PHP som jo nok ville ha' gjort det hele nemmere, men jeg giver ikke op. I øvrigt skulle Drupal 7 være nemmere forlyder det.

Der er udsolgt DrupalCamp i denne weekend http://2011.drupalcamp.dk/

Jeg skulle også bruge Google Maps API 3, så er da selv stolt af mit projekt http://beta.findtoilet.dk/, men arbejder stadigvæk videre på det.

Log ind eller opret en konto for at skrive kommentarer

JobfinderJob i it-branchen

TDC skifter koncernchef efter faldende mobilomsætning

Jesper Stein Sandal Mobil og tele 14. aug 2015

Nyeste job

KurserStyrk dine evner med et kursus

Adobe Dreamweaver Grundlæggende

Hvornår: 2015-11-18 Hvor: Storkøbenhavn Pris: kr. 9950.00

JavaScript/jQuery grundlæggende

Hvornår: 2015-10-19 Hvor: Storkøbenhavn Pris: kr. 10200.00

Administering Microsoft SQL Server Databases [20462]

Hvornår: 2015-09-24 Hvor: Østjylland Pris: kr. 19975.00

Varmeinstallationer (DS 469)

Hvornår: 2015-09-15 Hvor: Midtsjælland Pris: kr. 3180.00

Playmakeruddannelsen

Hvornår: Hvor: Efter aftale Pris: kr. Efter aftale