Wet op de webrichtlijnen schiet doel voorbij

“Gemeenten webrichtlijnen wettelijk opleggen” is de aanbeveling die belangenorganisaties voor slechtzienden en blinden Stichting Waarmerk drempelvrij.nl, Viziris, CG-Raad en Bartiméus doen in hun jaarlijkseevaluatierapport (extern, PDF) over de toegankelijkheid van overheidswebsites. Hiermee geven zij opnieuw brandstof aan de al jaren voortdurende discussie over het al dan niet  afdwingen van toegankelijkheid van overheidsinformatie op internet.

Webrichtlijnen zijn al verplicht

Overheidswebsites moeten al verplicht aan de webrichtlijnen voldoen. Dat is geregeld in het Besluit Kwaliteit Rijkswebsites (BKR) en het bestuursakkoord voor het Nationaal Uitvoeringsprogramma Dienstverlening en e-Overheid (NUP). De eerste is een kabinetsbesluit waaraan alle organisaties die onder ministeriële verantwoordelijkheid vallen moeten voldoen, de tweede is een overheidsbreed akkoord waaraan Rijk, Provincies, Waterschappen en Gemeenten zich hebben gecommitteerd. Alle nieuwe Rijkswebsites zouden vanaf 1 januari 2006 moeten voldoen aan de webrichtlijnen, vanaf 1 januari 2010 ook alle bestaande websites. Voor gemeenten zijn soortgelijke afspraken gemaakt: vanaf 8 december 2008 (datum van ondertekening van het NUP) moeten alle nieuwe gemeentelijke websites aan de webrichtlijnen voldoen, op 1 januari 2011 ook alle bestaande gemeentewebsites.

Verplichten werkt (nog?) niet

Maar blijkbaar is dat niet voldoende. Volgens het rapport van Stichting Waarmerk Drempelvrij.nl cs. voldoen 2 gemeentelijke websites en 1 gemeentelijke regelingenbank aan de webrichtlijnen. Het onderzoek waarop het rapport is gebaseerd is echter maar uitgevoerd bij 33 gemeenten. Er zijn in Nederland 430 gemeenten (eind 2010 -er staan een paar herindelingen op stapel). Als je die gegevens zou extrapoleren, dan zouden 39 gemeentewebsites aan de webrichtlijnen moeten voldoen. Echter, als je het Register van het Waarmerk Drempelvrij.nl bekijkt, zie je dat van alle gemeenten er inderdaad 2 aantoonbaar voldoen aan de webrichtlijnen, en 1 gemeentelijke regelingenbank.

De situatie is dus nog erger dan het rapport doet vermoeden -of valt dat wel mee?

Beste jongetje van de klas

Wat zeggen de cijfers nu eigenlijk? Drie gemeentelijke websites (voor het gemak) voldoen aantoonbaar aan de Webrichtlijnen. Dat ‘aantoonbaar’ zegt al iets: er is een onafhankelijke en gecertificeerde toetsinstantie geweest die een verifieerbare toets heeft gedaan en daarmee een betrouwbare uitspraak doet over de toegankelijkheid van de website, volgens de norm van de Webrichtlijnen. Sterker nog, het resultaat van die onafhankelijke toets was dat deze drie websites 100% hebben gescoord. Want anders krijg je niet het certificaat en het bijbehorende logo van het groene mannetje met de drie sterren. Of alle andere gemeenten eenzelfde toets hebben laten doen, en wat daarvan de uitslagen zijn, is niet publiek. Het register is dus een cum-laude-register.

Daarmee legt het gelijk een van de grootste zwaktes van de huidige webrichtlijnen bloot: je voldoet aan alle 125 richtlijnen, of je voldoet helemaal niet. Als een organisatie na hard werken en met de beste intenties aan 120 richtlijnen voldoet, krijgen ze geen beloning. Sterker nog, ze worden daarmee gelijkgesteld aan die organisaties die de webrichtlijnen volledig aan hun laars lappen en er niets aan willen doen.

Morele plicht

Voor veel overheidsorganisaties is dat een reden om de toepassing van de webrichtlijnen voor hun website een lage prioriteit te geven. En dat is onterecht. De webrichtlijnen gaan immers over het borgen van de toegankelijkheid van overheidsinformatie. En sinds Napoleon in 1814 de basis legde voor de moderne overheid is informatie verstrekken een van de kerntaken van de overheid geweest. De webrichtlijnen borgen dat iedereen, ongeacht de technologie die daarvoor gebruikt wordt, bij de informatie kan komen die de overheid publiceert. De overheid heeft dan ook een bijzonder sterke morele plicht om ervoor te zorgen dat de informatie -en daarmee ook de kanalen waarlangs die informatie wordt vrijgegeven- zo toegankelijk mogelijk zijn.

Dat is ook het morele gelijk van de belangenverenigingen die tezamen bij de Tweede Kamer een sterke lobby voeren voor de wettelijke verplichting van de webrichtlijnen. Immers, zij vertegenwoordigen die mensen voor wie de overheid allerlei (digitale) drempels opwerpt om met die overheid digitaal te interacteren. Daarmee zijn kamerleden ook snel overtuigd van het belang van de webrichtlijnen. De SP heeft al eerder -eind 2009- aan de Staatssecretaris van BZK gevraagd of er geen wet kan komen die overheiden dwingt hun websites toegankelijker te maken.

Weerbarstige praktijk

Als het makkelijk was om de websites aan de webrichtlijnen te voldoen, waren er vast meer websites geweest die het (felbegeerde?) logo met drie sterren mochten voeren. De praktijk blijkt weerbarstiger -hoe goed en nodig de webrichtlijnen ook zijn. Toepassing van de webrichtlijnen betekent dat door verschillende mensen op verschillende plekken binnen en buiten de organisatie moeten weten waar zij op moeten letten.

Meestal gaan de webrichtlijnen meespelen bij vernieuwing van de gemeentelijke website. Daarbij wordt een leverancier geselecteerd -als het meezit wordt bij de selectie ook gevraagd naar hun kennis en ervaring met de webrichtlijnen. Meestal zijn andere factoren, zoals prijs, integratie met andere systemen, huisleveranciers, samenwerkingen met andere gemeenten etc. van groter belang en worden de webrichtlijnen al bij de aanbesteding tot posterioriteit verklaard. De gemeentelijke website bestaat vaak uit meerdere systemen: een systeem om pagina’s met inhoud te publiceren, een webpublicatiemodule van het documentmanagementsysteem om documenten op de website te plaatsen, een producten- en dienstencatalogus en een of meerdere loketapplicaties met een web-intake systeem. Soms zijn hier nog aparte formulierenmodules aan toegevoegd. Daar moet de gemeente nog DigiD, Samenwerkende Catalogi, eHerkenning, MijnOverheid.nl, het Omgevingsloket Online, Antwoord(c), Regelhulp en vast nog wel meer (centrale) voorzieningen in zien te integreren. Over die hele brij heen moeten de webrichtlijnen toegepast worden.

Maar dat is nog niet alles. Want het doel is natuurlijk om de website blijven toegankelijk te laten zijn. Dat betekent dat alle processen die leiden tot publicatie op de gemeentelijke website gescreend moeten worden en de webrichtlijnen daarin geborgd moeten worden. Dat betekent dat de organisatie überhaupt procesgericht werkt, dat de mensen die zich met het creëren van overheidsinformatie bezig houden (en dat zijn er een boel bij een gemiddelde gemeente) met een aantal toegankelijkheidsaspecten, dat diegenen die daadwerkelijk informatie publiceren op de website over alles een strenge redactie voeren en dat de gemeente zelf bewust is van het werk dat dit met zich meebrengt in haar communicatie en publicatieambities.

De drie gemeentelijke websites die aan de webrichtlijnen voldoen laten echter zien dat het NIET onmogelijk is. Veel argumenten tegen het toepassen van de webrichtlijnen zitten dan ook in onwetendheid -klok versus klepel enzo- en gebrek aan kennis en ervaring bij dit soort grote en complexe trajecten.

Wet op de webrichtlijnen to the rescue?

Maar dan het voorstel van de SP en de belangenorganisaties om via een wet toepassing van de webrichtlijnen af te dwingen. De ervaringen met het BKR en het NUP wijzen uit dat een tandenloze afspraak niet helpt -en voor een wet geldt hetzelfde. Zonder sancties zullen de overheden niet harder gaan lopen. De sancties zouden serieus moeten zijn om ook daadwerkelijk een verschil te maken. Websites die op zwart gaan, bestuurlijke boetes, rechtszaken… Maar met al die sancties worden gemeentelijke websites niet minder complex of de organisaties in eens beter in staat de webrichtlijnen toe te passen zoals ze bedoeld zijn. Een wet schiet dan ook zijn doel voorbij.

Ondersteun gemeenten met goede instrumenten en opleiding

Wat werkt dan wel? Ervaringen met het NUP leiden ertoe dat de komende jaren in het kader van de implementatie van e-overheidsvoorzieningen staat. En het kernwoord daarbij is implementatie-ondersteuning. Help gemeenten met instrumenten die hun website minder complex, en leid de mensen op tot toegankelijkheidsbewuste contentmanagers. In aansluiting op de implementatiestrategie die het Digitaal Klantdossier-traject bij gemeenten heeft gevolgd, moet zoveel mogelijk gestandaardiseerd worden. Niet één centraal CMS (alhoewel dat bij de waterschappen en bij de departementen erg goed heeft gewerkt!), maar wel uniformering in structuur en functionaliteiten. Niet dwingend, maar ondersteunend. En de webrichtlijnen als onderdeel van een gestandaardiseerde aanpak voor web-projecten. Bijbehorende opleidingen door een breed scala aan opleiders. Met andere woorden: daadwerkelijke ondersteuning van de mensen die het moeten (gaan) doen: overheidsinformatie toegankelijker maken.

Beter meten is beter weten

Maar daarmee ben je er nog niet. Het huidige probleem van het moeten halen van een score van 100% moet ook aangepast worden. Er moeten meerdere niveau’s zijn waarop de toegankelijkheid gemeten kan worden. Een basisniveau (gelijk aan het Waarmerk Drempelvrij.nl?), een of meer tussen niveau’s, en het top-niveau van Webrichtlijnen. In versie 2 van de Webrichtlijnen wordt hier tot op zekere hoogte al rekening gehouden -maar naar mijn mening nog niet genoeg.

De conformiteitsniveau’s in versie 2 van de webrichtlijnen zijn gebaseerd op de A, AA en AAA niveau’s van de WCAG 2 standaard. Dit zijn niveau’s vanuit de toegankelijkheid geredeneerd. Daar is op zich helemaal niets mis mee. Maar aanvullend moeten er conformiteitsniveau’s op basis van de implementatie komen. Iets als ‘komt van ver, werkt hard aan verbetering’. Vergelijk het met auto’s: van Volvo’s verwacht je 5 sterren op het gebied van veiligheid, maar van een goedkope Mazda heb je daar minder hoge eisen bij. Dat maakt het veiligheids-sterren-model van de EU niet minder relevant en belangrijk, maar het maakt wel de keuzes -en de daarbij behorende consequenties inzichtelijk.

Het zou dan ook mooi zijn als transparant gemaakt kan worden hoe ver overheden nu al zijn met de webrichtlijnen en wat de consequenties daarvan zijn. Als een soort camping-gids: wat werkt al wel volgens de webrichtlijnen, en wat nog niet. Kleine plaatsen zijn ontoegankelijke delen van de website, veel schaduw is een toegankelijk raadsinformatiesysteem. Enzovoorts.

Hoge druk vraagt slimme inzet van middelen

De druk op overheden om serieus met de webrichtlijnen aan de slag te gaan wordt steeds groter. Dat blijkt ook wel uit het rapport. Ook uit Brussel komen geluiden dat toegankelijkheid van overheidsinformatie onderdeel kan worden van wetgeving over gelijke behandeling -waarmee het strafbaar kan worden tot aan het Europees Hof voor de Rechten van de Mens Maar met de bezuinigingen bij alle overheidsorganisaties en de complexiteit van de problematiek, moet zorgvuldig nagedacht worden over de juiste inzet van middelen. Onder druk wordt alles vloeibaar, dus als je nu een juiste propositie kunt doen om gemeenten en andere overheden te helpen met hun websites (en daarin de webrichtlijnen structureel meenemen), dan is in relatief korte tijd (4 jaar?) een grote stap voorwaarts te zetten. Met een verbeterde monitoring van de daadwerkelijke vooruitgang en de daaraan gekoppelde vertaling vaan consequenties, is het voor iedereen duidelijker waarom die belangenorganisaties zich zo druk maken over een paar webrichtlijnen.

Noot

Nog een korte nabrander: ik heb van september 2008 tot november 2009 bij het ICTU-project webrichtlijnen gewerkt als coördinator van de pilots en de versnellingsagenda. Ik draag de webrichtlijnen een bijzonder warm hart toe. De mening in dit artikel is echter mijn persoonlijke mening en niet die van mijn werkgever ICTU, noch die van het project webrichtlijnen. Overeenkomsten in meningen berusten dan ook op toeval.

In 7 stappen al je WordPress sites onder één WordPress 3 installatie -met eigen URLs

WordPress, het populaire open source weblog-beheer systeem, heeft versie 3, codenaam ‘Thelonius’ vrijgegeven. Een van de vernieuwingen is de mogelijkheid om vanuit één WordPress installatie meerdere WordPress weblogs op te zetten en te beheren: multi-site. Aangezien ik zelf meerdere websites heb die op WordPress draaien, waarvan ik zelf het technische beheer doe, is het een welkome verbetering. Vanaf nu kan ik al die installaties vanuit één centraal punt beheren.

Multi-site is voor gevorderden

Het gebruiken van de multi-site mogelijkheden zijn echter niet voor beginners. Je hebt wat kennis en ervaring met FTP, PHP, DNS en in sommige gevallen zelfs de commandline nodig. De documentatie op de WordPress website gaan er vanuit dat de gebruiker hiervan op de hoogte is. Helaas is dat niet altijd zo. Daarom heb ik geprobeerd een uitgebreide handleiding te schrijven voor het migreren van al je WordPress websites onder één WordPress 3 installatie.

Multi-site voor dummies

Je moet eerst begrijpen hoe WordPress multi-site werkt. En daarvoor moet je weten dat het web uit twee lagen bestaat: de bestandslaag en de adressen-laag.
De bestandslaag is de plek waar de bestanden van het WordPress systeem opgeslagen wordt, net als alle afbeeldingen, downloads etc. De bestanden staan ergens op een webserver, en zijn geordend in mappen en submappen. De bestandslaag bereik je via een FTP programma als FileZilla (PC) of Transmit (Mac). De WordPress bestanden staan vaak in de public_html/ map, welke de hoofdmap is voor de website.

De adressen-laag is waar de doorverwijzigen van het internet-adres naar de juiste mappen en bestanden geregeld worden. Zo wordt www.sitenaam.nl doorverwezen naar de juiste map op de juiste server, zodat de juiste bestanden weergegeven kunnen worden. De doorverwijzingen worden geregeld in het DNS, de Domain Name System.

Virtuele subsites

WordPress 3 gaat uit van 1 hoofdsite, waar alle andere websites ‘onder’ hangen. Die andere sites worden op 2 manieren aangemaakt, als submap (bijv. hoofdsite.nl/sitenaam) of als subdomein (bijv. sitenaam.hoofdsite.nl). Deze ‘subsites’ worden door WordPress beheerd. En dat is belangrijk om te weten, want deze subsites worden niet fysiek aangemaakt in de bestandslaag. ‘Normaal’ is het zo dat als je een subsite maakt (bijvoorbeeld sitenaam.hoofdsite.nl), de bestanden voor die subsite in een submap staan op de server (bijvoorbeeld public_html/sitenaam). In de adres-laag wordt er dan voor gezorgd dat het subdomein verwijst naar die submap. Met WordPress 3 is dat niet het geval. WordPress maakt ‘virtuele’ subdomeinen (en submappen) aan, en regelt zelf dat het adres naar de juiste site doorverwijst.

Aan de slag

Wat we gaan doen is drie WordPress websites migreren naar één hoofdwebsite, met twee subwebsites onder WordPress 3. Dat heet in WordPress termen een ‘netwerk opzetten’. Aan het eind van de rit heb je nog steeds drie verschillende websites, elk met een eigen internet adres (URL), maar kan je de thema’s, plugins, gebruikers en berichten centraal vanuit één website beheren.

Stap 0. Maak back-ups van alle WordPress sites

Dit is altijd belangrijk: als je grote wijzingen aan je websites gaat maken, begin dan eerst met het maken van een complete back-up van je website. Een complete backup is er een van de bestanden én van de database.

Een back-up maken kan op verschillende manieren. Als jouw webhoster cPanel gebruikt is het makkelijk: dan is het een kwestie van op de juiste knopjes klikken, en je hebt een ‘full site back-up’. MediaTemple (mt), waar ik mijn websites host, heeft dit niet. Ik heb via FTP een back-up gemaakt van alle bestanden door deze naar een map op mijn harde schijf te kopiëren. De back-up van de database is niets anders dan een export van de inhoud via PHPMyAdmin, het database-beheer progamma dat (mt) haar klanten biedt.

Stap 1. Exporteer je WordPress websites

Wat we gaan doen is de inhoud, vormgeving en functionaliteiten van de bestaande WordPress websites migreren naar de centrale WordPress 3 website. Daarvoor moet je de inhoud van de bestaande WordPress website exporteren, en later in de nieuw aangemaakt subsite in WordPress 3 importeren.

Het exporteren van de inhoud van een WordPress site is makkelijk: ga naar het beheerscherm van je WordPress site (sitenaam.nl/wp-admin) en ga naar Tools > Export. Zorg ervoor dat je alle berichten en pagina’s exporteert. Er wordt dan een .xml bestand op je computer opgeslagen.

In sommige gevallen is het slim om eerst alle plugins te deactiveren voordat je een export van de inhoud maakt. Doe dit als (straks bij het importeren van de inhoud) blijkt dat je niet alle berichten en pagina’s in het export bestand zijn opgeslagen.

Stap 2. Hoofdwebsite kiezen en voorbereiden

Als eerste moet je weten wat de hoofdwebsite wordt waar alle subwebsites aan komen te hangen. Vanuit deze hoofdwebsite wordt het netwerk gemaakt. Alle modules, thema’s e.d. Die je aan alle subwebsites wilt aanbieden, worden via de hoofdwebsite beschikbaar gesteld. Als er een nieuwe versie van een module of van WordPress zelf uitkomt, werkt je de hoofdwebsite bij, en zijn de updates voor alle andere websites verwerkt.

Als je hoofdwebsite een reeds bestaande website is, werk deze website dan bij naar WordPress 3. Daarmee is het in ieder geval klaar om als hoofdsite gebruikt te worden.

Let op: deze hoofdwebsite mag niet in een submap op de server staan, maar moet in de hoofdmap (root folder) op de server staan -waarschijnlijk genaamd html/ of public_html/.

Stap 3. Maak een wildcard subdomein aan

Hier wordt het technisch, en kan het vervelend worden. Een wildcard is een ‘joker’, en geeft aan dat voor het hoofddomein subdomeinen met alle namen mogelijk gemaakt worden. Dat ziet er zo uit: *.hoofddomein.nl. Dan kan WordPress 3 ervoor zorgen dat sitenaam1.hoofddomein.nl ook daadwerkelijk werkt.

Hoe maak je wildcard subdomeinen aan? Dat is iets wat je met je hosting-provider regelt. Als deze je de mogelijkheid geeft om je eigen DNS-records (zeg maar jouw kaart in het grote adresboek van het internet) aan te passen, kan je het zelf doen. Ga dan naar je cPanel of DNS-beheerpagina en maak een A-record aan met de waarde *.jouwdomeinnaam.nl (vervang jouwdomeinnaam.nl met jouw eigen hoofddomeinnaam, uiteraard).

Kan je niet zelf de DNS aanpassen, of vertrouw je je eigen kennis en ervaring hiermee niet, vraag dan aan je hosting provider of zij een wildcard subdomein voor jouw hoofddomein aan willen maken.

Soms is het niet nodig, omdat deze al standaard is aangemaakt. Zo ook bij (mt). Dan kan je deze stap overslaan.

Stap 4. Multi-site mogelijkheden activeren

De multi-site mogelijkheden van WordPress 3 staan niet standaard aan. Deze moet je activeren. Dit was lastig, omdat je een aantal bestanden moest bewerken en weer op de server moest terugzetten. Maar Jason Grim heeft een plugin geschreven die die acties automagisch uitvoert, de Enable Multi-Site plugin. Deze installeer je via je Plugins > Add new, zoek naar Enable Multi-Site, en klik op de ‘Install’ link. Activeer de plugin en volg de instructies voor het activeren van de multi-site mogelijkheden.

De Enable Multi-Site plugin maakt een ‘netwerk’ aan. Dat netwerk is de paraplu waar alle sub-websites onder komen te vallen. Alle WordPress websites die je aan je netwerk toevoegt, worden beheerd via de hoofdwebsite. Als je aan de hoofdwebsite een nieuwe plugin of thema toevoegt, kan je dat aan alle websites in het netwerk beschikbaar maken.
Zo heb je nu een Super Admin menu er bij gekregen, waarmee je je netwerk kunt beheren. Zo kan je gebruikers aanmaken, plugins en thema’s toevoegen en beschikbaar maken, en websites aan het netwerk toevoegen.

Omdat we in Stap 3 ervoor gekozen hebben om subdomeinen te gebruiken voor het netwerk van WordPress 3 websites, worden alle nieuwe websites in het netwerk aangemaakt als subdomeinen. Bijvoorbeeld: je maakt een nieuwe website aan getiteld ‘test’. Dan zorgt WordPress ervoor dat test.hoofddomein.nl verwijst naar die website. WordPress maakt dan automagisch een ‘kale’ nieuwe website aan op dat adres.

Nu is je WordPress website klaar voor de Multi-Site mogelijkheden. Deze gaan we nu natuurlijk direct benutten. We gaan een test website in het netwerk aanmaken.

Stap 5. Test website in het netwerk aanmaken

Een nieuwe website maak je aan via Superadmin >Sites. Je hoeft maar 3 velden in te vullen: de naam van het subdomein, de naam van de website en het e-mail adres van de beheerder.

We maken nu een testwebsite aan, om te kijken of alles werkt zoals het hoort. Dus gebruik ‘test’ (zonder ‘ uiteraard) als subdomeinnaam, ‘Test website’ als website titel, en jouw eigen e-mail adres als beheerder e-mail. Klik op de ‘Add site’ knop. Nu kan je naar test.jouwdomeinnaam.nl (vervang jouwdomeinnaam.nl met het hoofddomein van jouw eigen website) om te kijken of je nieuwe website is aangemaakt!

Stap 6. Elk subdomein een eigen, uniek internetadres geven

Als je zoals ik bent en meerdere websites met een eigen adres hebt, kan ik me voorstellen dat je de subdomeinen niet wilt gebruiken, maar elke website een eigen adres wilt kunnen geven. Dat kan -als je de domeinnamen bezit uiteraard.

Dat kan, met behulp van de ‘WordPress MU Domain Mapping’ plugin.

LET OP: deze plugin moet je niet direct gaan installeren via de Plugins > Add new methode, want dan gaat het fout! Lees zelf de README instructies goed door voordat je hiermee aan de slag gaat!

Download de plugin naar je hardeschijf, en pak het ZIP bestand uit. Er zitten een paar bestanden in, die je naar verschillende plekken op de server moet verplaatsen. Hiervoor gebruik je een FTP programma. Als je niet weet hoe dat werkt, raadpleeg dan het internet, daar is zeer veel informatie over te vinden. FileZilla is een uitstekend FTP programma voor de PC, en ikzelf ben een groot fan van Transmit voor de Mac.

Het sunrise.php bestand moet naar de wp-content/. map. De installatie-instructies geeft aan dat als er al een sunrise.php bestand aanwezig is, je ze zo goed en kwaad als het gaat moet samenvoegen. Dat betekent dat je de code in moet duiken door met een code-bewerkingsprogramma te kijken welke code aan het sunrise.php bestand op de server toegevoegd moet worden. Maar als je het sunrise.php bestand al hebt, heb je al ervaring met multi-site.

Dan moet je in de wp-content/ map een nieuwe submap aanmaken: mu-plugins/. In die map plaats je het domain-mapping.php bestand.

Tenslotte moet je een kleine aanpassing maken aan het wp-config.php bestand. Dat bestand staat in de hoofdmap (waarin ook de wp-content/ map staat). Download dat bestand naar je hardeschijf, en open het in een tekstbewerker (liefst kladblok of iets dergelijks -gebruik geen MS Word!).
Net boven de regel waar staat

/* That's all, stop editing! Happy blogging. */

voeg je de volgende regel toe:

define( 'SUNRISE', 'on' );

Als die regel er al staat, maar dan met // ervoor, haal dan de // weg en sla het bestand op. Plaats het bijgewerkte bestand vervolgens weer in de hoofdmap, waarbij je het origineel overschrijft.

TIP: Als je dit niet vertrouwt, hernoem dan het origineel eerst naar wp-config.orig alvorens je het bijgewerkte bestand op de server plaatst. Mocht er iets fout gegaan zijn, kan je altijd weer het wp-config.php bestand verwijderen en wp-config.orig hernoemen naar wp-config.php en zo de wijzigingen ongedaan maken!

Nu moet je de plugin activeren via het Plugins menu. En de plugin zo instellen dat het weet waar naartoe het de domeinen moet verwijzen. Immers, het gaat ervoor zorgen dat www.testdomeinnaam.nl de website die we op test.hoofddomein.nl hebben aangemaakt (in het WordPress netwerk) gaat laten zien. Op die manier kan je voor elke website die je aanmaakt in het netwerk, een uniek adres gebruiken.

Ga naar Super Admin > Domain Mapping. De instellingen van de plugin zien er erg technisch uit -en dat zijn ze ook. Echter, het belangrijkste veld is het IP adres of CNAME-hoofddomein veld. Ikzelf heb het IP-adres van de server waarop de hoofdwebsite staat gebruikt. Deze is bekend via het controlepaneel dat ik via de webhosting provider heb gekregen -daar kan je het ook navragen als je het niet weet.

Een andere manier is via een website [http://whatismyipaddress.com/hostname-ip], vul hier jouw hoofddomeinnaam in, en het IP adres van de server wordt zo bekend.

Nu is WordPress er klaar voor om domeinnamen naar de juiste website door te verwijzen.

Nu moeten we nog de domeinnamen zo instellen dat zij verwijzen naar de hoofdwebsite, zodat WordPress ze kan gaan dooverwijzen.

De makkelijkste manier is de domeinen om te zetten naar ‘geparkeerde’ domeinen. Vraag je webhosting provider en/of je domeinbeheerder (vaak zijn dit dezelfde partij, maar dat hoeft niet per sé) hoe zij dat verzorgen. (mt) biedt geen geparkeerde domeinen, maar biedt wel een oplossing. Misschien werken andere hosting providers ook wel op deze manier.

MediaTemple maakt voor elke (sub) domein in het systeem een aparte map aan op de server. Met behulp van een SSH verbinding vervang je de map met een zogenaamde symlink -een soort snelkoppeling. Voor de instructies van (mt) verwijs ik naar hun FAQ pagina. Let op: bij het maken van de symlinks verwijs je naar de hoofdmap. Dat is voldoende om ervoor te zorgen dat WordPress de verdere doorverwijzing kan regelen.

De test of het werkt is de test website die we in de vorige stap hebben aangemaakt. Parkeer of verwijs het unieke domein voor de testsite naar de hoofdsite. Ga naar Super Admin > Sites en schrijf het ID op van de site waar naartoe je het domein wilt laten verwijzen. Vervolgens ga je naar Super Admin > Domains, en geeft je bij Site ID het nummer van de website in het netwerk op, en bij Domain vul je de domeinnaam die je voor die site wilt gaan gebruiken in. Vink ‘Primary’ aan, en klip op ‘Save’.

Als het goed is, verwijst nu testdomein.nl naar test.hoofddomein.nl, zonder dat de bezoeker dat merkt.

Stap 7: Bouw je netwerk met websites

Nu kan je al deze websites beheren via de Super Admin op de hoofdwebsite, en toch elke website in het netwerk een eigen uniek adres geven. Je kan snel bestaande WordPress websites overzetten naar het netwerk door de inhoud te exporteren (via Tools > Export), en de inhoud vervolgens in de nieuw aangemaakt netwerk sites te importeren (via Tools > Import). Maak de nodige aanpassingen aan het domein (parkeren of symlink), en je hebt al je websites onder één installatie!

Veel plezier!

My predictions for the Apple Tablet

It’s only hours away, and thousands of people have talked and published about it already, but here’s my take on today’s event.

Apple has a nice track record for shaking up entire industries by introducing new devices. It changed the way we buy and consume music with the iPod (arguably not the best music player in the field, and not the first either), it changed the mobile phone industry with the introduction of the iPhone (same here, probably not the best smartphone out there, nor the first). The core of the success of these devices wasn’t the device itself, but the way it made accessing and using content easier and more enjoyable. I think we will see a repetition of this strategy later today.

My prediction: the Apple Tablet will shake the media publishing industry to its roots. And that is what the device will be aimed at: consuming rich content.

Just look at this concept movie Time Inc. made last year, and see how this affects the way you consume your favorite magazines and newspapers. Heck, just based on that concept movie alone I’d be willing to pay for subscriptions for rich media content.

[youtube]http://www.youtube.com/watch?v=ntyXvLnxyXk[/youtube]

Now, if Time Inc. makes the content of it’s flagship publications available to be consumed as shown on a device like that, and others (like McGraw Hill, The NYT, Washington Post) follow it’s example, now that would make a device interesting to use.

Sure, I have a MacBook and an Iphone, so why should I want such a device? The answer is in it’s main strength: accessing rich content. And why would publishers enrich their content, basically cannibalizing on their paper publications? Because in-app purchases and content subscriptions for this kind of rich media is the future. You need a MacBook to effectively edit and create content, and an iPhone to access it from your pocket. But to get the maximum (and optimized) rich experience, you’ll need the Mac Tablet.

Now on the iPhone you can get apps for watching missed episodes of TV shows, news channels, newspaper articles, etc. This device will be the platform to access the content I want, when I want, how I want. It’ll be a new revolution, as Time Inc. and McGraw-Hill and the NYT are just the beginning.

What if Amazon.com comes with an app for the Mac Tablet that does exactly what the Kindle does, and more? If this opens up the Amazon Store to a larger audience, with the ease of use we’ve come to expect from Apple’s user interface (as opposed to the Kindle’s UI), this will drive sales for Amazon, making the Kindle less important for them. But that’s what this revolution is all about: content content content.

And because this is an Apple device, it’ll look great, and it’ll be ultra-usable. But it’s not about the device itself, but about the platform it will represent: a new era for media publishing.

So what is this prediction worth? Absolutely nothing. I have no inside information, don’t read all the blogs all the time or just came back from the future. But to me, it makes sense. It fits Apple’s previous strategies to introduce a device with the great ways to use it for something special, not about the specs of the device itself. But this’ll stand or fall with the content publishers. But as you can see from mr. McGraw, they’re as excited as I am.

[youtube]http://www.youtube.com/watch?v=kxXIrdN6Wsc[/youtube]

Resultaten van #durftevragen naar een illustrator

Op 1 januari tweette ik het volgende:

Ik zoek een illustrator/cartoonist/tekenaar die mij wil helpen met illustraties voor nieuwe persoonlijke site! #durftevragen please RT

Die simpele vraag leverde al heel snel een aantal uitstekende reacties op. Om die behulpzaamheid ook voor anderen te bewaren, geeft ik hier een kort overzicht van de suggesties. Continue reading

New site for Child Support Ghana goes live!

Finally, after many hours of work, the new website for the Child Support Ghana NGO and Dutch Foundations is live. Child Support Ghana is a non-profit organization based in the Upper West Region (UWR) capital Wa, Ghana, West Africa, who support needy children by providing them with a roof over their head, loving care, education and healthcare. This organization is the vehicle for the awesome work my dad is doing in Ghana. His work is supported by a Dutch Foundation who raise funds and volunteers for the projects. Doing their website, has been a long standing side project of mine.

The new ChildSupport-Ghana.org website, as created by Herko Coomans

Screenshot of the Child Support Ghana homepage

Continue reading