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!

Xoops Foundation LLC verliest rechtszaak tegen Stichting XOOPS en mijzelf

Op 21 april 2010 heeft de rechtbank Zwolle-Lelystad vonnis uitgesproken in de civiele zaak die Xoops Foundation LLC heeft aangespannen tegen Stichting XOOPS en mijzelf. In het vonnis wijst de rechtbank alle eisen van Xoops Foundation LLC af, en veroordeelt hen tot het vergoeden van de proces- en advocaatkosten. Tevens wordt Xoops Foundation LLC door dit vonnis aansprakelijk gehouden voor de schade die is ontstaan door de onterechte beslaglegging op de tegoeden van de bankrekeningen van Stichting XOOPS en mijzelf.

Met dit vonnis is een einde gekomen aan een nare zaak, waarin ik door Michael Beck (alias Mamba) valselijk ben beschuldigd van diefstal, heling en fraude. De zaken waarvan hij mij beschuldigde, en vooral de motivatie en de manier waarop dit hele proces zicht heeft afgespeeld, druist zo in tegen de geest van het open source ontwikkelen van software, dat het een nare, agressieve smaak heeft gekregen.

Belangenbehartiging

Zo claimt Xoops Foundation LLC dat zij de hele (internationale, wereldwijde) XOOPS gemeenschap juridisch vertegenwoordigt. Ze vergelijken zichzelf met de Consumentenbond, om zo helder te maken dat zij namens alle XOOPS gebruikers, ontwikkelaars, testers, ondersteuners, enzovoorts spreken. Echter, in de articles of incorporation die zij de rechtbank stuurde staat nergens vermeld dat Xoops Foundation LLC belangen van wie dan ook behartigt. De rechtbank heeft die claim dan ook verworpen, waardoor Xoops Foundation LLC ontmaskerd is als een partij die alleen haar eigen belang behartigt.

Het is sowieso vreemd dat een partij die door een paar mensen is opgericht ergens begin 2009, zomaar stelt de juridische belangen te behartigen van meer dan 75.000 mensen die zich over de hele wereld verspreid als vrijwilligers en gebruikers bezig houden met XOOPS. Ik ben nog steeds lid van meerdere XOOPS websites, en dus lid van de ‘XOOPS Community’, maar ik heb nergens mijn akkoord gegeven voor het feit dat zij  mijn belang behartigen.
Het is sowieso erg lastig om het belang van de XOOPS gemeenschap te definiëren -laat staan deze juridisch te vertegenwoordigen. De banden die iedereen heeft met het product XOOPS zijn zo divers, dat er nauwelijks een eenduidig belang te vinden zal zijn.
Sterker nog, omdat XOOPS onder de voorwaarden van de GPL licentie is vrijgegeven, wordt iedereen juist belangeloos lid van de XOOPS gemeenschap. Een ieder mag immers voor elk doel alles met het product doen -zonder toestemming vooraf van wie dan ook.

Xoops Foundation LLC is hierin dan ook zijn boekje te buiten gegaan, en heeft zich veel meer macht toegekend dan dat zij eigenlijk in de praktijk -en volgens de rechtbank ook juridisch- mogen veroorloven.

Mi casa es su casa

De tweede eis van Xoops Foundation LLC gaat nog veel verder, en toont de ware aard van het beest. Zij stellen namelijk dat alles dat door het werk van de Stichting XOOPS en mijzelf in de loop der jaren is verzameld als eigendommen van de Stichting en mijn privébezit dat met XOOPS te maken heeft, aan hen toe komt.

Met andere woorden: alles dat iedereen (bedrijven, vrijwilligers en leden van ‘de XOOPS gemeenschap’) aan waarde genereert voor de XOOPS gemeenschap, wordt automatisch juridisch eigendom van Xoops Foundation LLC. En op dat moment verliest de vorige eigenaar alle zeggenschap over wat daar mee gebeurt, en heeft Xoops Foundation LLC het alleenrecht.

Die claim is een frontale aanval op open source software ontwikkeling. Dat is namelijk gebaseerd op vrij(willig) delen. Maar het auteursrecht op alles dat in de gemeenschap gemaakt en gedeeld wordt blijft bij de originele auteur. De GPL licentie zorgt er juist voor dat er een eeuwigdurend, niet in te trekken gebruiksrecht gegeven wordt door de originele auteur. Het auteursrecht wordt niet overgedragen -althans zeker niet bij XOOPS.

Xoops Foundation LLC handelt daarmee direct in strijd met de GPL. En niemand lijkt dat door te hebben.

De rechter heeft het echter wel door. Hij stelt dat Xoops Foundation LLC niet heeft gemotiveerd dat er afspraken zijn waaruit voort zou vloeien dat de bezittingen van Stichting XOOPS en mijn privébezit aan hen toe zou moeten komen. Die eis is dus ook afgewezen.

Géén zelfverrijking

Tenslotte de meest nare beschuldiging die Xoops Foundation LLC aan mij persoonlijk heeft gericht: dat ik geld uit Stichting XOOPS heb gehaald voor privédoeleinden. De rechtbank maakt korte metten met die beschuldiging, daar elk bewijs ontbreekt. Het gaat hier om de xoops.com domeinnaam die ik (aantoonbaar) als privébezit heb aangekocht, en aan de Stichting XOOPS heb verkocht, zodat deze in de inboedel van de Stichting terecht zou komen. De beschuldigingen vloeien voort uit het feit dat ik enig bestuurder was van Stichting XOOPS ten tijde van de transactie, waardoor ik de domeinnaam ogenschijnlijk aan mijzelf verkocht. De rechtbank acht die transactie rechtmatig, gemotiveerd en legaal. En daarmee is ook die kous af.

Eind aan bizarre periode

Ik hoop dat hiermee een eind is gekomen aan een bizarre periode in mijn leven. De impact op je leven als je valselijk beschuldigd wordt van wat dan ook is enorm, zeker als daar beslagleggingen, bodemprocedures, mediacampagnes en laster aan vast zitten. Je kunt je er nauwelijks tegen verdedigen, de publieke opinie lijkt zich snel en makkelijk tegen je te keren.

Gelukkig gaat de rechtbank hier niet in mee, en houdt die haar hoofd koel. Daarmee zijn de beschuldigingen zo makkelijk te weerleggen, dat ze bijna belachelijk lijken.

En ik hoop dat Xoops Foundation LLC de wijsheid krijgt om haar fouten in te zien, en haar verontschuldigingen aanbiedt. Ik denk dat de XOOPS gemeenschap dat wel heeft verdiend.

Big Brother werkt niet bij de overheid

Het Nieuwe Werken guru Henny van Egmond schreef op 20 maart een bericht op zijn weblog, getiteld de ‘20e eeuwse overheid‘. Het eerste deel van dat bericht ging over het nieuwe werken en de overheid, toen het plots veranderde in een klaagzang over Big Brother. Maar dit terzijde.

Henny stelt in zijn bericht:

Ik ben 15 jaar dagbladjournalist geweest bij het Leidsch en Haarlems Dagblad. In de jaren 80 werd er in Leiden een stevig politiek debat gevoerd over de vraag of er op een fietspad naar zo’n fout aangelegde nieuwbouwwijk – een beetje de Leidse Bijlmer – een videocamera mocht worden opgehangen. Vrouwen op dat fietspad werden met enige regelmaat lastiggevallen. Het antwoord van de politiek toen was nee. De privacy van de burger was belangrijker. Er werd gekozen voor stevig snoeien van de struiken, een betere surveillance van de politie en meer straatverlichting.

Nu zouden we in schamper lachen uitbarsten als de politiek een dergelijk besluit zou nemen. Maar het resultaat was verrassend positief. Gedurende vele jaren werd op die plek in Leiden niemand lastiggevallen.

Het antwoord vandaag zou echter meer camera’s zijn. Sterker nog, het antwoord van de laatste jaren is meer camera’s. In Londen word je gemiddeld per dag 3.500 keer gefilmd. In Nederland zal het niet anders zijn. Door je mobiele telefoon kan de overheid vrij simpel uitzoeken tot op vijf meter waar ik nu ben. Dankzij de OV-chipkaart weet de overheid exact welke routes ik per openbaar vervoer neem. En dat ik nooit de bus neem, omdat ik dat zo’n rotvervoermiddel vind.

Dankzij het vastleggen van telefoongegevens en het scannen van emailverkeer kan precies worden vastgesteld met wie ik communiceer en waarover. Om het allemaal compleet te maken worden binnenkort mijn vingerafdrukken genomen als ik mijn paspoort ga vernieuwen. En er zijn al mensen die pleiten voor het afnemen van DNA zodat bij misdrijven voortaan de daders vanachter de databank kunnen worden opgespoord.

En de politici die al deze maatregelen hebben bedacht, die politici  bezweren dat nooit iemand misbruik van al deze gegevens zullen maken.

Gelooft u het?

Ik ben het hier niet (helemaal) mee eens.

Privacy is geen objectief gegeven, maar subjectief, ervaren, gevoeld. Het heeft alles te maken met vertrouwen, en iets met risico’s. En eigenlijk ook niet zo heel veel meer met de overheid als Big Brother. Voorbeeld: in Scandinavië is het gebruiken van het persoonsnummer niet beperkt tot de overheid, maar mogen ook private partijen in binnen- en buitenland daar gebruik van maken. Zo wordt daar het écht zaakgericht werken ingevoerd, en wordt actief informatie gedeeld door allerlei partijen. Waarom zou de bank niet gebruik maken van het unieke nummer dat aan mij is gekoppeld? In Frankrijk en Engeland is dat anders: daar is het juridisch zelfs onmogelijk om tot een uniek nummer voor elke inwoner te komen. Vanwege de angst voor misbruik.

Maar tegelijkertijd laten we onze boodschappen registreren door AH met behulp van de Bonuskaart. En is de OV-chipkaart eigenlijk geen overheidsinitiatief, maar van de gezamenlijke vervoersbedrijven (vaak buitenlands!), om zo een eerlijker verdeling van hun private middelen te organiseren. En is het voor Google tegenwoordig een peulenschil om een heel uitgebreid profiel van al haar geregistreerde gebruikers op te stellen, dankzij iGoogle (alle zoekopdrachten worden 9 maanden bewaard en uitgebreid geanalyseerd!), Google Analytics (van honderduizenden websites weet Google precies wie waar op klikt), en gmail (alle berichten worden zogenaamd anoniem geanalyseerd). De telco’s bewaren de lokatiegegevens al lang, en verkoopt die weer aan derden (TomTom gebruikt Vodafone lokatiedata voor fileinformatie).

En daar vertrouwen we met zijn allen blindelings op, terwijl er geen (democratisch of anderszins) mechanisme is om te controleren of zelfs te beinvloeden hoe die gegevens gebruikt gaan worden. Of waar ze opgeslagen worden. Of dat ik er zelf nog iets mee kan doen. Of zelfs toegang krijg tot mijn data. Er mag dan wel een kloof zijn tussen burgers en overheid, maar dat is voornamelijk een belevingskloof. Want feitelijk is de afstand tussen ons burgers en Google bijvoorbeeld vele malen groter.

Big Brother leeft. Maar hij is geen ambtenaar.

Haiti toont failliet van onze democratie

De aardbeving in Haiti doet veel mensen realiseren hoe betrekkelijk het leven is, op allerlei manieren. Een van de dingen die het voor mij weer eens duidelijk maakt, is hoe belachelijk de Nederlandse/Westerse hang naar een risicoloze samenleving is. Afschuiven van verantwoordelijkheid is de norm, en de politiek, media en maatschappij houden elkaar zo op een gênante wijze bezig. Continue reading