1 Migratie van een website naar een nieuw contentmanagementsysteem Dries Blanchaert, Veerle Van Hauwenhuyse Promotor: prof. dr. Guy De Tré Begeleiders...
Migratie van een website naar een nieuw contentmanagementsysteem Dries Blanchaert, Veerle Van Hauwenhuyse
Promotor: prof. dr. Guy De Tré Begeleiders: Axel Hallez, ir. Tom Matthé Masterproef ingediend tot het behalen van de academische graad van Master in de toegepaste informatica
Vakgroep Telecommunicatie en informatieverwerking Voorzitter: prof. dr. ir. Herwig Bruneel Faculteit Ingenieurswetenschappen Academiejaar 2008-2009
Migratie van een website naar een nieuw contentmanagementsysteem Dries Blanchaert, Veerle Van Hauwenhuyse
Promotor: prof. dr. Guy De Tré Begeleiders: Axel Hallez, ir. Tom Matthé Masterproef ingediend tot het behalen van de academische graad van Master in de toegepaste informatica
Vakgroep Telecommunicatie en informatieverwerking Voorzitter: prof. dr. ir. Herwig Bruneel Faculteit Ingenieurswetenschappen Academiejaar 2008-2009
Voorwoord Deze masterproef vormt het slot van onze 1‐jarige opleiding in de toegepaste informatica. Hierin pasten we de opgedane kennis toe in de praktijk. We konden hierbij rekenen op de hulp en raad van verschillende mensen van de vakgroep TELIN. We willen hierbij onze promotor prof. dr. Guy De Tré bedanken voor het mogelijk maken van deze masterproef. Het was niet evident om op korte tijd tot een bevredigend resultaat te komen. Daarom willen we zeker onze begeleider lic. Axel Hallez bedanken voor zijn tijd en begeleiding bij het vormgeven van deze masterproef. We willen de systeembeheerders grd. Davy Moreels en ir. Philippe Serbruyns bedanken om toegang tot de TELIN webserver mogelijk te maken en onze daarbij horende vragen te beantwoorden. We konden met enkele concrete vragen ook terecht bij lic. Ronny Blomme van de vakgroep ELIS, waar we hem dan ook dankbaar voor zijn.
Toelating tot bruikleen De auteurs geven de toelating deze masterproef voor consultatie beschikbaar te stellen en delen van de masterproef te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze masterproef. 29 mei 2009 Dries Blanchaert
Veerle Van Hauwenhuyse
Universiteit Gent Faculteit Ingenieurswetenschappen Vakgroep Telecommunicatie en informatieverwerking Voorzitter: prof. dr. ir. Herwig Bruneel
Migratie van een website naar een nieuw contentmanagementsysteem Dries Blanchaert, Veerle Van Hauwenhuyse Promotor: prof.dr. Guy De Tré Begeleiders: Axel Hallez, ir. Tom Matthé Masterproef ingediend tot het behalen van de academische graad van Master in de Toegepaste informatica Academiejaar 2008‐2009
Samenvatting De huidige website van de onderzoeksgroep Database, Document & Content Management (DDCM) maakt gebruik van het inhoudbeheersysteem (Eng. content management system, CMS) TYPO3. Dit systeem wordt gebruikt voor grote bedrijfswebsites en is daarom te complex voor de noden van de DDCM website. Om verdere ontwikkeling van en interactie met de website te vereenvoudigen is een meer eenvoudig CMS, dat de nodige functionaliteit ondersteunt, wenselijk. Het CMS Drupal voldoet aan deze eisen. De hoofddoelstelling is om de DDCM website naar dit nieuwe systeem te migreren. Het resultaat is terug te vinden op http://telin.ugent.be/~dblancha/Drupal‐6.10/. Een eerste fase vormde de kennismaking met het systeem. Dit omvatte vooral algemene exploratie van de basismogelijkheden en trial en error testen. Na het configureren van bepaalde basisaspecten werd in een tweede fase nagegaan hoe het mogelijk was om tweetaligheid voor de volledige website te implementeren. Vervolgens werd in een derde fase functionaliteit toegevoegd die de website, zowel voor toekomstige webmasters als eindgebruikers, meer gebruiksvriendelijk moest maken. Ten slotte werd in een laatste fase de lay‐out (UGent huisstijl) van de website bepaald.
Hoofdstuk 1 – Inleiding 1.1 Website onderzoeksgroep De Universiteit Gent (UGent) is opgedeeld in faculteiten, vervolgens in vakgroepen en tenslotte in onderzoeksgroepen. Onderzoeksgroepen zijn thematische eenheden binnen een vakgroep waarvan de onderzoeksactiviteiten van haar personeelsleden zeer overlappend zijn. Een website voor een onderzoeksgroep kan gezien worden als een visitekaartje binnen de wetenschappelijke gemeenschap. Hier kan onder andere informatie weergegeven worden zoals contactgegevens, interesses en publicaties van personeelsleden en de projecten waarmee de onderzoeksgroep bezig is. Personen die personeelsleden van de onderzoeksgroep hebben ontmoet tijdens wetenschappelijke congressen kunnen op basis van de informatie op de website bijvoorbeeld besluiten om een samenwerkingsverband aan te gaan. Dit kan zowel onder de vorm van een gemeenschappelijk project als het wederkerig uitwisselen van expertise en informatie. In deze masterproef staat de website van de onderzoeksgroep Database, Document & Content Management (DDCM) centraal. Deze onderzoeksgroep maakt deel uit van de vakgroep Telecommunicatie en Informatieverwerking (TELIN) binnen de faculteit Ingenieurswetenschappen (FIRW). De huidige website van deze onderzoeksgroep is aan een update toe. Om een update of het ontwikkelen van een website te laten slagen, is het noodzakelijk te communiceren met de opdrachtgever(s). Omdat het onderwerp van deze masterproef rond de website van DDCM draait, was het voor ons noodzakelijk om de juiste vragen te stellen aan onze promotor en onze begeleider. Dit is een stapsgewijs proces. Initieel zijn de verwachtingen zeer algemeen. Naarmate het ontwikkelingsproces evolueert en de kennis van de ontwikkelaars over het gebruikte systeem toeneemt, kunnen meer concrete vragen gesteld worden. Hierbij leerden we het belang als ontwikkelaar om goed te weten waar men mee bezig is en wat de mogelijkheden en beperkingen zijn. We hebben ervoor gekozen om ook naar reeds bestaande websites van onderzoeksgroepen te kijken om ideeën op te doen. Een mooi voorbeeld hiervan is de
1
website van de onderzoeksgroep ‘Image Processing and Interpretation’ [1] (IPI). Deze onderzoeksgroep maakt ook deel uit van de vakgroep TELIN.
1.2 CMS en Drupal De inhoud van hedendaagse websites is veel dynamischer dan vroeger en doorgaans bevatten websites ook meer inhoud. Om deze stroom van informatie in goede banen te leiden is het noodzakelijk om aan inhoudsbeheer te doen. Een Content Management System (CMS) is het type software dat hiervoor wordt gebruikt. Het is vooral bruikbaar voor websites waarvan de inhoud regelmatig wordt aangepast of waar regelmatig nieuwe informatie wordt toegevoegd. Met behulp van een CMS is het mogelijk om zonder veel technische kennis gegevens op het internet te plaatsen. Een CMS kan worden gebouwd voor een specifieke toepassing, maar er zijn ook algemene beschikbaar. Sommige daarvan, onder andere Drupal, zijn onder een open source‐licentie gepubliceerd. Bij open source software is het zo dat de broncode steeds kan ingekeken en veranderd worden. Hierdoor kan men de software naar eigen noden en inzichten aanpassen. Dit is niet het geval bij closed source software. In tegenstelling tot een pagina per pagina opbouw van een website vereist het maken van een website met een CMS heel wat configuratie en exploratie. Het leren kennen van een CMS neemt een aanzienlijk deel in van het ontwikkelingsproces. Om te kunnen werken met een CMS is er dus eerst een kennismakingsfase. In deze fase leren de ontwikkelaars de basisfunctionaliteit van het systeem kennen. Dit kan via trial en error, het lezen van online documentatie of videotutorials en eventueel met behulp van een handboek [2]. De duur van deze fase hangt af van verschillende factoren, afhankelijk van de ontwikkelaars zelf en het soort CMS. Naast de basisfunctionaliteit kan er ook gezocht worden naar uitbreidingen voor het systeem. Dit moet allemaal gebeuren in functie van het eindresultaat zodat men doelgericht kan zoeken naar extra functionaliteit. Bij het kennismaken van een CMS en het opbouwen van een website is het aan te raden om lokaal te werken. Op die manier heeft de ontwikkelaar ruimte om verschillende dingen uit te proberen en kan hetgeen goedgekeurd is op de online versie van het CMS geplaatst worden. Wanneer men met meerdere ontwikkelaars werkt aan een website is het nog 2
sterker aan te raden om elk lokaal te werken zodat men geen hinder van elkaar ondervindt tijdens de kennismakingsfase en het verder uittesten van functionaliteit. Voor het eindproduct kan men dan samenwerken op een gemeenschappelijk toegankelijke server. De vertraging die men oploopt door een langdurige kennismakingsfase is slechts eenmalig. Bij een volgend ontwikkelingsproces met dezelfde CMS kan deze fase immers overgeslagen worden. Ook voor ons was het nodig om aan het begin van onze masterproef zo'n kennismakingsfase te doorlopen aangezien dit onze eerste kennismaking met een CMS in het algemeen en met Drupal in het bijzonder was. In deze masterproef maken we gebruik van het CMS Drupal versie 6.x. Drupal werd oorspronkelijk ontwikkeld door Dries Buytaert en is geprogrammeerd in PHP. Dit is een goede programmeertaal voor het ontwikkelen van dynamische websites en is compatibel met verschillende besturingssystemen zoals Linux, Windows en Mac OS X. Drupal werd uitgebracht onder de GNU General Public License [3] (GPL). Dit is een licentie voor open source software. Deze licentie stelt dat men met de software mag doen wat men wil (inclusief aanpassen en verkopen). Dit echter onder de voorwaarde dat men dit recht ook moet doorgeven aan anderen en de auteur(s) van de software vermelden. Iedereen kan zijn of haar programma onder de voorwaarden van deze licentie publiceren. Drupal is modulair opgebouwd. Dit wil zeggen dat functionaliteit gesegmenteerd is in afzonderlijke onderdelen die nagenoeg naadloos met elkaar (zouden moeten) samenwerken. Bij een basis Drupal installatie zijn standaard enkele kernmodules meegeleverd. Dit zijn vaak modules die hun handigheid reeds bewezen hebben en door velen gebruikt worden. Om nieuwe functionaliteit toe te voegen, moet men extra modules installeren via de module download pagina op de Drupal website [4]. Deze modules vallen ook onder de GPL en zijn ontwikkeld door vrijwilligers die deel uitmaken van de Drupal gemeenschap. Deze gemeenschap stelt een zeer grote hoeveelheid modules ter beschikking. Dit aantal is zodanig groot dat het beter is om eerst te weten welke soort extra functionaliteit men wil toevoegen. Zo kan men doelgericht op zoek gaan naar een geschikte module. Sommige van deze modules overlappen in de aangeboden extra functionaliteit. Om een goede keuze te maken, is het belangrijk te weten wat men precies wil. Het aantal downloads kan ook een goede indicatie zijn voor 3
de kwaliteit van de module. De beschikbaarheid voor de gebruikte Drupal versie is ook een factor die meespeelt bij de keuze voor een module. Het achterliggende principe van de Drupal gemeenschap kan men samenvatten als: ‘Men hoeft niet opnieuw het wiel uit te vinden om snel de nodige functionaliteit voor de website die men voor ogen heeft te implementeren’. Eens men kiest voor een module is het noodzakelijk om op een oppervlakkige manier al de mogelijkheden van de module te bekijken. Soms kan men dingen ontdekken die zeer nuttig zijn, maar waar men zelf nog niet aan gedacht had. Het toevoegen van een extra module kan namelijk heel wat veranderen in de reeds bestaande structuur van configuratie‐elementen. Zo kunnen er op verschillende plaatsen extra opties bijkomen. Het is belangrijk om goed na te denken over welke modules men wil toevoegen aan de website. Dit omdat elke module de software zwaarder maakt. Dit kan de performantie doen dalen. Het is dus niet zo dat een website met meer modules noodzakelijk een betere website is. Het is belangrijk om met zo weinig mogelijk modules zo'n uitgebreid mogelijke functionaliteit te realiseren. Daarnaast maken extra modules het beheer van de website ook ingewikkelder en is het voor de administrator ook meer werk om de website goed te onderhouden. Tijdens onze masterproef hebben we dan ook veel modules lokaal uitgetest alvorens te beslissen welke modules we op de uiteindelijke website zouden implementeren.
1.3 Probleemstelling Wanneer men kiest voor een CMS is vooral de gebruikservaring van belang. Daarbij stellen we ons de volgende vraag: 'Voldoet het CMS aan de noden van de opdrachtgever?’ of met andere woorden: 'Is het CMS de beste keuze voor de website die we voor ogen hebben?' De huidige website van de onderzoeksgroep DDCM is opgebouwd met het CMS TYPO3. Dit soort CMS is een veel gebruikt en zeer krachtig CMS dat zich vooral focust op de bedrijfswereld. TYPO3 is in staat om alle functionaliteit te bieden die men wenst te implementeren, anders zou men er vroeger niet voor gekozen hebben. TYPO3 heeft echter één groot nadeel. De grote flexibiliteit die het biedt, leidt tot een onnodige complexiteit. Dit zorgt voor een trage leercurve. Deze investeringskost is valide 4
voor grote en complexe websites voor bedrijven. Voor een relatief eenvoudige website met een relatief lage updatefrequentie zoals de DDCM website, is dit systeem onnodig zwaar. Het CMS Drupal is in staat dezelfde functionaliteit aan te bieden met een snellere leercurve. Dit laat toe om in de toekomst op een meer eenvoudige manier te interageren met de website vanuit een ontwikkelingsstandpunt. We zijn tot deze conclusie gekomen op basis van een voorzichtige vergelijking van online gebruikersgetuigenissen en websites van bedrijven die gespecialiseerd zijn in CMS oplossingen. Voor een gedetailleerde vergelijking tussen Drupal en TYPO3 kan men terecht bij de CMS Matrix website [5].Deze organisatie biedt ook de mogelijkheid om een vergelijking te maken tussen verschillende andere CMS'en. Wanneer de inhoud en functionaliteit van een CMS worden overgezet naar een andere CMS spreken we van een migratie. Het is de bedoeling dat we de website van de onderzoeksgroep DDCM migreren naar Drupal 6.x om te voorzien in een groter gebruiks‐ en onderhoudsgemak. Dit is dan ook de hoofddoelstelling van deze masterproef. Hierbij is het de bedoeling om de huidige functionaliteit te behouden. Daarnaast zijn aanpassingen die de gebruiksvriendelijkheid verhogen zowel vanuit het standpunt van de leden van de onderzoeksgroep als vanuit het standpunt van de bezoekers van de website gewenst.
1.4 Installatie Om Drupal te kunnen installeren op een lokale machine is het noodzakelijk om eerst een ontwikkelingsomgeving te installeren. Deze moet bestaan uit een webserver (e.g. Apache), een database (e.g. MySQL) waarin Drupal gegevens kan bewaren en men moet voorzien in ondersteuning voor de PHP scriptingtaal van Drupal. Het opzetten van een ontwikkelingsomgeving kan eenvoudig gerealiseerd worden door het installeren van een geïntegreerd pakket. We hebben gekozen voor het WAMP (Windows Apache MySQL PHP) pakket. Om hetzelfde te bekomen in een Linux of Mac OS X systeem kan men respectievelijk de LAMP of MAMP pakketten gebruiken. Een migratie van een Drupal website tussen de verschillende ‐AMP pakketten is relatief eenvoudig. Men moet hiervoor enkel de database en de Drupal directory kopiëren. De 5
mogelijkheid van migratie naar andere platformen is bij onze masterproef van belang omdat naar alle waarschijnlijkheid bij de deployment van de website zal gebruik gemaakt worden van Linux als besturingssysteem. Voor deze masterproef gebruiken we elk lokaal de WAMP‐omgeving als standaard op een PC met Windows XP. Daarnaast werd er ook getest met Drupal op een MacBook via de MAMP omgeving. Voor de gemeenschappelijke ontwikkeling van het eindproduct maakten we gebruik van een Drupal installatie op een weblocatie van de vakgroep (telin.ugent.be/~dblancha/Drupal‐6.10) die ons werd toegewezen. Deze website draait op een Linux machine (Ubuntu) via Apache. Om een basis Drupal website te installeren moeten we eerst het installatie‐archief op de Drupal website downloaden. De Drupal bestanden moeten uitgepakt worden in de webpublicatiemap van de ontwikkelingsomgeving. Voor de WAMP installatie is dit de map www. Dit maakt de Drupal website toegankelijk in een browser op de lokale machine via het adres localhost of door het ingeven van het eigen ip‐adres. De WAMP installatie voorziet via phpMyAdmin in een eenvoudige interface om MySQL databases te beheren. Voor we beginnen aan de setup van de Drupal website via de browser is het de bedoeling dat we via phpMyAdmin een database aanmaken. Hiervoor moeten we eerst een gebruiker aanmaken via phpMyAdmin. Daarna maken we de database aan en kennen we aan de zonet aangemaakte gebruiker alle lees‐ en schrijfrechten toe voor deze database. We hoeven zelf geen tabellen aan te maken in deze database omdat Drupal hierin zelf voorziet. Daarna gaan we via de browser naar de Drupal website setup. Deze is te bereiken via localhost/Drupalmapnaam. Eerst kunnen we een taal kiezen voor de software. Dit kan in het Engels, wat de standaard is, maar onder andere ook in het Nederlands. Vervolgens kunnen we de naam van de database ingeven en de accountgegevens van de gebruiker voor toegang tot deze database. Daarna volgen enkele triviale instellingen zoals het ingeven van de naam van de website en een algemeen e‐ mailadres voor notificaties. Daarnaast worden nog 2 belangrijke waarschuwingen tijdens de installatieprocedure gegeven. Een eerste waarschuwing is een standaard waarschuwing die voorkomt bij elke installatie ongeacht het soort ontwikkelingsomgeving. Ze luidt als volgt: 'Maak een kopie van het bestand ./sites/default/default.settings.php en noem het ./sites/default/settings.php. Zorg ervoor dat dit bestand schrijfbaar is, zet 6
permissies op 644.' Het getal 644 heeft betrekking op een bepaalde configuratie van schrijf‐ en leesrechten. Dit kan ingesteld worden via de bestandseigenschappen, zoals wordt weergegeven in Figuur 1. De tweede waarschuwing gaat over schone URL's. Om schone URL's mogelijk te maken, moet de Apache module rewrite_module geactiveerd worden. Dit is mogelijk via het Apache menu‐item van de WAMP menulijst. Tenslotte moeten de mod_rewrite lijnen in 2 configuratiebestanden (httpd.conf bestanden) worden uitgecommentarieerd zodat schone URL's worden toegelaten. In sommige gevallen, zoals bij onze website, moet er een aanpassing worden gemaakt in het .htaccess bestand om mod_rewrite te doen werken. Dit doet zich voor wanneer de website zich in een subdirectory van de server bevindt. De aanpassing bestaat eruit dat men het basispad naar de submap moet aangeven in de Rewrite base / lijn [6], e.g. bij onze site: Rewrite base /~dblancha/Drupal6.10. Wat schone URL’s precies zijn en waarom ze gebruikt
worden, wordt beschreven bij de Path module in Hoofdstuk 2.
1.5 Ingebruikname Voor de officiële ingebruikname van de website kan plaatsvinden, zal de effectieve inhoud van de site nog aangepast worden. De huidige inhoud van onze website is vooral bedoeld als test en voorbeeld van de mogelijkheden die we hebben geïmplementeerd. Bij de deployment van de website, dit is het overplaatsen van een website naar de officiële serverlocatie, moeten er nog enkele belangrijke taken worden uitgevoerd: 1. Ten eerste moeten alle hardgecodeerde elementen worden opgezocht die verwijzen naar /~dblancha/Drupal‐6.10/. Onze basismap heeft een verwijzing naar de oorspronkelijke versie. Ondertussen zijn er echter reeds 2 security updates gebeurd. Het was dan ook beter geweest als onze basismap een algemene naam had gehad zoals /Drupal/. Dit is immers veel gebruiksvriendelijker bij het verplaatsen van de map en voorkomt verwarring over de versie van Drupal. 2. Tijdens de ontwikkeling van een website is het gebruik van de cache niet handig omdat veranderingen dan moeilijk waar te nemen zijn. Bij het actief maken van de website mag deze cache wel aangelegd worden. Deze functie vindt men bij 'Site‐instellingen' onder de 7
rubriek 'Prestatie'. Caching is belangrijk omdat het de performantie van de website aanzienlijk verhoogd. 3. Ook de instelling wat er moet gebeuren bij de rapportage van fouten wordt best aangepast bij deployment. Zo wordt de instelling 'Schrijf fouten zowel in de log als op het scherm' best veranderd naar 'Schrijf fouten in de log'. Het is niet nuttig voor eindgebruikers om de fouten te zien op het scherm aangezien zij hier toch niets aan kunnen doen en het hun gebruikservaring niet opwaardeert. Enkel bevoegde personen kunnen iets doen aan deze fouten en kunnen deze opzoeken in de log. Tijdens de ontwikkelingsfase zijn fouten op het scherm uiteraard wel handig.
8
Hoofdstuk 2 ‐ Kernfunctionaliteit van Drupal In dit hoofdstuk bespreken we de kernfunctionaliteit van Drupal 6.x. Meer concreet gaat het hier over de kernmodules die aanwezig zijn nadat de installatie van Drupal voltooid is. Een module is een stukje software, geschreven in PHP, dat de kenmerken en/of de functionaliteit van Drupal uitbreidt. Er zijn 2 soorten kernmodules, nl. verplichte kernmodules en optionele kernmodules. De verplichte kernmodules worden weergegeven op de modulepagina in het administratormenu, meer bepaald bij ‘Site‐ constructie’ onder de rubriek ‘Modules’. Men kan deze niet uitschakelen. De optionele kernmodules staan ook aangegeven op de modulepagina. Men kan uit deze modules kiezen welke men wil activeren en daarna rechten instellen voor de gebruikersrollen. In Drupal is het namelijk mogelijk om rollen in te stellen. Men kan aan elke rol dan verschillende rechten toekennen die nodig zijn om deze rol uit te voeren. Elke gebruiker in Drupal kan dan 1 of meerdere rollen toegewezen krijgen. Meer over de gebruikers van onze website wordt beschreven in Hoofdstuk 6. Er zijn naast de kernmodules ook extra modules die men apart kan downloaden zoals in sectie 1.2 reeds werd aangegeven. Hierbij is het belangrijk erop te letten dat de module overeenkomt met de versie van Drupal die men geïnstalleerd heeft. Na het downloaden moet men de module uitpakken in de map sites/all/modules in de Drupal map. Het is ook belangrijk om oog te hebben voor afhankelijkheden. Sommige modules zijn namelijk afhankelijk van andere modules zoals te zien is op Figuur 2. Hierbij is het nodig de oudermodule te activeren voordat de andere module kan geactiveerd worden. Het is ook niet mogelijk een oudermodule te deactiveren wanneer een afhankelijke module geactiveerd is. Dit is een handige beveiliging in het systeem van Drupal. Hieronder geven we een overzicht van de verschillende kernmodules van Drupal 6.x [7]. Waarbij we eerst de 5 verplichte kernmodules bespreken. o Block Een blok bestaat uit een groep gerelateerde informatie, zoals menu‐items of recente blogposts. Blokken staan meestal langs de zijkant van een website, maar ze kunnen ook 9
elders geplaatst worden. Blokken kunnen volledig zelf gemaakt worden door code toe te voegen. Ze worden echter meestal gecreëerd door modules. Blokken kunnen geactiveerd worden of gedeactiveerd en het is ook vrij eenvoudig om ze als administrator te verplaatsen in de opdeling van de pagina. Deze module gebruikten we om ons menu een plaats te geven en het inlogvenster te verplaatsen naar een aparte pagina om in te loggen. Ook de taalkeuze konden we hiermee activeren en bovenaan de website plaatsen. De onderverdeling in blokken op onze website is te zien in Figuur 3. o Filter Deze kernmodule zorgt ervoor dat men kan vastleggen welke formaten geldig zijn bij het invoeren van tekst op de website. Zo kunnen bijvoorbeeld maar bepaalde HTML tags toegelaten worden of kunnen juist bepaalde HTML tags verboden worden. Op die manier kan men voorkomen dat gebruikers slechte of gevaarlijke code toevoegen aan de website. Er zijn reeds enkele inputformaten beschikbaar bij de installatie van Drupal, daarnaast kan de administrator ook extra inputformaten maken. Wanneer gebruikers dan tekst toevoegen op de website kunnen ze kiezen welk inputformaat ze gebruiken. Hun keuze is beperkt door de keuzes die de administrator voor hen beschikbaar maakt. o Node De inhoud van de website wordt opgeslagen in nodes. Elke node heeft een unieke URL gegeven door het systeem. Deze URL kan ook aangepast worden door de Path module. Elke node heeft een auteur, een titel en een berichttekst. Er kunnen categorieën toegewezen worden aan nodes en bijlagen aan toegevoegd worden. o System Deze module zorgt voor bepaalde taken die het systeem moet uitvoeren om goed te blijven werken. Bijvoorbeeld ‘cron jobs’ en het opslaan van webpagina's in de cache voor meer efficiëntie. Cron is een 'scheduler' die zich op de server bevindt en taken uitvoert, ‘cron jobs’ genaamd, op verschillende intervallen, die de admistrator kan opgeven. Cron kan ook handmatig uitgevoerd worden. Wanneer het enige tijd geleden is dat cron 10
gelopen heeft, kan Drupal de administrator hiervan op de hoogte brengen via een waarschuwing (Figuur 4). o User Door deze module kunnen gebruikers zich registreren, inloggen en uitloggen. Op deze manier wordt de inhoud die gecreëerd wordt door gebruikers geassocieerd met hun account en kunnen bepaalde rollen aan hen toegewezen worden. Gebruikers kunnen meer dan 1 rol toegewezen krijgen. Elke gebruiker heeft een individuele 'mijn account'‐ pagina waarop onder andere staat hoe lang de account al bestaat. Er zijn nog verdere personaliseringen mogelijk afhankelijk van de rechten die de gebruiker heeft. We vermelden hieronder de optionele kernmodules, waarvan de door ons gebruikte kernmodules in het vet worden aangeduid. o Aggregator Deze module zorgt voor het publiceren van gesyndiceerde inhoud. o Blog Hierdoor kan men een blog voorzien voor elke gebruiker. o BlogApi Met deze module kan men posts maken vanuit de blog tools. o Book Een boek (Eng. book) is een groep pagina’s die verbonden zijn in een bepaalde volgorde, bijvoorbeeld in hoofdstukken, secties… Men kan boeken gebruiken voor handboeken, FAQ’s… Gebruikers met de nodige toelating kunnen een boek aanmaken en pagina’s schrijven, nakijken, aanpassen of ordenen. Aan 1 boek kunnen meerdere gebruikers werken. Dit kan door de administrator nauwkeurig vastgelegd worden. Aan de onderkant van de boekpagina’s staan links om naar de vorige pagina, de volgende pagina en een niveau hoger in de structuur te gaan. Deze links worden door Drupal automatisch toegevoegd. Er wordt ook een link toegevoegd naar een printvriendelijke versie van een
11
boekpagina en zijn subsecties (Figuur 5). Met deze module konden we de pagina's met de onderzoeksthema's makkelijk bereikbaar maken voor de bezoekers van de website. o Color Deze module laat de gebruiker toe om het kleurschema van bepaalde thema’s op een eenvoudige wijze aan te passen. o Comment Door het activeren van deze module laat men toe dat er commentaar wordt gegeven bij de webinhoud. o Contact Deze module vormt een manier om gebruikers met elkaar in contact te laten komen. o Content translation Deze module laat toe dat inhoud vertaald wordt in verschillende talen. Hij werkt samen met de module Locale en is nodig om een website in verschillende talen te maken. De Internationalisatie module die we later toevoegden voor onze meertalige website is afhankelijk van deze module. o Dblog Deze module heet ook Database Logging. Hij monitort het systeem en plaatst alle gebeurtenissen in een logboek. Dit kan dan later door bijvoorbeeld de administrator bekeken worden en geeft een overzicht van de activiteiten op de website. In het logboek wordt ook de volgorde van de gebeurtenissen bijgehouden, wat bruikbaar kan zijn bij het debuggen van de website. Het logboek wordt best regelmatig nagekeken door de administrator(s) om na te gaan of de website werkt zoals het hoort. o Forum Door het activeren van deze module is het mogelijk voor de gebruikers om in een forum discussies te voeren.
12
o Help De Help module toont contextgevoelige hulpteksten. Dit helpsysteem kan niet aangepast worden door de administrator. Wanneer men een nieuwe module maakt, kan men echter wel helptekst toevoegen die dan via deze module getoond zal worden. o Locale Deze module laat toe om de website in een andere taal dan het standaard Engels te tonen. Met deze module wordt het mogelijk om een meertalige website te maken of bepaalde standaardtekst te veranderen. Wanneer deze module tekst tegenkomt die getoond moet worden, zal deze de tekst proberen te vertalen naar de geselecteerde taal. Wanneer een vertaling niet voorhanden is, zal de string onthouden worden en kan men deze string later gemakkelijk opzoeken. Dit wordt verder uitgebreid besproken in sectie 2.3. o Menu Deze module zorgt voor een interface om het menusysteem van Drupal te controleren en aan te passen aan de eigen noden. Menu’s bestaan uit een hiërarchische lijst van links, die getoond worden in blokken, met behulp van de module die hierboven reeds werd beschreven. Standaard is het navigatiemenu aanwezig en 2 lege menu’s nl. primaire links en secundaire links. Deze laatste zijn sets van links die meestal getoond worden in de header of de footer van elke pagina, afhankelijk van het gebruikte thema. Men kan voor elk menu gebruik maken van de primaire of secundaire links. De administrator kan echter nog meerdere menu’s aanmaken. o OpenID De OpenID module zorgt ervoor dat gebruikers met een OpenID kunnen inloggen. o Path Deze module zorgt ervoor dat men URL aliassen kan maken voor de pagina’s van de website. Zo maakt Drupal voor elke node automatisch een URL, maar deze is niet echt gebruiksvriendelijk. Bijvoorbeeld: www.mijnwebsite.be/?q=node/67 . Door het gebruik 13
van aliassen verkrijgt men dan een URL zoals www.mijnwebsite.be/?q=alles‐over‐ olifanten. Dit kan echter nog gebruiksvriendelijker en properder gemaakt worden door het inschakelen van de functie ‘schone URL’s’. Drupal geeft argumenten door aan zichzelf via dynamische gegenereerde URL's in de vorm van .../?q=argument(en). De opbouw van deze URL's met '?q=' maakt ze slecht leesbaar en maakt het moeilijk voor zoekmachines om zulke websites te indexeren. De schone URL functie laat toe om deze tekenreeks weg te laten. Het voorbeeld wordt dan www.mijnwebsite.be/alles‐over‐olifanten. Deze module is vereist voor de goede werking van de module Pathauto (zie sectie 4.2). o PHP filter Door deze module kan men PHP code toevoegen in posts. o Ping De Ping module voorziet in een meldingsservice voor het melden van veranderingen. o Poll Dit laat de gebruikers toe om te stemmen. o Profile Deze module laat toe dat de geauthenticeerde gebruikers van de website informatie over zichzelf kunnen delen met elkaar door het opstellen van een profielpagina. Als administrator kan men bepalen welke velden de gebruikers kunnen invullen. o Search Hierdoor wordt een intern zoeksysteem voor de website geactiveerd. o Statistics Deze module houdt bepaalde statistieken over de website bij. Bijvoorbeeld verwijzingen naar de website, hoe vaak een bepaalde pagina bezocht wordt… o Syslog Deze module zorgt voor besturingssysteem geïntegreerd loggen.
14
o Taxonomy Taxonomy voorziet in een manier om inhoud te organiseren. o Throttle Deze module zorgt voor congestiecontrole. Congestie komt voor wanneer de server waarop de website draait te veel belast wordt. o Tracker Tracker maakt het eenvoudig om nieuwe en vernieuwde inhoud terug te vinden en te bekijken. o Trigger Trigger kent acties toe aan systeemgebeurtenissen. o Update status Deze module behoort pas sinds Drupal 6.x tot de kern. Bij vorige versies was het een externe module die men kon downloaden. Deze module gaat regelmatig na of er nieuwe versies van de software beschikbaar zijn. Dit geldt zowel voor de algemene Drupal installatie als voor de extra modules en thema’s. De module meldt aan de administrator wanneer er nieuwe updates beschikbaar zijn. Tevens kan men als administrator naar een logboek gaan kijken waar alle beschikbare updates worden weergegeven met een link om ze te downloaden. Deze module maakt dat de website makkelijker te onderhouden is en dat de administrator niet steeds zelf in de gaten moet houden of er updates beschikbaar zijn. o Upload Deze module laat gebruikers toe om bestanden online te plaatsen.
15
Hoofdstuk 3 – Meertaligheid 3.1 Een multilinguale website Net zoals bij de portaal website van de UGent en vele andere websites op het UGent domein hebben we ervoor gezorgd dat de webinhoud zowel in het Nederlands als het Engels beschikbaar is. We kozen voor Nederlands omdat dit de officiële onderwijstaal is aan de UGent en voor Engels omdat dit de voertaal is in de wetenschappelijke wereld. Om meertaligheid in Drupal mogelijk te maken, voegden we de Internationalisatie (i8n) module toe. Deze module werkt samen met 2 kernmodules, nl. Content translation en Locale. Deze 3 modules samen bezorgden ons de nodige functionaliteit om een meertalige website mogelijk te maken. In de toekomst kan men op een eenvoudige manier nog andere talen toevoegen indien beheerders dit wensen. Bij het toevoegen van nieuwe inhoud moet men enkel aangeven in welke taal de inhoud werd ingevoerd. Daarna kan men via een vertaalfunctionaliteit een kloon in een andere taal aanmaken (Figuur 6). Zo kan men dan de inhoud aanpassen door bijvoorbeeld het verwijzende menu‐item en de tekst te vertalen. De 2 nodes, die een vertaling zijn van elkaar, worden door Drupal aan elkaar gelinkt. Wanneer men met een speciale functie, de taalkeuze (Eng. language switcher) die standaard in Drupal zit, wisselt tussen beide talen, krijgt men de vertaalde inhoud te zien. Indien men informatie wil invoeren die onafhankelijk is van de taal waarin de website staat, kan men inhoud ook labelen als taalneutraal. We kozen ervoor om deze Internationalisatie module als eerste extra module toe te voegen omdat het tot een vrij grote wijziging in Drupal leidt. Zo moet men onder andere na installatie van de module voor elk inhoudstype meertaligheid activeren. De i8n module heeft echter ook enkele belangrijke tekortkomingen en omdat ze ook een effect hebben op onze website bespreken we ze kort. Ten eerste is niet alles in de gebruikersinterface vertaald. Bij installatie kozen we voor het Nederlands en om meertaligheid te verkrijgen activeerden we ook het Engels. De vertaling naar het Engels is echter niet altijd volledig en dan blijft in de Engelstalige gebruikersinterface de Nederlandse uitleg staan. Dit is onhandig wanneer er een anderstalige persoon inhoud zou willen toevoegen via de Engelse interface. Voor de anonieme bezoekers levert dit 16
geen problemen op. Ten tweede kan niet alle inhoud op de website worden vertaald. De vertaling van de standaard inhoudtypes zoals pagina's en boeken is in orde. De problemen ontstaan echter wanneer we zelf nieuwe inhoudstypes willen definiëren met behulp van de Content Construction Kit (CCK) module (zie sectie 4.4). Hierbij worden de veldnamen niet automatisch vertaald. Een eerste idee om dit probleem te omzeilen was zeer omslachtig. We wilden voor elk nieuw inhoudstype ook een vertaald inhoudstype definiëren. Dit is echter geen optimale oplossing omdat men dan meer mogelijkheden creëert voor het maken van fouten bij het invoeren van inhoud. Het is ook niet bepaald gebruiksvriendelijk. Daarom besloten we dit als noodoplossing in het achterhoofd te houden en verder te zoeken naar een betere oplossing. We kozen voor een efficiëntere oplossing door gebruik te maken van de mogelijkheid tot stringvertaling van de Locale module. Deze wordt besproken in de volgende sectie. Deze oplossing werkt echter niet voor alle vertaalproblemen. Bij andere modules die later worden besproken zoals de modules Biblio, Personeel en Views worden bepaalde onderdelen van de inhoud niet opengesteld voor vertaling.
3.2 Stringvertaling Om de beperkte samenwerking met andere modules op te vangen, beschikt de Locale module over een aparte manuele vertaalfunctie die stringvertaling noemt. Met deze functionaliteit is het mogelijk om om het even welke string die voorkomt op de website afzonderlijk te vertalen. Dit is van toepassing op zowel de inhoud van de website als de volledige beheerdersinterface. Het achterliggende idee is dat van alle stringelementen waaruit de website bestaat een indexering wordt gemaakt zodat we deze strings via een zoekfunctie kunnen terugvinden. De zoekresultaten zijn voorzien van de nodige contextinformatie om het juiste item tussen de zoekresultaten te vinden. Het is belangrijk om op te merken dat deze zoekfunctie hoofdlettergevoelig is. Daarnaast is het ook aangeraden om regelmatig de stringlijst up te daten zodat recent toegevoegde elementen ook kunnen gevonden worden. Dit kan men bij ‘Site‐constructie’ onder de rubriek ‘interface vertalen’. Wanneer een element niet kan gevonden worden via de zoekfunctie bestaat er een manier om dit element alsnog toe te voegen aan de stringlijst. Hiertoe moet men letterlijk op codeniveau de string tussen haakjes plaatsen met een t ervoor. 17
Deze t() functie wordt verder uitgelegd in sectie 5.2.3 waar we de module Personeel bespreken. Dit zorgt ervoor dat een string in PHP zoals Professors via de constructie t('Professors') eenvoudig kan gevonden worden met de zoekfunctie. Hierna kunnen
we de Nederlandse vertaling Professoren invullen in een tekstveld zodat dit zichtbaar is op de Nederlandstalige personeelspagina. We zijn er echter niet in geslaagd om volledige arrays en afzonderlijke stringelementen van arrays te vertalen. Dit is de reden waarom bijvoorbeeld de kolomtitels van de personeelstabellen niet vertaald zijn naar het Nederlands.
18
Hoofdstuk 4 – Gebruiksvriendelijkheid We hebben gepoogd onze website zo gebruiksvriendelijk mogelijk te maken. Dit zowel voor de bezoekers van de website als voor de leden van de onderzoeksgroep. Voor deze laatste groep moet het mogelijk zijn om op een eenvoudige manier inhoud toe te voegen en eventueel te verwijderen. Daarnaast hebben we geprobeerd ervoor te zorgen dat het onderhoud van de website ook vlot kan verlopen zodat men zonder veel tijdsverlies de website up to date kan houden.
4.1 Foutmeldingen Drupal voorziet de mogelijkheid om een aparte pagina weer te geven bij de 2 meest voorkomende foutmeldingen. Een eerste foutmelding is deze met code 403. Deze treedt op wanneer een gebruiker geen toegang krijgt tot een bepaalde pagina. Een tweede foutmelding met code 404 treedt op wanneer de inhoud niet gevonden wordt. Wanneer er geen paden worden opgegeven naar zelfgemaakte foutmeldingspagina's voorziet Drupal in een standaard foutmelding. Bij deze foutmeldingen wordt vertaling ook ondersteund. Het opgeven van paden naar zelfgemaakte pagina’s kan via het menu ‘Site‐instellingen’ onder de rubriek ‘foutrapportage’.
4.2 URL‐Aliassen Omdat alle webinhoud in Drupal wordt opgeslagen in nodes krijgt elke inhoud, ongeacht het type, een volgnummer. Standaard zullen paden aangeduid worden met www.mijnwebsite.domein/.../node/nummer in plaats van meer logische URL’s. Om URL’s meer gestructureerd en op een logischere manier weer te geven hebben we daarom de Pathauto module toegevoegd. Voor de goede werking van deze module is de kernmodule Path vereist. Deze laatste module maakt het mogelijk dat URL’s aliassen krijgen, waarop Pathauto verder bouwt.
19
Eens Pathauto geïnstalleerd is, wordt bij de aanmaak van om het even welk type inhoud automatisch voorzien in een logisch relatief pad. In de praktijk wordt dit pad de titel van de node. Het gebruik van logische padnamen maakt het ook veel eenvoudiger om manueel links toe te voegen naar andere pagina’s op de website. Het is immers gemakkelijker om de naam van een pagina (e.g. projecten) te onthouden in plaats van het volgnummer van een pagina (e.g. node/35). Ook voor gebruikers zijn deze URL’s veel duidelijker en leesbaarder.
4.3 Navigatie Een duidelijke menustructuur is essentieel om ervoor te zorgen dat de gebruiker gemakkelijk toegang heeft tot de inhoud van de website. In Drupal zijn er standaard 3 types menu’s: de primaire links, de secundaire links en het navigatiemenu. Het navigatiemenu is het menu dat getoond wordt wanneer gebruikers inloggen. De inhoud van dit menu hangt af van de toelatingen van elke gebruiker. Het navigatiemenu is vooral van belang voor het beheer van de website. De administrator kan via dit menu de website op rechtstreekse wijze beïnvloeden. Wat essentieel is voor de gebruikers zijn de primaire links. Dit is het typische hoofdmenu van een website dat gebruikt wordt om de verschillende hoofdsecties van een website te bereiken. Omdat het menu van de oorspronkelijke DDCM website zeer duidelijk en overzichtelijk was, hebben we het overgenomen. We hebben er extra aandacht aan besteed om de menustructuur in beide talen zo gelijk mogelijk te maken. Dit om ervoor te zorgen dat het niet vreemd aanvoelt wanneer een gebruiker tussen beide talen toggelt. Om er voor te zorgen dat de menu‐ items in de juiste volgorde staan, niet per se alfabetisch, hebben we gewichten toegevoegd aan de items. Deze gewichten zijn een ingebouwde functionaliteit in Drupal die ervoor zorgen dat menu‐items worden gerangschikt volgens hun opgegeven zwaarte. Hoe hoger het gewicht hoe lager het item zal geplaatst worden. Net zoals in de oorspronkelijke website hebben we het menu linksboven geplaatst. Dit is een opvallende plaats zonder dat het menu teveel afleidt van de hoofdinhoud. Bij een goede en toegankelijke website zijn niet enkel de menu’s van belang, maar ook de verdere navigatie doorheen de website moet duidelijk en intuïtief zijn. Bij de 20
onderwijspagina werd er bijvoorbeeld met links binnen de pagina gewerkt om eenvoudig van de top van de pagina naar een vak te gaan en omgekeerd. De onderzoeksthema’s beslaan meerdere pagina’s. Om eenvoudige navigatie tussen deze pagina’s mogelijk te maken, hebben we een extra inhoudstype gebruikt, namelijk ‘books’. Door het gebruik van boeken is het mogelijk om inhoudstypes te sorteren alsof ze samen een boek vormen. Het hoofdniveau van het boek is de hoofdpagina van de onderzoeksthema’s. Alle afzonderlijke thema’s zijn de opeenvolgende pagina’s van het boek waardoor men kan bladeren. Bij een boekpagina (met uitzondering van de hoofdpagina) vindt men telkens onderaan 3 links terug. Links onderaan staat een link naar de vorige pagina uit het boek, centraal staat een link naar de hoofdpagina en rechts een link naar de volgende pagina (Figuur 5). Dit is het eenvoudigste geval met slechts 2 niveaus. Uiteraard kan men ook een boek maken met meerdere niveaus. Dit inhoudstype, in de kern van Drupal inbegrepen, laat de gebruiker toe om gemakkelijk te navigeren tussen de verschillende onderzoeksthema’s en ondertussen een overzicht over het geheel te bewaren. Tenslotte zorgt het er ook voor dat we het hoofdmenu, ondergebracht in de primaire links, niet moeten uitbreiden met een extra item per thema. Dit zou het hoofdmenu nodeloos ingewikkeld maken.
4.3.1 Problemen met de menustructuur Een klein nadeel dat we ondervinden bij het standaard menugedrag in Drupal is dat submenu’s dichtklappen wanneer men switcht tussen talen. Dit deed zich voor in het standaard thema van Drupal, genaamd Garland. In ons eigen thema, genaamd ddcm, werken we met uitschuifbare menu’s wanneer men er met de muis overheen gaat. Op die manier is er geen probleem meer bij het wisselen van taal. Ondanks de goed uitgewerkte manier om menu’s aan te maken, kregen we soms te maken met een menu‐item dat niet meer op zijn juiste plaats stond of menu’s met submenu’s die niet meer wilden openklappen. We zijn er tot op heden nog niet uit hoe het komt dat een menu‐item plots bij zijn anderstalige tegenhanger komt te staan. We veronderstellen echter dat het iets met de vertaalfunctie van de website te maken heeft. Hier zijn echter op z’n minst 3 modules bij betrokken waardoor het moeilijk is te 21
achterhalen waar het probleem vandaan komt. Zoektochten op internet naar gelijkaardige ervaringen hebben voorlopig nog niets opgeleverd. Het feit dat menu’s met submenu’s plots niet meer uitklappen, blijkt nog voor te komen. We vonden hier enkele topics over in de Drupal gemeenschap. Toch konden hier geen sluitende oplossingen voor gevonden worden. Er wordt wel gemeld dat dit probleem zich vooral kan voordoen wanneer meer dan 1 menu‐item naar dezelfde locatie verwijst. Dit was bij ons menu‐item ‘Onderzoek’ het geval aangezien dit menu‐item verwijst naar de rubriek ‘Thema’s’, het submenu dat zich er direct onder bevindt. We vonden dat een mogelijke oorzaak van het probleem het opgeven van volledige URL’s als pad voor de menulink kon zijn [8]. Hierop gingen we onze menulinks na en vonden hier en daar volledige URL’s die we dan ook aanpasten naar hun kortere versies. Hierdoor was ons probleem opgelost. Al blijkt uit ervaringen van anderen uit de Drupal gemeenschap dat dit geen garantie is dat het probleem zich niet meer voordoet.
4.4 Inhoud toevoegen Een van de belangrijkste aspecten van een CMS is dat na de kennismaking met het systeem het eenvoudig wordt voor gebruikers om nieuwe inhoud toe te voegen. De administrator van een Drupal website, die instaat voor de configuratie, kan het proces van inhoudcreatie aanzienlijk beïnvloeden. Om invoer in het algemeen vlotter te laten verlopen, hebben we door de FCK‐editor module te installeren een WYSIWYG‐editor (What You See Is What You Get) toegevoegd (Figuur 7). Dit zorgt ervoor dat men bij tekstvelden niet met HTML tags moet werken om structuur of lokale opmaak toe te voegen. Daarnaast maakt een WYSIWYG‐editor het ook veel eenvoudiger om links of figuren toe te voegen. Dit is vooral nuttig voor mensen met minder technische kennis die graag een rijke inhoud willen toevoegen. We hebben voor de FCK‐editor module geopteerd in plaats van andere editors omdat deze het meest gedownload wordt. Dit is een sterke indicatie dat deze editor veel wordt gebruikt en er dus ook meer kans is op uitgebreide ondersteuning in geval van problemen.
22
Om de gebruiksvriendelijkheid te verhogen, kan de administrator op voorhand verschillende soorten inhoudstypes definiëren. Het voordeel voor de persoon die publiceert, is dat reeds heel wat functionaliteit op maat gemaakt is waardoor men sneller nieuwe inhoud kan toevoegen. Naast snelheid kunnen de voorgedefinieerde velden dienen als een geheugensteun voor wie nieuwe inhoud publiceert. Voor de bezoeker van de website is het gebruik van inhoudstypes gebruiksvriendelijk omdat inhoud op deze manier veel meer gestructureerd en gelijkmatig wordt weergegeven. De structuur van de informatie wordt onder andere duidelijk door goed gekozen labels voor de verschillende velden waarin de informatie werd ingevoerd. Daarnaast kan het gebruik van verplichte velden bij inhoudstypes ervoor zorgen dat inhouden van een bepaald type gemakkelijk kunnen doorzocht en geordend worden. De standaardinstallatie van Drupal bevat helaas geen mogelijkheden om nieuwe inhoudstypes aan te maken. Daarom hebben we de CCK module geïnstalleerd. Deze stelt ons in staat om nieuwe inhoudstypes aan te maken waarbij we velden met verschillende datatypes kunnen toevoegen.
4.4.1 Inhoudstype ‘project’ Een concrete realisatie van een zelfgemaakt inhoudstype in deze masterproef is het inhoudstype ‘project’. Dit type werd aangemaakt om de invoer van projecten waarmee de onderzoeksgroep bezig is, te vereenvoudigen. Na een gesprek met onze opdrachtgevers hebben we een structuur voor de projecten vastgelegd (Figuur 8). Eerst en vooral is het verplicht om een begin‐ en einddatum voor een project op te geven. Dit stelt ons in staat om projecten op basis van datum te sorteren. Het biedt ons ook de mogelijkheid om een onderscheid te maken tussen projecten die reeds afgehandeld zijn of die nog steeds lopen binnen de onderzoeksgroep. Om datumvelden mogelijk te maken, hebben we de module Date moeten installeren omdat Drupal standaard enkel velden met getallen of tekst ondersteunt. De Date module laat onder andere toe om een algemeen datumformaat en een lokale tijdzone voor de website te specificeren. Ten tweede hebben we een optioneel contactveld toegevoegd. Hierin kan het e‐mailadres van de verantwoordelijke voor dit project geplaatst worden. Dit laat toe dat geïnteresseerden 23
meer te weten kunnen komen over dit project door een e‐mail te sturen naar die contactpersoon. Standaard is er geen e‐mailveld opgenomen in de CCK module. Hiervoor bestaat er echter wel een extra module Email die speciaal bedoeld is om e‐mailvelden toe te voegen aan de CCK module. Ten derde hebben we een veld genaamd projecttype toegevoegd. Dit is ook een optioneel veld waarmee men kan aangeven of het gaat om een samenwerkingsverband en/of via welke organisatie het project wordt gefinancierd. Dit projecttype is een gewoon tekstveld omdat er heel veel verschillende soorten projecttypes mogelijk zijn. Mochten er slechts een beperkt aantal keuzemogelijkheden geweest zijn, konden we ook een veld aanmaken met een keuzelijst bestaande uit voorgedefinieerde waarden. Tot slot is er ook de mogelijkheid om een beschrijving van het project toe te voegen.
4.5 Onderhoud 4.5.1 Updates Zoals we reeds aangaven in onze inleiding is er een hele gemeenschap actief rond Drupal. Hierdoor wordt er constant gewerkt aan de software om deze veilig te houden, te verbeteren... Wat natuurlijk tot gevolg heeft dat er regelmatig updates uitkomen. Als administrator wordt men hier zeer snel van op de hoogte gebracht via de Update status module, zoals reeds beschreven in Hoofdstuk 2. Voor deze masterproef startten we met Drupal 6.10. Tijdens ons ontwikkelproces kwamen er 2 beveiligingsupdates uit, versie 6.11 en 6.12. Dit terwijl er in de gemeenschap ook reeds druk gewerkt wordt aan Drupal 7.x en men Drupal 5.x nog steeds onderhoudt. Het updaten van Drupal is even werk, zeker wanneer men dit voor de eerste keer doet. Er is echter voldoende uitleg voorhanden. Zo bevat de update een tekstdocument (upgrade.txt) waarin stap voor stap wordt beschreven hoe de update dient uitgevoerd te worden. Daarnaast bestaan er ook online video’s waarin het updateproces wordt voorgedaan. Als administrator kost het dus enige tijd om het updateproces in de vingers te krijgen, maar dit proces blijft grotendeels hetzelfde, waardoor het de volgende keren stukken vlotter gaat. Om na te gaan of er nieuwe updates voor handen zijn, moet men af en toe bij de sectie ‘Rapporten’ nagaan of er nieuwe updates beschikbaar zijn bij de 24
rubriek ‘Beschikbare Updates’. Bij een nieuwe beveiligingsupdate van het Drupal systeem zelf krijgt de administrator overal de volgende waarschuwing te zien met een downloadlink naar de nieuwe bestanden: "Er is een beveiligingsupdate voor de Drupal versie van deze website beschikbaar. Om de veiligheid van deze server te verzekeren moet u het systeem direct opwaarderen naar de nieuwste versie. Ga naar de pagina beschikbare updates voor meer informatie." Het is aan te raden om eerst het bestand upgrade.txt volledig door te lezen voor men aan de upgrade begint. Dit bestand bevindt zich in de map van de nieuwe Drupal basisinstallatie. In wat volgt, baseren we ons op de structuur van het bestand upgrade.txt om het updateproces te overlopen. Stap 1 Eerst moeten we voor de veiligheid een back‐up maken van onze Drupal database. Wanneer er iets fout zou gaan met de update kan men gemakkelijk de database herstellen en gaat geen informatie verloren. Het updaten van de database moet voor ons via phpMyAdmin [9] gebeuren. Daar gaat men naar de database en klikt men dan op de Exporteertab. Op deze pagina staan automatisch alle tabellen geselecteerd. Indien men maar bepaalde tabellen nodig heeft, kan men deze afzonderlijk in de lijst selecteren. Het is belangrijk ervoor te zorgen dat data en structuur aangevinkt staan en het SQL formaat aangevinkt staat. Daarnaast moeten we ook een back‐up maken van onze Drupal installatie, in het bijzonder van de map ‘sites’, omdat deze allerlei aangepaste en toegevoegde bestanden bevat die niet tot de Drupal basisinstallatie behoren. Dit zijn onder andere het configuratiebestand en toegevoegde modules en thema's. Ook van het .htaccess bestand moet een back‐up gemaakt worden omdat het aangepast werd na de eerste installatie. De Drupal map kopiëren we via een FTP cliënt. Stap 2 Om de update uit te voeren, logt men best in met gebruikersID 1, dit is de account van de hoofdadministrator. Deze gebruiker heeft automatische toegang tot update.php.
25
Stap 3 Plaats de website in off‐line mode. Dit is nodig om de update te laten werken zonder onderbreking en om te voorkomen dat eindgebruikers foutmeldingen te zien krijgen op de website in het geval het gaat om een reeds operationele website. Deze optie is te vinden bij 'Site‐instellingen' onder de rubriek 'Site‐onderhoud'. Hierbij is het belangrijk de browser te laten openstaan tot de update volledig voltooid is. Stap 4 Schakel over naar een kernthema. Dit is een thema dat meegeleverd wordt met de basisinstallatie. Deze stap is nodig omdat de extra thema’s niet in de basisinstallatie zitten en pas na de update weer toegevoegd worden. Om problemen te voorkomen moet men de update dus uitvoeren met een kernthema, zoals bijvoorbeeld Garland. Stap 5 In deze stap moeten alle zelfgemaakte en toegevoegde modules uitgevinkt worden. De kernmodules mogen aan blijven staan. Om zeker te zijn welke modules of onderdelen van modules actief waren, kan men een paar screenshots nemen voor het uitvinken. Stap 6 De mappen en documenten van de Drupal installatie moeten hierna verwijderd worden. Een probleem bij onze installatie is dat er een bepaald javascript op de locatie .../sites/default/files/languages niet verwijderd kan worden. Dit zorgt verder niet voor problemen. Stap 7 Wanneer de Drupal map leeg is, kunnen de vernieuwde bestanden in de plaats komen. Hiervoor moet de nieuwe Drupal installatie uitgepakt worden en op de locatie waar men zonet de vorige Drupal installatie verwijderd heeft, geplaatst worden. Stap 8 Vervang hierna de nieuwe 'sites' map met de oude map die in stap 1 gekopieerd werd. Daarnaast moet men in de basismap het nieuwe .htaccess bestand terug aanpassen. De aanpassingen die wij doorvoerden, bestaan erin dat we onderaan de RewriteBase lijn 26
uitcommentarieerden en het pad van de server naar de basismap opgaven: RewriteBase /~dblancha/Drupal6.10.
Stap 9 Een kleine doch belangrijke stap is het laten lopen van update.php. Dit bestand is te vinden via een link op de modulepagina of rechtstreeks via de basismap, in ons geval: /~dblancha/Drupal‐6.10/update.php. Stap 10 Hierna kan men weer alle modules activeren. Hiervoor kan men, indien deze gemaakt werden, de screenshots gebruiken. Ook nu moet men update.php laten lopen. Stap 11 Indien de website normaal niet in een kernthema getoond wordt, kan men nu de website terug in het oorspronkelijke thema zetten. Stap 12 Tenslotte kan men de website weer beschikbaar stellen voor de gebruikers door de website uit off‐line mode te halen. Ook modules kunnen een update krijgen. Zo kunnen er bugs uitgehaald of extra functionaliteit aan toegevoegd worden. Deze updates worden, wanneer ze beschikbaar zijn, gemeld aan de administrator via de Update status module. Voordat men een module updatet, is het best om eerst een back‐up te nemen van de Drupal database. Als er dan iets fout loopt in het update proces, kan men de back‐up gebruiken om opnieuw te beginnen voor de update begon. Een nieuwe versie van een module installeren, verloopt vrij eenvoudig. Eerst deactiveert men de module, daarna verwijdert men de bestaande module en plaatst de nieuwe versie van de module in de plaats. Dit alles zonder de bestaande module te deïnstalleren. Daarna is het belangrijk om update.php te laten lopen zodat de database kan aangepast worden indien nodig.
27
4.5.2 Linkchecker module Onze website bevat verschillende links zowel interne als externe. Interne links zijn links die verwijzen naar pagina's binnen de eigen website. Externe links zijn links die verwijzen naar andere websites. Het is mogelijk dat na enige tijd een link breekt. Dit wil zeggen dat de link niet meer werkt. Een externe link kan bijvoorbeeld breken wanneer de URL van deze website verandert. Een interne link kan breken wanneer men een aanpassing doet op de eigen website waardoor de verwijzing niet meer klopt. Elke keer wanneer men aan de eigen website werkt, zou men moeten nagaan of men niet zonder het te weten een link verbroken heeft. Omdat men geen controle heeft over de externe URL’s zou de administrator ook regelmatig moeten nagaan of deze externe links nog werken. Dit alles neemt veel tijd in beslag en meestal zullen de links intact zijn. Om zo een tijdverlies te vermijden, bestaat er een extra module. Om het onderhoudsgemak van onze website te verhogen, kozen we er dan ook voor om deze module, genaamd Linkchecker, toe te voegen aan onze website. Deze module gaat na of alle links werken en geeft in een logboek weer welke links gebroken zijn. De administrator kan zelf instellen hoe vaak de links moeten nagekeken worden.
28
Hoofdstuk 5 – Bestaande inhoud In dit hoofdstuk bespreken we de manier waarop we de bestaande inhoud hebben proberen over te brengen naar het nieuwe systeem. Vooral de extra modules die we hierbij gebruikt hebben, komen uitgebreid aan bod.
5.1 Statische pagina’s Bij de overname van de bestaande inhoud van de originele DDCM website maakten we gebruik van het inhoudstype 'pagina'. Met behulp van de FCK‐editor konden we hier gemakkelijk enige lay‐out aan toevoegen en links implementeren. Enkel voor het gedeelte over de onderzoeksthema's kozen we voor een aanvulling met een ander inhoudstype, namelijk een boekstructuur. Hierdoor wordt het voor de bezoekers gemakkelijker om te bladeren tussen de verschillende onderzoeksthema's zonder een overzicht op het geheel te verliezen. Deze boekstructuur kan men zien als een geordende verzameling van pagina’s zoals eerder in sectie 4.3 werd uitgelegd. De contact‐pagina op de originele website bevat 2 figuren, een foto van het gebouw waarin de onderzoeksgroep gelokaliseerd is en een plan met de omliggende straten. Deze figuren wilden we op zo'n efficiënt mogelijke wijze invoegen op de pagina. Hiervoor probeerden we verschillende modules, uiteindelijk kozen we niet voor deze modules omdat ze niet precies deden wat we wilden. Ze boden vaak ook meer functionaliteit dan voor deze website en deze 2 figuren nodig was. Indien nodig kan deze functionaliteit later nog altijd gemakkelijk toegevoegd worden. We probeerden de Image module, deze module zorgt ervoor dat gebruikers, indien toegelaten, figuren kunnen uploaden in Drupal. De module zorgt hierbij voor miniatuurafbeeldingen (Eng. thumbnails) en verschillende groottes. Door deze module konden we figuren toevoegen als nodes. We hoopten om dan via links in HTML tags of via de linkfunctie van de FCK‐editor deze nodes als figuren te kunnen toevoegen. Dit werkte echter niet en deed ons ook beseffen dat de node met de afbeelding uit meer 29
bestond dan enkel en alleen een afbeelding. Het deed ons inzien dat een node altijd een volledige datastructuur omhelst. Omwille van deze mislukking en de overbodige functionaliteit van de Image module hebben we besloten deze module niet te gebruiken. We dachten er ook over de IMCE module te gebruiken. Deze module wordt ook frequent gebruikt in de plaats van de Image module. Het is een module die ervoor zorgt dat men gemakkelijk figuren en documenten kan uploaden. Daarnaast wordt deze module ook vaak met rich text editors gebruikt zoals onder andere met FCK‐editor. Toch bleek ook deze module niet handig voor de 2 figuren die we maar nodig hadden. Daarnaast hebben we ook geprobeerd om met de InsertNode module te werken. Deze module laat toe om nodes in elkaar te nesten. Deze module toonde echter ook geen figuren op de pagina waarin we de node hadden toegevoegd. We hebben dan besloten om deze module ook niet te gebruiken. Zoals hierboven beschreven hebben we behoorlijk wat tijd nodig gehad om te begrijpen, via het uittesten van modules en het lezen van de Drupal documentatie, dat losstaande figuren die statisch worden toegevoegd aan een pagina moeten geupload worden in een aparte map op de server. Deze locatie is bij voorkeur /sites/default/files/images/. Dan kan er bij het toevoegen van tags gewoon verwezen worden naar het bestand op de server. Alhoewel deze oplossing triviaal lijkt, is het verwarrend omdat onze beginnerservaring immers de indruk gaf dat alle inhoud in Drupal normaal wordt bijgehouden in de database.
5.2 Dynamische pagina’s 5.2.1 Lijst van projecten Via de Views module is het mogelijk om informatie op een gestructureerde manier, volgens bepaalde criteria en op verschillende locaties weer te geven. Het is een complexe module met zeer veel mogelijkheden. Er kunnen verschillende views aangemaakt worden en van elke view kunnen we verschillende displays maken. Displays kunnen als inhoud van een pagina of als een blok die men in een van de zijbalken van de pagina kan plaatsen, weergegeven worden. We wilden deze module graag gebruiken om projecten in een lijst weer te geven. Dit om een direct overzicht van alle projecten te kunnen bieden aan de 30
bezoeker. Zo'n lijst maakt alle projecten ook gemakkelijk individueel toegankelijk zonder dat we aan elk project een menu‐item moesten toekennen waardoor het overzicht verloren zou gaan. Daarnaast wilden we ook een lijstweergave van de lopende en de reeds afgelopen projecten. Een voorbeeld van zo een lijst is te zien in Figuur 9. Bij deze laatste 2 lijsten stootten we echter op een probleem. Het is perfect mogelijk om op basis van het einddatumveld de projecten te filteren en te kiezen voor alle projecten waarbij de einddatum kleiner of groter is dan de huidige datum. Wanneer we deze filter echter willen verbergen voor de bezoekers, toont de view alle projecten in plaats van de lopende of afgelopen projecten. Wanneer we naar de SQL query kijken die gegenereerd wordt, zien we dat de filter ontbreekt ook al staat hij in het views menu aangeduid. Tot op heden hebben we hier geen oplossing voor gevonden ondanks het werken met verschillende displays en verschillende views. We hebben er uiteindelijk voor gekozen beide lijsten toch aan te maken en de filter zichtbaar te maken (Figuur 9). Op die manier is het voor de bezoekers ook mogelijk een andere filterdatum in te geven dan de standaard, namelijk. de huidige datum.
5.2.2 Publicaties Voor het weergeven van de publicaties van de onderzoeksgroep kozen we voor een dynamische weergave. Hiervoor besloten we in overleg met onze opdrachtgevers de Biblio module te gebruiken. Deze module laat toe dat gebruikers manueel hun publicaties invoeren aan de hand van voorgedefinieerde velden. Men kan er echter ook voor kiezen om reeds bestaande bibliografielijsten te importeren. De module ondersteunt verschillende formaten, meer bepaald BibTex, EndNote Tagged, EndNote 7 XML, EndNote 8 XML, MARC of RIS. Aangezien de onderzoeksgroep reeds over een database met deze informatie beschikt, werd ervoor gekozen om de bestaande gegevens te importeren in Biblio. We hebben hierbij 2 formaten uitgetest, namelijk BibTex en RIS. Beide formaten gaven echter kleine foutjes. Zo werden bij het BibTex document alle titels en vreemde tekens omgeven door accolades. Bij RIS werd er aan alle jaartallen 3 keer een '/' toegevoegd. Het laatste is echter gemakkelijk te verwijderen door gebruik van de functie ‘zoeken en vervangen’ voordat de import gebeurt.
31
Daarnaast merkten we dat in de oorspronkelijke gegevens sommige auteurs zowel in drukletters als gewoon weergegeven werden. Dit zorgde ervoor dat Biblio deze auteurs als 2 verschillende personen aanzag, wat natuurlijk fout is. Hier bestaat echter een oplossing voor in Biblio zelf. Er kan namelijk een samensmelting (Eng. merge) uitgevoerd worden tussen beide auteurs waarbij maar 1 van de schrijfwijzen behouden wordt. Dit gaat merkelijk sneller dan het manueel aanpassen van deze auteursnamen en voorziet duidelijk in een groter gebruiksgemak. De module geeft de bibliografie in een mooie lijst weer die op verschillende manieren gesorteerd kan worden. De administrator kan kiezen voor een sortering op jaar, auteur... Deze filter is volgens de standaardinstellingen niet zichtbaar voor de bezoekers, maar het is mogelijk dit in de toelatingen toch aan te vinken. We ondernamen eerst een poging om deze bibliografie gegevens ook aan de hand van een view weer te geven. Dit is mogelijk, maar geeft geen mooie publicatielijst weer. Men kan dit wel gebruiken als men bijvoorbeeld enkel de titels, met link naar de gehele node, wil tonen aan bezoekers. Omdat we een volledige bibliografie wilden weergeven, kozen we er dus voor om geen view te maken en de weergave van Biblio te behouden. Hiervoor maakten we een Nederlandstalige menu link en een Engelstalige menu link naar de weergave van Biblio. Het oorspronkelijke menu met extra mogelijkheden plaatsten we in het navigatiemenu en maakten het enkel zichtbaar voor geauthenticeerde gebruikers. Op die manier hebben de ingelogde gebruikers de mogelijkheid om via dit menu snel opzoekingen te doen in Biblio en extra bibliografieën te importeren. Een functionaliteit die niet direct nodig is voor bezoekers en voor wie we de menustructuur niet nodeloos ingewikkeld willen maken met allerlei functionaliteiten. Elke geauthenticeerde gebruiker van de website heeft publicaties die op een aparte pagina worden weergegeven. Het is echter belangrijk dat men als gebruiker zijn eigen publicaties kan bekijken. Er wordt dan ook door de module een link gelegd tussen de publicaties en de gebruikers. Wanneer men op een profielpagina kijkt, kan men ook de publicaties van de betreffende gebruiker bekijken. Anonieme gebruikers kunnen enkel de globale publicatielijst zien via het hoofdmenu. Wanneer de bezoekers echter in deze 32
publicatielijst op de naam van een auteur klikken, wordt de lijst gefilterd en enkel de bibliografie van die auteur getoond.
5.2.3 Personeelspagina Het was ook nodig om op de website een lijst weer te geven van het personeel van de onderzoeksgroep. Dit kan op verschillende manieren gerealiseerd worden in Drupal. Het is mogelijk om bijvoorbeeld een inhoudstype aan te maken met verschillende velden waarin men personen en informatie over hen kan ingeven. Hiervan kan men een view maken zodat de gebruikers een mooie lijst te zien krijgen. Dit is echter geen efficiënte manier om een personeelspagina te maken, want het zorgt voor redundante informatie omdat alle personeelsleden ook gebruikers met een eigen profiel zullen zijn op de website. Een tweede mogelijkheid is om via het profiel een lijst samen te stellen van alle geautenticeerde gebruikers, in dit geval de personeelsleden van de onderzoeksgroep. Hiervoor heeft men de Profiel module en de Menu module nodig. Dit zijn beide kernmodules van Drupal. Wanneer beide modules actief zijn, kan men in het navigatiemenu het item 'gebruikerslijst' activeren. Wanneer men wil, kan men dit item ook naar een ander menu verplaatsen. Dit item zorgt ervoor dat een pagina wordt weergegeven waar men een lijst van de gebruikers kan zien. Wanneer een persoon de toelating heeft om op de naam van de gebruikers te klikken, kan hij het profiel bekijken van deze gebruiker. Beide mogelijkheden voldeden echter niet aan de vraag van onze opdrachtgevers en zorgden voor redundantie. Er is echter een derde mogelijkheid waarbij gebruik gemaakt wordt van de gegevens op de Lightweight Directory Access Protocol (LDAP) server van de TELIN vakgroep. Door het gebruik van de LDAP server kunnen we redundantie vermijden en het aanpassen van de personeelslijst zo eenvoudig mogelijk maken. Doordat alle gegevens van de LDAP server komen, moeten enkel hier aanpassingen gebeuren en niet in de Drupal database. Dit is efficiënter en voorkomt fouten. We vonden echter geen module in de Drupal gemeenschap die informatie van een LDAP server kan samenbrengen op een pagina. De 33
LDAP integration module, die we gebruikten voor de authenticatie van de gebruikers, is hiervoor immers niet geschikt. Drupal is echter zo ontworpen dat men zelf modules kan ontwikkelen wanneer men geen module vindt voor de benodigde functionaliteit. Hiervoor is het wel nodig om documentatie rond het ontwikkelen van modules door te nemen en enigszins vertrouwd te zijn met PHP. Wij hoefden echter niet van nul te beginnen voor onze Personeel module. We konden gebruik maken van een reeds bestaande module, namelijk de module People die gebruikt wordt op de website van de IPI onderzoeksgroep. Deze onderzoeksgroep behoort tevens tot de vakgroep TELIN en heeft ook een website in Drupal. Onze uiteindelijke Personeel module is een aanpassing van deze module. De People module is speciaal voor de onderzoeksgroep IPI ontwikkeld om gegevens van de TELIN LDAP server te verzamelen en weer te geven. Deze module bevat echter meer dan enkel een personeelspagina. Deze extra functionaliteit was niet nodig voor de website van de onderzoeksgroep DDCM waardoor we deze module mochten aanpassen. We deleteten de stukken die we niet nodig hadden, veranderden de naam van de module naar Personeel en veranderden waar nodig IPI door DDCM. Aangezien het over dezelfde LDAP server ging, moest in dat stuk van de code niets veranderd worden. De oorspronkelijke module vereiste het gebruik van een andere extra module, namelijk Spamspan. Deze module zorgt ervoor dat e‐mailadressen op een bepaalde manier op de website verschijnen waardoor ze niet kunnen gebruikt worden door spambots. Deze module vonden we heel handig omdat de e‐mailadressen van de hele onderzoeksgroep online zouden komen en mogelijk ook contactpersonen voor projecten (zie sectie 4.4.1). We kozen er dan ook voor om de afhankelijkheid te behouden. Nadat we de overbodige code verwijderd hadden, merkten we echter dat de module geschreven was voor een oudere versie van Drupal. Hierdoor was de module nog niet direct bruikbaar voor ons omdat wij werken met versie 6.x. De module bestaat uit een modulenaam.info bestand en een modulenaam.module bestand. In beide moesten enkele aanpassingen gedaan worden. Het personeel.info bestand bevatte nog niet alle benodigde informatie. In het originele bestand werden enkel de naam van de module, de beschrijving en de afhankelijkheden 34
aangegeven. In versie 6.x is het echter een vereiste dat ook wordt aangegeven voor welke versie de module is geschreven. We voegden dus de volgende lijn toe: core = 6.x De verdere aanpassingen waren nodig in het document met de code van de module zelf, meer bepaald het personeel.module bestand. Bij de 'hook' menu moesten we de meeste aanpassingen doen in de code. Een ‘hook’ is een PHP functie die genoemd wordt naar de module en de naam van de ‘hook’. In ons geval werd dit: personeel_menu(). Een ‘hook’ zorgt er voor dat modules kunnen interageren met de kern van Drupal. Het hele module systeem van Drupal is dan ook gebaseerd op het concept van ‘hooks’. Elke ‘hook’ heeft een vaste set parameters en een gespecificeerd resultaatstype. Om Drupal te kunnen uitbreiden, moet een module een ‘hook’ implementeren. Wanneer Drupal interventies van modules wil toelaten, gaat het systeem na welke modules een ‘hook’ implementeren en dan wordt deze ‘hook’ opgeroepen in alle geactiveerde modules die deze ‘hook’ implementeren. De ‘hook’ menu zorgt voor het definiëren van menu‐items en ‘page callbacks’. Door deze ‘hook’ kunnen modules menu’s plaatsen in bijvoorbeeld het navigatieblok. De parameters van deze hook die in de bestaande module gebruikt werden, bestaan nog steeds in versie 6.x, maar sommigen kregen een andere naam. We zorgden er voor dat alle parameters de correcte naam kregen. Ook de variabele $may_cache was niet meer nodig en kon gewoon weggelaten worden. Hieronder geven we de oorspronkelijke code van de ‘hook’ weer na verwijdering van overbodige menu‐items: /** * Implementation of hook_menu(). */ function ipi_menu($may_cache) { $items = array(); if ($may_cache) { $items[] = array('path' => 'people', 'title' => t('People'), 'callback' => 'ipi_ipimembers', 'access' => 1, 'type' => MENU_NORMAL_ITEM);
35
} return $items; }
Na enkele aanpassingen werd dit de nieuwe code van de ‘hook’: /** * Implementation of hook_menu(). */ function personeel_menu() { $items = array(); $items['people'] = array( 'title' => t('People'), 'page callback' => 'personeel_ddcmmembers', 'access callback' => 1, 'type' => MENU_NORMAL_ITEM ); return $items; }
De bovenstaande code zorgt er dus voor dat er in het navigatiemenu een menu‐item, genaamd People, verschijnt. We verplaatsten dit item later naar het hoofdmenu van de website dat ook voor de bezoekers zichtbaar is. Zoals te zien is in bovenstaande code wordt People omgeven door de functie t(). Dit zorgt ervoor dat de betreffende string kan vertaald worden met behulp van stringvertaling. Hieronder volgt een stukje code uit de functie personeel_ddcmmembers() van de nieuwe module Personeel. $groups = array( t(' Professors') => "(&(telinResearch=$research_group)(telinStatus=ZAP))", t(' Associate professors') => "(&(telinResearch=$research_group)(telinStatus=AZAP))", t(' Researchers') => "(&(telinResearch=$research_group)(|(telinStatus=OAP)(telinStatus=AAP)))",
In bovenstaande code worden alle personeelsleden onderverdeeld in groepen. We voegden ook hier de functie t() in om de groepsnamen te kunnen vertalen. Zo konden we er bijvoorbeeld voor zorgen dat op de Engelstalige personeelspagina ‘Researchers’ stond en op de Nederlandstalige personeelspagina ‘Onderzoekers’. We wilden dit verder in de code ook doen voor de kolomnamen. Maar zoals reeds vermeld in sectie 3.2 over stringvertaling lukt het ons niet om de functie t() te doen werken bij arrays en afzonderlijke elementen van arrays. Per persoon werd reeds de naam, het e‐mailadres, de eventuele homepagina en het telefoonnummer weergegeven. Daarnaast voegden we zelf de benodigde PHP en HTML code toe om een foto toe te voegen in de personeelslijst. Dit naar analogie van de personeelslijst op de oorspronkelijke website van DDCM. De code die we hiervoor toevoegden, wordt hieronder weergegeven. $telinphoto = '';
Om deze nieuwe variabele $telinphoto ook weer te geven, voegden we ze toe in de daartoe bestemde array. $rows[] = array($telinphoto, $name, $email, $homepage , $telephonenumber);
37
Hoofdstuk 6 – Gebruikers 6.1 Inloggen Om gebruikers toegang te verschaffen tot bepaalde delen van de website is het nodig hen te laten inloggen. Oorspronkelijk staat het inlogvenster van Drupal aan de linkerkant op de pagina. We kozen er echter voor om een aparte inlogpagina te maken zoals bij de oorspronkelijke website. Deze inlogpagina is bereikbaar via het hoofdmenu. We kozen voor deze aparte inlogpagina omdat niet alle gebruikers waarvoor de website bedoeld is, horen in te loggen. Daarom leek het ons beter om deze inlogmogelijkheid wat minder duidelijk te profileren. Het verplaatsen van het inlogvenster was niet zo evident. Standaard is het inlogvenster zichtbaar op elke pagina van de website omdat het gedefinieerd is als een blok in de linker zijbalk. Het is echter mogelijk om bij de configuratie van blokken te werken met een insluit (Eng. include) of uitsluit (Eng. exclude) systeem. Door enkel het relatieve adres van de inlogpagina in te voegen in het insluit tekstgebied kunnen we er gemakkelijk voor zorgen dat de inlogmogelijkheid slechts op 1 pagina wordt weergegeven. Het addertje onder het gras is dat bij een foutieve invoer van het adres er geen inlogvenster meer zichtbaar is na uitloggen en men geen toegang meer heeft tot het administratorgedeelte van de website. Om dit euvel te voorkomen, hebben we tijdens de ontwikkeling ook de string toegevoegd aan het insluittekstveld zodat de inlogmogelijkheid ook altijd zichtbaar was op de frontpage. Daarnaast was het tijdens de ontwikkelingsfase ook handiger om reeds van op de frontpage te kunnen inloggen.
6.2 Soorten gebruikers Het is de bedoeling om slechts 2 types van gebruikers te definiëren. Dit zijn de anonieme gebruikers en de geauthenticeerde gebruikers. De anonieme gebruikers zijn de gewone bezoekers van de website. Zij kunnen enkel de bestaande inhoud bekijken en geen inhoud toevoegen, aanpassen of verwijderen. De geauthenticeerde gebruikers kan men opsplitsen in 2 groepen. Enerzijds is er de hoofdgebruiker of administrator. Via deze login is er volledige toegang tot het website beheer. Dit is de account waarmee we deze 38
website
ontworpen
hebben
en
die
zal
doorgegeven
worden
aan
de
hoofdverantwoordelijke voor de website nadat onze masterproef is afgerond. Anderzijds zijn er de personeelsleden van de onderzoeksgroep DDCM. Zij moeten in staat zijn om inhoud toe te voegen en eventueel aan te passen of te verwijderen. Ze kunnen ook rechten toegewezen krijgen om bepaalde aspecten van de website te beheren indien dit nodig zou zijn.
6.3 LDAP authenticatie Standaard zijn er binnen Drupal voldoende mogelijkheden voorzien om gebruikers manueel toe te voegen. Binnen de vakgroep TELIN kunnen we echter gebruik maken van hun LDAP server. Deze server bevat allerhande informatie over het personeel van de volledige vakgroep en kan ook gebruikt worden voor authenticatie via het gebruikersID en wachtwoord. Op die manier is het ook niet nodig dat de leden van de vakgroep een nieuw gebruikersID en wachtwoord bedenken. Om een Drupal website met een LDAP server te laten communiceren, bestaat de module LDAP Integration. Deze module bestaat uit 3 onderdelen: LDAP Authentication, LDAP Data en LDAP Groups. Het onderdeel LDAP Authentication is voor ons het meest relevante onderdeel. Dit onderdeel maakt het mogelijk om LDAP servers toe te voegen. Om de LDAP server van TELIN te kunnen gebruiken, moesten we een aantal gegevens invullen. Deze zijn: de domeinnaam ldap zonder meer, want dit wordt lokaal herkend, het poortnummer 389 en de basis DNS string ou=Users,dc=telin,dc=ugent,dc=be. Deze laatste, de basis DNS string, bevat de zoekparameters om de gegevens van de LDAP server op te vragen. Door de verbinding met de LDAP server via LDAP Authentication lukt het voor iedereen van TELIN om in te loggen op onze website. Dit is echter niet de bedoeling van onze opdrachtgevers. De geauthenticeerde gebruikers, waarover reeds gesproken werd in sectie 6.2, moeten behoren tot de onderzoeksgroep DDCM. Hierdoor moesten we dus proberen te voorkomen dat mensen uit de vakgroep TELIN die niet behoren tot de onderzoeksgroep DDCM kunnen inloggen. Dit probeerden we door de basis DNS string aan te passen en telinresearch=ddcm toe te voegen aan de bestaande string na. Dit
39
lieten we testen, maar ou=Users bleek niet te werken, want niemand kon nog inloggen via de LDAP server. We kregen de tip om in het configuratiebestand ldapauth.conf.php te gaan kijken, waar we een functie vonden die het waarschijnlijk mogelijk zou kunnen maken om verder te filteren. Ldapauth.conf.php bevat onder andere de volgende code: /** * Let users in (or not) according to some attributes' values * (and maybe some other reasons). */ function ldapauth_user_filter(&$attributes) { // Uncomment next line to see how the argument array looks like // msg_r($attributes); // Example: don't allow in users with no homeDirectory set. // return isset($attributes['homeDirectory'][0]) && $attributes['homedirectory'][0]; return TRUE; }
We zijn er echter niet in geslaagd om de lijn return isset ... aan te passen met gegevens uit de string telinresearch=ddcm. Omdat het ons niet gelukt is om inloggen door andere leden van TELIN te voorkomen, hebben we een andere, maar minder elegante, oplossing proberen toepassen. Het is namelijk mogelijk om via LDAP Groups, deel van de module LDAP Integration, de ingelogde gebruikers te filteren in bepaalde gebruikersrollen. Zo zouden leden van andere onderzoeksgroepen wel kunnen inloggen, maar een gebruikersrol toebedeeld krijgen waardoor ze niet meer kunnen doen dan een anonieme
bezoeker. Dit zou de rol ‘geverifieerde gebruiker’ zijn. De leden van de onderzoeksgroep DDCM zouden een andere gebruikersrol toegewezen krijgen, namelijk DDCM, met de permissies die ze nodig hebben. Het is ons echter niet gelukt om dit met behulp van LDAP Groups te laten werken.
40
Hoofdstuk 7 – Lay‐out 7.1 Thema’s Drupal bevat thema’s waarmee men de lay‐out van de website kan aanpassen. Er bestaan heel veel verschillende thema’s waarvan enkelen (e.g. Bluemarine, Minnelli) tot de basisinstallatie van Drupal behoren. Standaard staat Drupal ingesteld op het Garland thema. Daarnaast bestaan er ook veel thema's in de Drupal gemeenschap die vrij kunnen gedownload worden net zoals modules [10]. We gingen bij onze opdrachtgevers na welke lay‐out zij in gedachten hadden voor hun website. Het moest een professioneel ogende website worden die een goede indruk achterlaat bij al wie hem komt bezoeken. Er werd uiteindelijk gekozen voor de UGent huisstijl, omdat dit een reeds uitgewerkte stijl is die professioneel overkomt en de onderzoeksgroep ten slotte deel uitmaakt van de UGent. Er bestaan reeds enkele Drupal websites in het UGent domein die de UGent huisstijl implementeren [11] [12]. Zij hebben dus reeds een eigen thema aangemaakt volgens deze huisstijl. Met het open source gedachtengoed in het achterhoofd vroegen we of het mogelijk was om zo een thema te krijgen om te implementeren op onze website. We kregen zonder problemen het recentste thema, namelijk het thema dat gebruikt wordt voor de UGent LaTeX website. Het implementeren van de UGent huisstijl bleek echter niet zo eenvoudig en vlot te verlopen als verwacht. Het implementeren van het thema van de UGent LaTeX website op onze website was problematisch. De reden hiervoor was dat deze implementatie van de UGent huisstijl in Drupal niet meer up to date was ten opzichte van de nieuwe versie van Drupal die wij gebruikten. De door ons gekende thema‐implementaties van de UGent ELIS website en de UGent LaTeX website werken met Drupal 5.x of ouder. Wij werken echter met Drupal 6.x. Deze en toekomstige Drupal versies vereisen voor elk thema een themanaam.info bestand. Alhoewel het aanmaken van zo een bestand niet complex is, schenen er nog meer compatibiliteitsproblemen te zijn. We probeerden met behulp van online documentatie het UGent LaTeX website thema te herwerken naar de vereisten van Drupal 6.x [13]. Deze transitie vereiste echter een grote kennis van CSS en PHP wat het moeilijk maakte om te begrijpen welke veranderingen precies noodzakelijk waren. 41
Daarnaast was het ook niet eenvoudig een bestaand thema te doorgronden omwille van de vele afhankelijkheden tussen de bestanden onderling. Na enige tijd vruchteloos zoeken en proberen, besloten we om zelf een thema te ontwikkelen. Hiervoor zijn er 2 redenen. Een eerste reden is het falen om het bestaande thema om te vormen naar versie 6.x. Een tweede reden is de huisstijl van de UGent zelf. Deze heeft immers onlangs nieuwe aanpassingen ondergaan. Vanzelfsprekend wilden we graag de meest recente huisstijl gebruiken. Het zelf ontwikkelen van een thema is niet eenvoudig. Gelukkig zijn er goede informatiebronnen voorhanden in de Drupal gemeenschap om op een efficiënte wijze tot een relatief goed resultaat te komen. Er wordt aangeraden om vooral reeds bestaande eenvoudige thema's te gebruiken en te bestuderen bij het ontwikkelen. Bestaande basisthema's met gelijkaardige kenmerken als het thema dat men in gedachten heeft, kunnen een waardevolle bron van informatie zijn. Daarnaast hebben we vooral beroep gedaan op het hoofdstuk 'Chapter 8. The theme system' uit het boek Pro Drupal Development [14].
7.1.1 Opbouw van een thema Een thema bestaat uit verschillende elementen. Allereerst is er het themanaam.info bestand. Hierin wordt het thema gedefinieerd. Dit is vrij gelijkaardig aan het modulenaam.info bestand bij een module. Zonder dit type van bestand zal Drupal, tenzij in vroegere versies, het thema niet herkennen. Dit themanaam.info bestand bestaat uit gewone tekst die zowel verplichte als optionele informatie bevat. Als voorbeeld voegen we hieronder het volledige ddcm.info bestand toe van het door ons ontwikkelde thema ddcm: ; $id$ name = ddcm description = De layout voor de DDCM website werd ontwikkeld door Dries Blanchaert en Veerle Van Hauwenhuyse. Deze stijl is gebaseerd op box_grey. core = 6.x engine = phptemplate
42
regions[left] = Left sidebar ;We do not have a right sidebar. ;regions[right] = Right sidebar regions[content] = Content regions[header] = Header regions[footer] = Footer ; These appear on the theme config page features[] = logo features[] = name features[] = slogan features[] = mission features[] = node_user_picture features[] = comment_user_picture features[] = search features[] = favicon ;features[] = primary_links ;features[] = secondary_links ; Stylesheets can be declared here or, for more ; control, be added by Drupal_add_css() in template.php. ; Add a stylesheet for media="all": stylesheets[all][] = reset.css stylesheets[all][] = screen.css stylesheets[all][] = specific.css stylesheets[all][] = style.css ; Add a stylesheet for media="print": stylesheets[print][] = print.css
Het document bestaat uit sleutelwoorden gevolgd door een 'is gelijk aan' teken met daarnaast de waarde voor dat sleutelwoord. De sleutelwoorden name, core en engine zijn noodzakelijk voor een goede werking van het thema. De beschrijving van het thema is optioneel en is zichtbaar wanneer men in Drupal naar de themalijst gaat. Het toevoegen van een beschrijving wordt dan ook sterk aangeraden. Daarnaast hebben we nog de regio’s vermeld die door ons thema gebruikt worden en de elementen die op de configuratiepagina van het thema mogen verschijnen. Wanneer deze laatste 2 zaken ontbreken, wordt automatisch teruggevallen op de standaard. Als laatste worden in het 43
themanaam.info bestand de CSS bestanden vermeld die door het thema gebruikt worden. Meer over deze CSS bestanden volgt in sectie 7.2. Voor meer informatie over themanaam.info bestanden zie [15]. Naast het themanaam.info bestand bestaat een thema uit ‘template’ bestanden. Dit zijn de bestanden met de extensie .tpl.php wanneer men de phptemplate engine gebruikt. Deze bestanden worden gebruikt voor de HTML markup en PHP variabelen. Deze documenten zijn optioneel, in de zin dat wanneer ze ontbreken het thema zal terugvallen op de standaard bestanden die zich bevinden in de System module in de map modules. Om zelf een thema te ontwikkelen volgens de vernieuwde UGent huisstijl was het noodzakelijk om de verantwoordelijke voor de UGent huisstijl te contacteren. Via deze persoon (d.i. Dimitri Boone) konden we beschikken over de recentste CSS bestanden en ook over het index.htm bestand dat als referentie kon dienen om het bestand page.tpl.php mee op te bouwen. Via dit bestand konden we de basisstructuur van de website vastleggen. De PHP code in dit bestand bepaalt de lay‐out van de volledige website pagina. Daarnaast zijn er nog gespecialiseerde bestanden mogelijk zoals node.tpl.php, dat de lay‐out van de nodes bepaalt en block.tpl.php, dat de lay‐out van de blokken bepaalt. Deze bestanden kunnen nog verder toegespitst worden op een specifiek blok, een specifieke node… Voor ons was het niet nodig om veel verschillende ‘template’ bestanden toe te voegen. We bespreken later in sectie 7.1.3 de concrete opbouw van ons thema. Het is ook mogelijk om een template.php bestand toe te voegen. Dit document is niet verplicht, maar het kan gebruikt worden om de .tpl.php documenten proper te houden. Wanneer men een functie wil overschrijven, kan de code hier geplaatst worden. De functie in de template.php zal eerst opgeroepen worden voor de reeds bestaande functie. Het is beter om het overschrijven van functies in dit document te doen en niet in bijvoorbeeld het page.tpl.php bestand. In ons thema hebben we geen template.php bestand toegevoegd. Daarnaast bestaat een thema ook nog uit een style.css bestand en eventueel nog uit andere CSS bestanden, een logo en een screenshot. Deze laatste 2 zijn niet verplicht, 44
maar komen in de meeste thema's wel voor. Het logo voor onze website wordt echter niet doorgegeven door de variabele $logo, maar via een HTML tag. We voegden wel een screenshot toe omdat dit in de themalijst een indicatie geeft van hoe het thema er zal uitzien.
7.1.2 Het ugent thema Bij onze eerste poging tot het ontwikkelen van een thema vertrokken we vanuit het index.htm bestand dat we hernoemden tot page.tpl.php en aanvulden met PHP code. Dit bleek echter een poging die ons te veel tijd zou kosten om helemaal uit te pluizen. Ons zelf ontwikkelde thema vertoonde dan ook nogal wat gebreken. Het zag er vrij goed uit voor bezoekers, maar vooral voor de ingelogde gebruikers ging veel van de opmaak verloren. Zo was de opmaak van onze Biblio module verdwenen en tevens de opmaak in tabs waar extra functies staan voor ingelogde gebruikers (Figuur 10). We probeerden te achterhalen welke code in andere thema's in deze opmaak voorzag. We maakten hierbij gebruik van de Devel module. De Devel module is een module met functies die hulp bieden bij het ontwikkelen. We gebruikten hier een deel van de Devel module, namelijk Theme Developer. Deze module geeft aan welke functies bepaalde zaken vorm geven. Onze kennis over de werking van thema's en de benodigde HTML en PHP code was tijdens deze poging behoorlijk toegenomen, maar niet genoeg om bovenstaande problemen op te lossen. Deze eerste poging is terug te vinden als het thema ugent op de themapagina.
7.1.3 Het ddcm thema We besloten het over een andere boeg te gooien en onze opgedane kennis op een andere manier te gebruiken. We kozen voor een basisthema om daarin onze code en CSS bestanden toe te voegen. Dit is dus het omgekeerde van wat we eerst probeerden te doen. We kozen ervoor het thema box_grey als basis te gebruiken. Dit is een thema met een relatief eenvoudige code, wat het niet zo moeilijk maakt om het aan te passen wanneer men niet over een grote technische kennis beschikt. Dit thema is tevens het thema dat voor het Drupal thema van de UGent LaTeX website als basis diende. Vandaar dat we er vertrouwen in hadden om dit thema als basis te kiezen. We voegden de 45
benodigde figuren en CSS bestanden toe en pasten toen het page.tpl.php bestand van box_grey aan aan onze noden. Dit door ons eigen page.tpl.php bestand van het thema ugent, gebaseerd op index.htm van de UGent huisstijl, te vergelijken met het page.tpl.php bestand van box_grey. Op het einde voegden we ook een screenshot van het ddcm thema toe. De weergave van dit thema werd getest in verschillende browsers. Voor de ontwikkeling hebben we hoofdzakelijk Firefox 3.0 (zowel voor Windows XP als Mac OS X) gebruikt. Daarnaast hebben we de layout ook uitgetest op Microsoft IE 6 en 7, Opera 9.6 en Safari 3.2. Om een beeld te krijgen van de weergave in Firefox 3.0 verwijzen we naar Figuur . In Figuur 12 geven we een verschil met Firefox 3.0 aan in Opera 9.6.
7.1.3.1 ddcm thema: page.tpl.php Het volledige page.tpl.php bestand van het ddcm thema is te vinden in de bijlage. Hierbij hebben we alle veranderingen ten opzichte van het oorspronkelijke box_grey bestand aangeduid in het vet. In wat volgt zullen we bondig de grootste veranderingen bespreken. Tussen de tags van de HTML code verwijderden we de onderstaande lijn code. <meta httpequiv="ContentStyleType" content="text/css" />
Deze lijn is overbodig door de PHP code die eronder staat, namelijk . De variabele $head bevat de HTML code die gegenereerd wordt door de
functie Drupal_get_html_head() en die functie bestaat uit de volgende code: \n"; return $output . Drupal_set_html_head(); } ?>
46
Het was dus onnodig de hard gecodeerde lijn te laten staan. De code uit de $head variabele komt ook letterlijk overeen met de code uit het index.htm bestand van de UGent huisstijl. Verder voegden we tussen de tags ook nog enkele lijnen code toe. Zo wilden we de favicon van Drupal die automatisch gebruikt wordt, vervangen door de favicon van de UGent. Daarvoor plakten we onderstaande code uit het index.htm bestand.
Een favicon is het icoontje dat men naast de URL ziet in de browser. We voegden ook extra code toe voor de CSS aanpassingen die nodig zijn om ook in Microsoft Internet Explorer versie 6 en 7 een goede weergave te verkrijgen. Deze code wordt verder besproken in sectie 7.2 over CSS. De grootste veranderingen gebeurden tussen de tags van de HTML code. Het thema box_grey werkt met een tabel met 3 kolommen in de body. Deze code verwijderden we omdat de CSS bestanden van de UGent voor de pagina‐indeling instonden en we voegden de benodigde
blokken toe met de juiste klassen en id’s. Daarnaast verwijderden we de klassenamen en id’s in bestaande
blokken om ze te vervangen door de klassen en id’s van de UGent CSS bestanden. Elementen die we behielden en geen evenbeeld in onze UGent CSS bestanden hadden, bleven onveranderd. De meest opvallende veranderingen worden hieronder besproken, voor de uitgebreide details verwijzen we naar de bijlage. We voegden allereerst code toe om bovenaan op de website de taalkeuze weer te geven. We vonden niet welke variabele dit blok genereert, waardoor we gebruik maakten van de variabele $header. Deze variabele geeft alle blokken weer die in de header geplaatst zijn, bij ons was dit enkel de taalkeuze. Omdat we enkel beschikten over de variabele $header hebben we in het Drupal systeem zelf de standaardwaarden voor de taallabels, dit zijn Nederlands
en Engels moeten vervangen door respectievelijk NL en EN. De
oorspronkelijke code uit het index.htm bestand voor de taalkeuze hebben we verwijderd. 47
In het page.tpl.php bestand van box_grey wordt het logo van de website doorgegeven door een PHP variabele. Dit hebben we hier niet gedaan, we kozen ervoor om de code uit het index.htm bestand te behouden. In het
blok header dat reeds aanwezig was, voegden we de blokken headerleft en headerright toe volgens het model van index.htm. We kopieerden ook de code die hierin vervat zat, aangevuld met de juiste PHP variabelen. Zo werden onder andere de zoekfunctie, het telefoonboek en de A‐Z index toegevoegd. De broodkruimel (Eng. breadcrumb) wordt via een PHP variabele doorgegeven. In de oorspronkelijke versie kreeg deze geen verdere opmaak. Wij verpakten deze variabele in een
blok om deze van de juiste opmaak volgens de huisstijl te kunnen voorzien. Om de broodkruimel nog verder op te maken en er onder andere voor te zorgen dat de huidige pagina ook in de broodkruimel werd opgenomen, maakten we gebruik van de Menu breadcrumb module. We voegden ook op verschillende plaatsen code toe van de klasse hidden en de klasse Visual clear. Deze code bestond niet in het oorspronkelijke bestand, maar om de
huisstijl toch goed te volgen, voegden we deze code toe waar nodig. In het
blok dat de hoofdinhoud opmaakt, behielden we de meeste PHP code en opmaak. Enkel de PHP code die de titel van elke node weergeeft op de website verwijderden we. Dit omdat onze nodes zelf een titel bevatten en de nodetitel hierdoor overbodig was. Daarnaast verwijderden we tevens de code die het RSS feed icoon weergeeft omdat onze website niet werkt met RSS feeds. We voegden ook de code toe om het rechter kader met de 'Snel naar' links (Eng. Quick links) aan de rechterkant toe te voegen. De footer was oorspronkelijk vrij eenvoudig. Hierbij voegden we extra
blokken toe om de juiste opmaak voor de footer te kunnen realiseren en om de benodigde tekst en links toe te voegen. We zorgden er ook voor dat de tekst in de footer vertaalbaar werd
48
met stringvertaling. Dit deden we door de t() functie te plaatsen rond Reactions on content en Last change.
Op die manier verkregen we uiteindelijk het thema ddcm dat behoorlijk overeenkomt met de UGent huisstijl en tevens enkele problemen oploste uit onze vorige poging.
7.1.3.2 De menuweergave De menuweergave vormde in beide thema's een probleem. Op onze website maken we gebruik van een menu met meerdere onderverdelingen. Deze zagen er echter steeds hetzelfde uit. Het was dus onmogelijk om de ouder‐ en kinditems duidelijk visueel van elkaar te onderscheiden zonder dat men de menustructuur reeds kent. Dit is niet gebruiksvriendelijk en wilden we dus ook graag oplossen. Het menu wordt echter niet op een eenvoudige manier weergegeven en doordat het tweetalig is, zit het in een blok verpakt. Het lukte ons niet de benodigde CSS code aan dit bepaald blok te verbinden. We zorgden op een alternatieve manier voor een duidelijk zichtbare hiërarchie in onze menustructuur. Dit door de module Nice Menus te gebruiken, waardoor de menu’s naar rechts uitklappen wanneer men er met de muis over gaat (Figuur 13).
7.2 Cascading Style Sheets (CSS) De Drupal thema’s maken gebruik van CSS bestanden om de lay‐out van een website te verzorgen. Deze CSS bestanden worden echter op een specifieke manier toegevoegd in een thema. Elk thema bevat een CSS bestand dat meestal de naam style.css meekrijgt. Dit bestand wordt automatisch toegevoegd aan de variabele $styles. Deze variabele wordt met behulp van PHP code in de van het page.tpl.php bestand geschreven en zorgt ervoor dat dit bestand gelezen kan worden. Men kan echter nog andere CSS bestanden toevoegen. Deze moeten dan eerst in het themanaam.info bestand vermeld worden. Op die manier kunnen ze ook toegevoegd worden aan de variabele $styles. Tijdens de ontwikkelingsperiode is het cruciaal dat bij de rubriek 'Prestatie' van 'Site‐ instellingen' de optimalisatie van CSS bestanden uitgeschakeld staat omdat dit ervoor 49
zorgt dat aanpassingen bij het aanmaken van een thema niet worden gezien. Tevens is het belangrijk om het register van de thema‐elementen (Eng. theme registry) regelmatig leeg te maken. De thema‐informatie wordt namelijk gecached voor een betere prestatie. Dit wordt zelfs gedaan wanneer de cache op de website uitstaat. De 'theme registry' dwingen om zich te updaten kan op verschillende manieren. Het kan bijvoorbeeld door op de themapagina te wisselen van thema en dan weer terug of via de 'theme registry' link in de Devel module. Om de UGent huisstijl te implementeren hebben we zoals reeds vermeld de CSS bestanden
van
de
faculteit
Ingenieurswetenschappen
opgevraagd
bij
de
verantwoordelijke van de huisstijl. Om deze CSS bestanden te implementeren in ons thema plakten we ze in onze themamap bij het reeds aanwezige style.css bestand van het oorspronkelijke box_grey thema. Deze CSS bestanden zijn fix‐ie6.css en fix‐ie7.css die respectievelijk voorzien in compatibiliteit van de lay‐out in Microsoft Internet Explorer 6 en 7. Daarnaast waren er de basis CSS bestanden reset.css, screen.css en specific.css die de lay‐out volgens de UGent huisstijl voorzien. Tenslotte is er ook een print.css bestand om het afdrukken van webpagina's te optimaliseren. In het ddcm.info bestand werden zij op volgende manier toegevoegd: ; Stylesheets can be declared here or, for more ; control, be added by Drupal_add_css() in template.php. ; Add a stylesheet for media="all": stylesheets[all][] = reset.css stylesheets[all][] = screen.css stylesheets[all][] = specific.css stylesheets[all][] = style.css ; Add a stylesheet for media="print": stylesheets[print][] = print.css
Zoals uit dit stuk code blijkt, zijn de bestanden fix‐ie6.css en fix‐ie7.css niet toegevoegd in het ddcm.info bestand. Dit komt omdat deze CSS bestanden maar onder specifieke voorwaarden toegepast mogen worden. Ze mogen enkel gebruikt worden wanneer de website bekeken wordt met behulp van Microsoft IE 6 of 7. Hiervoor voegden we een 50
specifiek stuk code toe in het page.tpl.php bestand. Deze code detecteert de gebruikte browser en zorgt ervoor dat de juiste HTML code wordt uitgevoerd. <style type="text/css" media="all">@import "/fixie6.css"; <style type="text/css" media="all">@import "/fixie7.css";
Bij het testen van het thema merkten we dat de figuren niet werden weergegeven. Hierdoor kwamen we erachter dat de paden die standaard in de CSS bestanden opgenomen is niet helemaal klopten. Dit omdat onze CSS bestanden niet in een aparte map, genaamd css, mogen zitten om te kunnen toegevoegd worden aan de variabele $styles. In de huisstijl die ons toegezonden werd, was dit echter wel het geval waardoor
de paden hierop afgesteld waren. Voor het instellen van de juiste paden naar de figuren gebruikten we de zoek en vervang functie om ../images/bestand te vervangen door images/bestand op 53 locaties in screen.css en op 3 locaties in specific.css. Na deze aanpassing werden de figuren zonder problemen getoond op de website. In het thema box_grey was reeds een style.css bestand aanwezig. We behielden dit bestand omdat we ook bepaalde code uit het page.tpl.php bestand behielden en de bijbehorende CSS code dus ook nodig hadden. We maakten wel enkele aanpassingen in dit bestand. Zo verwijderden we code waarvan we zeker waren dat er code aanwezig was in de andere CSS bestanden die hierin voorzag. Bijvoorbeeld de CSS code voor de tag en
,
... Daarnaast pasten we de code aan voor het ID message. Dit omdat alle rode kaders, bijvoorbeeld bij de melding van een nieuwe update, in een extra groen kader werden gezet. Echter het verwijderen van deze kader zorgde ervoor dat meldingen zoals 'De veranderingen werden opgeslagen' en 'De instellingen zijn opgeslagen' nu niet 51
meer in een groene kader met groene letters werd weergegeven. We vonden niet terug hoe we de groene kader weg konden krijgen rond de rode kaders zonder ze overal te verwijderen. We konden er echter wel voor zorgen dat de meldingen wel in een groene kleur verschenen. Hieronder geven we de oorspronkelijke code weer waarvan border, padding en margin werden verwijderd in de nieuwe code. #message { background: #fff; border: 2px solid #6e2; padding: 2em; margin: 1em 2em; }
De nieuwe code werd aangevuld met color en fontsize. #message { color: #6e2; fontsize:13px; background: #fff; }
52
Hoofdstuk 8 – Conclusie De doelstelling van onze masterproef was het migreren van de website van de onderzoeksgroep DDCM van het CMS TYPO 3 naar Drupal (versie 6.x). Het resultaat van onze inspanningen is te vinden op http://telin.ugent.be/~dblancha/Drupal‐6.10. We baseerden ons bij het ontwerp deels op de structuur van de oude website en voegden hier en daar extra functionaliteit toe om de gebruiksvriendelijkheid van de website te verhogen. We kozen in samenspraak met onze opdrachtgevers voor een nieuwe lay‐out gebaseerd op de UGent huisstijl. In deze conclusie willen we aandacht besteden aan de manier waarop deze masterproef tot stand gekomen is. Ten eerste willen we een bondige samenvatting geven van de belangrijkste ervaringen die we opgedaan hebben tijdens het ontwikkelingsproces. Ten tweede willen we wat dieper ingaan op de toegevoegde waarde van het samenwerken aan een masterproef. Ten slotte willen we ook het eindproduct evalueren met aandacht voor wat er nog kan verbeteren.
Ervaringen Het heeft enige tijd geduurd voordat we inzicht hadden in de achterliggende filosofie van Drupal. Een CMS is er in de eerste plaats om snel een aanvaardbaar resultaat te behalen. Het is daarom zeer interessant om te leren werken met een CMS om later op een zeer efficiënte wijze webinhoud te beheren. De ervaring heeft ons geleerd dat het ontwikkelingsproces zich zeer sterk focust op keuzeprocessen. We weten nu welke manier van werken we best volgen. Eerst is het belangrijk na te gaan wat het uiteindelijke doel is. Dit doel kan opgesplitst worden in verschillende duidelijk omschreven problemen. Daarna moet nagedacht worden over hoe we deze doelen een voor een op een zo efficiënt mogelijke wijze kunnen bereiken. We hebben geleerd dat we ons eerst de vraag moeten stellen of de nodige functionaliteit reeds voorhanden is in het Drupal systeem. We weten dat we daarvoor kunnen rekenen op de zeer gestructureerde Drupal gemeenschap waarvan we zelf deel uit kunnen maken. Daarnaast zagen we in dat, 53
ondanks onze beperkte kennis van PHP, we toch snel zelf bepaalde zaken konden ontwikkelen. Dit wordt allemaal mogelijk gemaakt door het vele materiaal dat online beschikbaar is en de gelaagde manier waarop Drupal is opgebouwd. We konden ook beroep doen op onze kennis van een gelijkaardige taal, namelijk Active Server Pages (ASP), wat ons hielp in het lezen van de PHP code. Deze kennis zorgde ook voor een basis waardoor we voldoende met PHP code leerden werken om onze opdracht te vervullen. Daarnaast hadden we voorafgaand aan deze masterproef ook kort gewerkt met HTML en CSS code wat ons zeer goed vooruit hielp bij het ontwikkelen van het ddcm thema.
Samenwerking Het was een meerwaarde dat we deze masterproef met 2 konden uitvoeren. Op deze manier ging de kennismakingsfase sneller dan wanneer we het alleen hadden gedaan. Op die manier konden we leren van elkaars fouten en konden we bij elkaar terecht met onze ideeën en vragen. Het werk ging ook sneller met 2 waardoor we ongetwijfeld een mooiere en beter uitgeruste website konden maken. Het vereiste ook een zekere mate van coördinatie, flexibiliteit en aanpassing aan elkaar. De ontwikkeling van deze eigenschappen is relevant voor het uitvoeren van toekomstige projecten zowel in academische als commerciële werkomgevingen.
Eindproduct en suggesties We hebben geprobeerd zoveel mogelijk te behouden van de originele website waarbij we vooral rekening hielden met de bestaande functionaliteit en inhoud. Daarnaast hebben we geprobeerd om de gebruiksvriendelijkheid van de website zo groot mogelijk te maken, dit zowel voor de bezoekers als de leden van de onderzoeksgroep zelf. Hierbij hebben we zo goed mogelijk geluisterd naar onze opdrachtgevers. We hebben gepoogd om naast het beschrijven van de ingevoerde functionaliteit ook enkele problemen duidelijk te omschrijven. Dit zou moeten leiden tot een beter begrip van de huidige toestand van het eindproduct. Een website is vooral een dynamisch gegeven en er is dus altijd ruimte voor verbetering en verandering. Dit omdat de software ook steeds veranderd en ook de noden van de 54
onderzoeksgroep doorheen de tijd aan verandering onderhevig zijn. Een website is dus ook nooit af, het is een 'work in progress'. Zelf hebben we dan ook enkele suggesties voor aanpassingen aan de website. 1. De website concentreert zich vooral op tekstuele informatie. Het zou interessant zijn om de website aantrekkelijker te maken voor bezoekers door meer beeldmateriaal toe te voegen. Zo zouden voorbeelden van toepassingen die ontwikkeld zijn binnen het kader van projecten interessant kunnen zijn. Men zou bijvoorbeeld ook schema’s van ontwikkelde databases kunnen publiceren. Concrete visuele voorbeelden zijn handig voor de bezoekers om te weten of de activiteiten van de onderzoeksgroep in het verlengde ligt van hun eigen projecten 2. De website kan ook een portaal vormen voor persoonlijke websites van personeelsleden waarin zij zelf hun eigen projecten meer in detail naar voren brengen. Eventueel kan met behulp van Drupal een meer uitgebreide profielpagina voorzien worden. 3. Er kan ruimte voorzien worden om informatie te publiceren over recente conferenties waaraan personeelsleden hebben deelgenomen. 4. Men kan de website ook verder uitbouwen als een sociaal platform met bijvoorbeeld een forum of een gemeenschappelijke agenda zodat personeelsleden meer op de hoogte zijn van elkaars activiteiten. 5. Men kan ook toestaan om een gemeenschappelijke blog aan te maken met vakgerelateerde informatie. Een mooi voorbeeld hiervan is terug te vinden bij de Usability onderzoeksgroep van de KULeuven [16]. Daarnaast hebben we ook enkele suggesties voor verbetering aan Drupal als CMS systeem in zijn geheel. 1. Er zijn nog verschillende mogelijkheden om de Internationalisatie module in Drupal verder uit te bouwen. Zo zijn er onder andere problemen met het implementeren van een andere lay‐out voor meertalige menu’s. Nieuw ontwikkelde modules hebben soms ook problemen met meertaligheid en wanneer men een nieuw inhoudstype aanmaakt wordt niet alles vertaald. 55
2. De module Views heeft veel potentieel. De interface is echter zeer technisch en omslachtig om mee te leren werken. Bij de meeste instellingen, zelfs hele kleine, is het noodzakelijk om de aanpassingen te bevestigen waardoor men al snel iets vergeet op te slaan. Daarnaast is er ook geen template beschikbaar voor de specifieke lay‐out van views. Dit is waarschijnlijk wel mogelijk, maar wordt niet binnen de module zelf aangeboden. Dit zorgde er onder andere voor dat we weinig controle hadden over de lay‐out van onze projectviews. Het zou ook handig zijn, mocht er op een eenvoudige manier ondersteunende tekst bij views kunnen toegevoegd worden. 3. Bij de ontwikkeling van nieuwe inhoudtypes kan men enkel velden toevoegen. Het zou handig zijn om ook hier template mogelijkheden toe te voegen. Hierbij verwijzen we naar mogelijkheden zoals het opstellen van rapporten zoals in MS Access. Rechtstreekse manipulatie van lay‐out en meer evenwicht tussen statische en dynamische elementen zou veel sneller tot gerichte resultaten kunnen leiden.
56
Bijlage Bijlage A: De Personeelmodule t('People'), 'page callback' => 'personeel_ddcmmembers', 'access callback' => 1, 'type' => MENU_NORMAL_ITEM ); return $items; } /** * Function for generating a page with a listing of the DDCM members * with some extra information and a link to their Drupal user page if available */ function personeel_ddcmmembers() { $output = ''; // connect anonymous to ldap $telin_ldap_base = 'ou=Users,dc=telin,dc=ugent,dc=be'; $telin_ldap_connection = ldap_connect('ldap'); ldap_set_option($telin_ldap_connection, LDAP_OPT_PROTOCOL_VERSION, 3); // which attributes $telin_ldap_attributes = array('sn', 'title', 'cn', 'telinhomepage',
57
'mail', 'telephonenumber', 'roomnumber', 'telinphoto', 'uid'); // filter per category $research_group = 'DDCM'; $groups = array( t(' Professors') => "(&(telinResearch=$research_group)(telinStatus=ZAP))", t(' Associate professors') => "(&(telinResearch=$research_group)(telinStatus=AZAP))", t(' Researchers') => "(&(telinResearch=$research_group)(|(telinStatus=OAP)(telinStatus=AAP)))", t(' Associate researchers') => "(&(telinResearch=$research_group)(telinStatus=ARESEARCH))", t(' Guests') => "(&(telinResearch=$research_group)(telinStatus=GUEST))", t(' Former members') => "(&(telinResearch=$research_group)(telinStatus=FORMER))" ); foreach ($groups as $group => $telin_ldap_filter) { // query LDAP database $result = ldap_search($telin_ldap_connection, $telin_ldap_base, $te lin_ldap_filter, $telin_ldap_attributes); // sort on surname ldap_sort($telin_ldap_connection, $result, 'sn' ); // get data $data = ldap_get_entries($telin_ldap_connection, $result); if ($data['count'] > 0) { $header = array('Photo', 'Name', 'Email', 'TELIN homepage', 'Telephone'); $rows = array(); for ($i=0; $i<$data['count']; $i++) { //build name $name = implode(' ', array($data[$i]['title'][0], $da ta[$i]['cn'][0])); // add link to profile page if available $uidresult = db_query("SELECT uid FROM {users} WHERE name = '%s';", $data[$i]['uid'][0]); if ($uid = db_fetch_array($uidresult)) { $uid = $uid['uid']; if ($uid > 0) {
Figuur 1. In het gemarkeerde gedeelte kan men onder andere de lees‐ (R) en schrijfrechten (W) voor het bestand instellen. Het getal 644 is een getal dat samenvat dat die 4 specifieke keuzevakjes van de 12 zijn aangevinkt.
Figuur 2. Het onderdeel ‘Content translation’ is afhankelijk de module Locale.Daarnaast is dit onderdeel vereist voor de werking van heel wat andere onderdelen. Er wordt ook 66
vermeld of deze onderdelen actief (Eng. enabled) zijn of niet (Eng. disabled). Zolang er afhankelijke onderdelen actief zijn zal het keuzevakje (omcirkeld) grijs blijven en kan ‘Content translation’ niet uitgeschakeld worden.
Figuur 3. In deze figuur wordt de hoofdstructuur van de website lay‐out weergegeven.
Figuur 4. Wanneer je bij een bezoek aan de module pagina deze waarschuwing tegenkomt, moet men de ‘cron instellen’ link aanklikken zodat de onderhoudsoperaties van het systeem kunnen uitgevoerd worden.
67
Figuur 5. Het gebruik van een boek inhoudstype zorgt voor een eenvoudige navigatie onderaan elke pagina.
Figuur 6. Gebruikers met voldoende rechten om inhoud aan te maken en te bewerken kunnen via het tabblad vertalen toegang krijgen tot het bewerken van dezelfde pagina’s in andere talen. Zo kan onder andere de titel en de tekst in de andere taal worden ingegeven. Via de taalkeuze kan men dan eenvoudig overschakelen van de ene versie van de pagina naar de vertaalde versie van de pagina.
Figuur 7. Een eenvoudige WYSIWYG editor die het aanmaken van inhoud sterk vereenvoudigd.
68
Figuur 8. Deze figuur geeft een overzicht van de verschillende velden die kunnen ingevuld worden bij het inhoudstype project. De velden met een * zijn verplichte velden.
69
Figuur 9. Dit is een voorbeeld van het uitzicht (view) van de huidige projecten. Bovenaan kan een datum worden ingegeven waarop gefilterd moet worden. Dit zijn bijvoorbeeld de projecten die op 28 mei 2009 nog steeds bezig zijn. Standaard wordt uiteraard telkens de datum van de huidige dag getoond.
70
Figuur 10. In het ugent thema waren we er niet in geslaagd om de tab weergave correct weer te geven. Door te vertrekken vanuit het box_grey thema ging dit wel in het ddcm thema.
71
Figuur 11. Zo ziet de website er uit in Firefox 3.0.
Figuur 12. Tussen sommige browsers zijn er kleine verschillen in weergave. In Opera 9.6 zien we onder andere dat wanneer een geen afbeeldingen van personeelsleden beschikbaar zijn deze worden vervangen door lege kaders. Dit is niet zo in Firefox 3.0. 72
Figuur 13. Initieel was het de bedoeling om het type layout voor meer niveau menu’s te benaderen zoals in de officiële Ugent huisstijl (a). Dit lukte ons echter niet, omdat we er niet in slaagden om een duidelijk onderscheid te maken tussen de ouder‐ en kinditems van het menu (b). Via de module Nice Menus vonden we wel een oplossing die voor een duidelijke menu structuur zorgde. Hier worden opeenvolgende niveaus telkens horizontaal geordend.