Hou Het Simpel: Gebruik Docker Om Een CMS Te Testen

Een paar dagen geleden vertelde ik dat je meerdere oplossingen voor je CMS-behoeften moet bekijken als je wilt weten wat voor jou werkt en wat niet. Maar hoe bestudeer je een server-gebaseerd tool (zoals Drupal, Joomla, WordPress, Typo3 en andere) als je geen specialist hebt om je te helpen bij de installatie?

Ik zal WordPress als voorbeeld gebruiken, aangezien ik een reeks WordPress-thema’s en plug-ins wilde uitproberen voordat ik ze op een productie-site activeer. Maar dezelfde benadering kan worden gebruikt voor andere tools; ik ben er zeker van dat er op het internet meerdere bronnen zijn om uit te leggen hoe dat kan.

Het goede nieuws is dat je dit zonder al te veel downloads en installatiewerk kan doen, door Docker en “containers” te gebruiken. Ik ga niet uitleggen wat Docker is en hoe het hier werkt: er zijn verschillende uitstekende introducties beschikbaar, te beginnen (natuurlijk) bij de Docker Docs-website.

Docker zorgt voor het verkrijgen en configureren van de benodigde software of pakketten. Docker installeert ze in een of meer actieve containers en start ze ook op. Je hebt dus twee dingen nodig om aan de slag te gaan: de Docker-applicatie en een definitie voor wat je in de container of containers wilt draaien.

Docker installeren is niet moeilijk: de Docker-website legt het uit voor Linux, Mac OS en Windows. Ik heb Docker Desktop geïnstalleerd, inclusief Docker Compose. De “composer” is gemakkelijker te gebruiken dan de opdrachtregelversie van het tool, zeker voor Docker-nieuwkomers zoals ik. Ik wil immers in de eerste plaats meer weten over WordPress; extra informatie over Docker komt later als en wanneer nodig.

Je moet Docker vertellen welke “services” er moeten draaien voordat het tool zijn werk kan doen. Dat doe je in een “Docker Compose”-bestand. Ik heb een map met de naam ‘wordpress‘ aangemaakt op het bestandssysteem van mijn Mac, en in die map heb ik een bestand gezet met de naam ‘docker-compose.yml‘. Hier is de inhoud die in dat bestand moet worden geplaatst om WordPress op gang te krijgen:

version: "3.3"
services:
        mysql:
            image: mariadb
            volumes:
                - db_data:/var/lib/mysql
            restart: always
            environment:
                MYSQL_ROOT_PASSWORD: example
                MYSQL_DATABASE: wordpress
                MYSQL_USER: youruser
                MYSQL_PASSWORD: yourpw

        wordpress:
          image: wordpress
          ports:
              - "8000:80"
          volumes:
              - wp_data:/var/www/html
          environment:
            WORDPRESS_DB_HOST: mysql
            WORDPRESS_DB_USER: yourwpuser
            WORDPRESS_DB_PASSWORD: yourwppw
            WORDPRESS_DB_NAME: wordpress
          depends_on:
              - mysql
          restart: always
volumes:
        db_data: {}
        wp_data: {}

Dit bestand vertelt Docker dat er twee ‘services‘ nodig zijn: een database en de WordPress-applicatie zelf. Als database heb ik MariaDB, een MySQL-variant, gekozen. De regel ‘image‘ specificeert welke software (versie) Docker moet ophalen uit zijn uitgebreide catalogus. De regels environment beschrijven de waarden die moeten worden gebruikt als waarden voor de parameters die het pakket nodig heeft. De regel ‘ports‘ in de service ‘wordpress‘ legt Docker uit dat netwerkverkeer van uw browser op poort 8000 moet worden omgeleid naar de standaardpoort 80 op de WordPress-container.

Dan zijn er de wat minder vanzelfsprekende regels over volumes.

Wanneer je een toepassing start vanuit een of meer Docker-containers, zal Docker controleren of wat het eerder heeft gedownload uit de catalogus nog steeds overeenkomt met wat is opgegeven in het bestand docker-compose.yml . Als er geen specifieke versie wordt vermeld, gaat Docker ervan uit dat je de nieuwste versie wil. Docker zal dus een nieuwere versie downloaden dan degene die tevoren gebruikt werd als die laatste verouderd is, en daarbij de oude versie overschrijven; zonder bijkomende instructies is dat inclusief de data die bv. in de database wordt opgeslagen. Om die data op te slaan voor later hergebruik – in dit geval zal dat de inhoud van de WordPress-site zijn – moet je Docker vertellen om bepaalde onderdelen van het pakket op te slaan buiten de containers, in jouw eigen bestandssysteem. De ‘volumes’ in het bestand docker-compose.yml doen precies dat: normaal slaat MariaDB zijn database op in een Linux-pad op ‘/var/lib/mysql‘ ; het bestand zegt dat de database moet worden opgeslagen in een lokale folder pad (map) genaamd ‘db_data‘. WordPress-gegevens die normaal worden bewaard in ‘/var/www/html‘, moeten worden opgeslagen in onze folder ‘wp_data‘.

Ik vermoed dat Docker veronderstel wordt om deze folders aan te maken als ze nog niet bestaan, maar dat gebeurde niet tijdens mijn eerste tests. Om problemen te voorkomen heb ik die mappen (volumes) zelf aangemaakt onder dezelfde ‘wordpress‘ map waarin het docker-compose.yml bestand zich bevindt.

Als dat allemaal is gebeurd, is het tijd om een shell (‘bash’ op Mac en Linux bv) te starten, jouw ‘working directory’ in te stellen op de map ‘wordpress‘ en de volgende opdracht te starten:

docker-compose up -d

Docker zal opstarten, en als eerste klus zal het de vereiste software-images downloaden als deze nog niet op jouw computer staan. Dit kan een paar minuten duren, zeker bij een eerst gebruik van Docker. Maar als alles goed gaat, zal het eindigen met de boodschap dat het “Netwerk” is gemaakt en de “containers” zijn gestart.

Dan kan je een browser openen en naar het adres “http://localhost:8000” surfen om WordPress te configureren. Volg gewoon de instructies: kies een taal voor de site, voer vervolgens een titel voor de site in en maak de inloggegevens voor de sitebeheerder. Daarna kan je beginnen met het maken van content en het aanpassen van de manier waarop de site die inhoud weergeeft aan zijn gebruikers. Vanaf nu kan je WordPress aan de tand voelen, en experimenteren met extensions en thema’s en nog veel meer.

Als je denkt dat het gebruik van Docker moeilijk is, kun je mijn Docker-instructies vergelijken met de “How to install WordPress“-pagina op de WordPress-website. Ik hoop dat het duidelijk is dat Docker veel configuratiewerk in jouw plaats doet. Nog beter: Docker doet het op een manier die het proces zeer herhaalbaar maakt – doe dit opnieuw op een andere machine en je krijgt precies hetzelfde resultaat, met weinig kans op typefouten en andere voetangels die het proces compliceren. Bedankt, Docker!

Waarom Zou U Zelf Een CMS Bouwen?

De markt van Content Management Systemen (CMS) is verre van overzichtelijk: de welgekende CMS Matrix-website heeft meer dan 1300 producten in zijn databank zitten! Dat maakt een keuze er niet eenvoudiger op, natuurlijk. En dus hoor ik wel eens zeggen: “Laten we dan maar een eigen CMS bouwen“.

Is dat een goed idee? Wat houdt dat zoal in, een eigen CMS bouwen? Welke voor- en nadelen moet je incalculeren bij het opstarten van de bouw?

Het artikel “Why Would You Write Your Own CMS?” is warm aanbevolen aan elke ontwikkelaar en webmaster die een eigen CMS overweegt. De auteur pretendeert geen volledigheid, maar zet m.i. toch maar mooi de voornaamste kenmerken van dat proces op een rijtje.

When all is said and done, the main reason I chose to write my own CMS is because I wanted to. The main benefit is that it’s precisely what I need, and the main drawback is that it took ages to build.

Nu is het natuurlijk zo dat James Edwards een systeem bouwde dat “op zijn lijf” is geschreven: hij is ook de enige gebruiker. Wie een eigen CMS voor het bedrijf wil bouwen, moet rekening houden met extra nadelen – en voordelen, natuurlijk. Uit ervaring weet ik dat één van die belangrijke voordelen de flexibiliteit is waarmee je het CMS dan kan aanpassen aan de evoluties binnen en rondom het bedrijf. Dat kan je van vele bestaande producten niet zeggen…

Anderzijds mag een pleidooi voor “do it yourself” ook niet betekenen dat je niet mag kijken naar een aantal “content management platformen”. Zo’n platform biedt basisfunctionaliteiten, en daar bovenop een of meerdere manieren om op maat gemaakte functies toe te voegen. De grote voorbeelden zijn gekend: Drupal, Joomla, WordPress, Typo3 en nog vele anderen kan je op eigen servers installeren; platformen als Wix, BigCommerce, Shopify en Bitrix24 zorgen niet alleen voor het CMS zelf, maar ook voor de hosting, zodat je je enkel moet concentreren op de inhoud.

Elk type oplossing heeft voor- en nadelen, en er bestaat dus geen “beste” oplossing voor alle mogelijke situaties. Studeren, proberen en verschillende mogelijkheden vergelijken is de enige manier om jouw “beste” oplossing te vinden!

Proficiat, Mobco!

Tien jaar geleden werd Mobco opgericht. Sedertdien is de firma flink gegroeid – ook internationaal. Ik leerde Mobco kennen als de absolute MobileIron-specialisten in de Benelux, maar intussen zijn de Mobco-medewerkers experten in heel wat meer domeinen.

Happy birthday, Mobco!

Zet De Gebruikers Centraal Bij De Implementatie Van Uw CMS

Zowel marketeers als IT’ers durven ze al te gemakkelijk uit het oog verliezen: de gebruikers. Zeker wanneer het gaat over grote investeringen of over combinatiepakketten als de G Suite van Google of Microsoft’s Office 365 wordt meer over de uitgebreide mogelijkheden en de prijs gesproken dan over de specifieke behoeften van de gebruikers en hun bedrijf of team. In de woorden van Laurence Hart in het artikel “Don’t Blame SharePoint, Blame IT“:

The question you need to ask yourself about SharePoint, Office 365 or any system is, “Who is driving your requirements?” To whom is the vendor listening when they design and build enhancements? The answer is critical to choosing the right software.

Het zal u niet verbazen dat ook de succesvolle implementatie van een Content Management-systeem mee bepaald wordt door de reële en specifieke behoeften van de organisatie én van haar gebruikers. Juist omdat het zo moeilijk is om die behoeften vooraf (en dus een beetje in het abstracte) te verwoorden en op (virtueel) papier te zetten, is het van het grootste belang om tijdens het selectieproces veel ruimte te voorzien voor het consulteren van de mensen die dagelijks met het CMS aan de slag zullen gaan.

Let op: het gaat dan niet enkel over gebruiksgemak en de “user interface”, maar ook over de functionaliteiten van de producten. Wanneer het gaat over het aanpassen van bestaande werkprocessen moet je je afvragen: welke functionaliteiten heeft de eindgebruiker nodig, en hoe kan het tool die leveren terwijl het in het proces wordt ingepast? Wie kan die vragen beter beantwoorden dan de eindgebruikers zelf?

Als u nieuwe processen gaat opzetten of bestaande processen kompleet gaat omgooien en vervangen, dan is de rol van de eindgebruikers zo mogelijk nog belangrijker. Want zonder hun inbreng is de kans op slagen van het veranderingstraject heel klein, dat leert u in elke cursus “change management”. Dus eerst het proces op punt zetten, en pas daarna geheel of gedeeltelijk automatiseren. En natuurlijk moeten dan de IT’ers weer mee aan tafel – maar niet als ultieme beslissers.

Content Management In Tijden Van COVID-19

Woorden als “crisis”, “oorlog” en “lock-down” maken het overduidelijk dat we dezer dagen een zeer uitzonderlijke periode meemaken. Iedereen zoekt naarstig naar manieren om zich aan te passen aan de strenge beperkingen die de overheid ons oplegt om de impact van de SARS-CoV-2-besmetting zoveel mogelijk te beperken. Niemand weet hoe lang de huidige situatie gaat aanhouden.

Met behulp van informatietechnologie slagen heel wat bedrijven er gelukkig in om toch geheel of gedeeltelijk actief te blijven. Telewerk is al langer mogelijk, maar vandaag wordt het toegepast op een schaal die zelfs in grote bedrijven (denk in België aan de banken) nieuw is. En dat brengt dus onbekende risico’s met zich mee, bijvoorbeeld rond de schaalbaarheid en de performantie van de gekozen hard- en software. Reken maar dat menig CIO zich daar de voorbije weken de kop heeft over gebroken!

Maar ik wil het hier even over een ander aspect van het telewerk hebben, met name de beschikbaarheid van de informatie die de telewerkers nodig hebben om hun werk te blijven doen.

Elke telewerker wil op de hoogte blijven van wat er reilt en zeilt binnen de onderneming. E-mail en/of intranet blijven de belangrijkste kanalen voor al wie ingelogd geraakt in de telewerk-sessie… maar hebt u ook één of meerdere alternatieve kanalen ter beschikking? Publieke sociale media als WhatsApp kunnen in nood dienst doen. Maar ze zijn niet echt ideaal in een professionele context: hoe houdt u de leden van een groep up to date? Hoe zit het met de discretie van de berichten? Hoe garandeer je dat er geen ‘fake news’ binnensluipt? etc.

Als het bedrijf over een intranet beschikt, dan is de kans groot dat tenminste een deel van de informatie die de medewerkers nodig hebben beschikbaar is wanneer ze inloggen op de systemen van het bedrijf. Maar het is goed om je de vraag te stellen: heeft elke telewerker wel al de informatie ter beschikking die nodig is? Is de zoekfunctie handig genoeg om te vinden wat er gezocht wordt? Het zou mij alvast niet verbazen dat tijdens het telewerk duidelijk wordt in welke mate medewerkers rekenen op de parate kennis van collega’s die op kantoor vlak bij hen zitten, in plaats van op wat een “search” kan leveren!

Last but not least is er het gedrag van de klanten van het bedrijf. Tijdens crisisperiodes als deze gaan mensen, en dus ook klanten, zich anders gedragen. Soms omdat het moet op bevel van de overheid, maar vaak omdat we als mensheid nu eenmaal creatief zijn in het bedenken van oplossingen voor nieuwe problemen. Of die oplossingen goed of slecht zijn maakt niet uit: de vraag is wat er nodig is binnen het bedrijf om met die veranderende verwachtingen en gedragingen van de klanten om te gaan. Hoe snel kunnen processen – en de bijbehorende documentatie- en informatiestromen – worden aangepast, gedocumenteerd en uitgerold? Hebt u de middelen ter beschikking om medewerkers te vormen wanneer ze thuis aan de slag zijn?

Bovenstaande bedenkingen zijn verre van  volledig, maar dat was ook niet mijn bedoeling. Ik wil niet verwijzen naar Machiavelli of Churchill, want een “goede crisis” is dit niet. Maar: de COVID-19-epidemie gooit onze wereld wel even overhoop, en uit wat er verandert kunnen we hopelijk heel wat leren, ook op het vlak van content management.

Terwijl we leren mogen we de essentie niet vergeten: eerst zorgen voor de mensen en hun gezondheid, en daarna pas voor de rest. Verzorg jezelf, verzorg je naasten, wees solidair met alle mensen! En wees alsjeblief verdraagzaam voor al wie het moeilijk heeft om zich aan te passen aan de vele veranderingen die ons nu overvallen.

“Gemakkelijk” Is Niet Noodzakelijk Goed

Microsoft kondigde onlangs aan dat het in de nieuwste versie van SharePoint super-gemakkelijk wordt om een “home page” voor je intranet te maken. Leuk, niet waar?

Toch maar even uitkijken, zou ik zeggen: websites in het algemeen, en dus ook intranetten, verdienen meer dan een paar minuten aandacht vooraleer je iets online zet. Ook de CMSWire website, dat de aankondigingen van Microsoft bespreekt, eindigt met die boodschap:

It is not the pure technology aspect to building out an intranet that is difficult.

What is the focus, what do you want employees to be able to do? You better have spent some months thinking about the user experience, the information architecture, navigation, metadata (for all sorts of purposes) and many other factors before you start cranking out those sites. Just because you can do something easily, does not necessarily mean that you should!

Content Management = Mensen + Processen + Tools

“Content Management”, hoe je het ook juist definieert, is een complexe materie. Mensen, processen en tools moeten op goed op elkaar afgestemd zijn om tot een relevant, bruikbaar en waardevol resultaat te leiden. Zelfs wanneer het “enkel maar” over een website gaat blijkt dat al niet steeds evident te zijn. De term “website” omvat voor mij dan zowel de statische content (teksten, afbeeldingen, video, …) als de dynamische content, zijnde de toepassingen die er in opgeroepen worden (registratie van gebruikers, polls, aankopen, etc.).

Een paar jaar geleden wees ik al op wat er misgelopen is met de Wikibru website: het tool, Mediawiki, is prima, maar over de processen (en de mensen die verondersteld worden om er aan mee te werken) is onvoldoende nagedacht. Ook vandaag kan je enkel constateren dat er sedert augustus 2016 geen enkele nieuwe informatie op de Wikibru sites is gezet – zelfs spammers laten de sites links liggen.

Maar er zijn nog andere illustraties te vinden van de complexiteit waarvan ik sprak.

De voorbije twee weken, net na mijn vakantie, zijn er mij een paar situaties overkomen die wijzen op… slordigheidjes in het beheer van websites. Het gaat hier telkens om Belgische websites, die ik niet zal noemen – ik wil niemand specifiek beschuldigen, ik wil enkel maar aantonen hoe gemakkelijk fouten kunnen optreden en eventueel voor problemen kunnen zorgen.

* * *

De eerste case betreft een geweldige taalfout in de titel van een artikel in een grote commerciële website:

De fout is intussen (gelukkig!) gecorrigeerd, waarschijnlijk omdat ik niet de eerste noch de enige was die hierover struikelde. Maar dergelijke inhoudelijke fouten zouden nooit door de redactionele controle op een tekst mogen sluipen – en ook niet op een website.

De tweede case is een gewone programmeerfout in een invoerscherm, die gelukkig geen gevolgen had voor de aankoop die ik uitvoerde (ik heb het hokje maar aangevinkt in de hoop dat er niets anders fout zou lopen):

Dit soort bug had al in de testcyclus moeten opvallen: het is geen randgeval, maar een tekst die bij elke aankoop getoond wordt. Deze software wordt gebruikt voor meerdere websites/bedrijven, en dat al geruime tijd (in de source code wordt nog getest op zeer oude browserversies!). Dan zou iemand toch moeten zien dat de juiste naam van bedrijf or organisatie niet wordt getoond? Ik heb niet geklikt op de term “general conditions” die in de tekst rood wordt geafficheerd, maar het is niet onmogelijk dat die (eventuele) link niet leidt naar de juiste tekst. Dat is misschien niet van belang voor een particulier die een kleinigheidje online aankoopt, maar wel voor de aankoper van een bedrijf die een flinke bestelling wil plaatsen.

Als derde case wil ik even verwijzen naar de situaties die kunnen ontstaan wanneer meerdere diensten betrokken zijn bij de bouw van web applicaties, en dan zeker bij applicaties die meerdere jaren blijven bestaan en dus regelmatig onderhouden worden:

Waren het de ontwikkelaars die de tekst op de knop gewijzigd hebben naar “Bevestigen”, of is het de taaldienst die de boodschap aangepast heeft? Of is er nog een derde partij in het spel? Ik weet het niet. Gelukkig is de impact hier beperkt – behalve voor mensen die de tekst letterlijk nemen en dan misschien de klantendienst gaan contacteren…

* * *

Het weze duidelijk dat geen van de genoemde fouten op zich heel erg fout zijn. Geen van hen had impact op wat ik wou realiseren; ik ben er enkel een beetje tijd mee kwijt gespeeld. Maar ze zijn wel illustratief voor alvast drie soorten problemen die kunnen voorkomen in het dagelijks beheer van websites. Het gaat natuurlijk om menselijke fouten, en mensen zullen steeds fouten blijven maken. Maar als bedrijf wil je dergelijke fouten zo veel mogelijk opvangen nog voor het grote publiek ze te zien krijgt. Juist daarom is het belangrijk om “content management” niet alleen te zien als een product dat je aankoopt, maar als een tool dat je moet inpassen in je organisatie, rekening houdend met de mensen en de processen in die organisatie. Dat betekent flink wat studie en overleg vooraleer over te gaan tot implementatie, en dat is één van de redenen waarom content management een (relatief) dure aangelegenheid is.