Wet op de webrichtlijnen schiet doel voorbij

Posted on by
Reply

“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

Posted on by
7

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 loses its civil lawsuit against Stichting XOOPS and Herko Coomans

Posted on by
2

On april 21st 2010 the Court of Zwolle-Lelystad in The Netherlands ruled in the civil lawsuit that US-based Xoops Foundation LLC started against Stichting XOOPS (Dutch for XOOPS Foundation) and Herko Coomans, chairman of Stichting XOOPS and formerly an active volunteer in the international XOOPS community and the XOOPS.org website. In its ruling, the Court dismissed all claims of illegal activity of Stichting XOOPS and Herko Coomans as unproven by Xoops Foundation LLC, and sentenced Xoops Foundation LLC to pay due damages to Herko Coomans and Stichting XOOPS.

This brings an end to a 20 month period during which Xoops Foundation LLC made false accusations, legal threats, used aggressive slander campaigns and harassed me and my family. This had direct consequences for my friends and employers, as my reputation was actively being attacked by Xoops Foundation LLC.
The Court dismissed all claims Michael Beck (aka Mamba) made in the name of Xoops Foundation LLC, using nothing more than logic and common sense.

Not created to represent the XOOPS community

Xoops Foundation LLC claimed that in this case, they (legally) represented the XOOPS community. To back this claim, they produced three (yes, 3) signed letters from people claiming they’re active in the XOOPS community (which means they’re volunteers), and that they support Xoops Foundation LLC’s lawsuit. The online petition was dismissed altogether by the Court as irrelevant -anyone can produce a list of names.

Xoops Foundation LLC further claimed that their representation of the XOOPS community is similar to that of the Dutch Consumentenbond (Consumer Union), who had success in other legal disputes with legally representing its members (people who pay for a membership). Xoops Foundation LLC claimed this suit was a Class Action suit by the whole XOOPS community.
The Court dismissed the Class Action suit claim. Legally, a class action suit can only be started by an organization that actually represents its representee’s interests, both in its statutes and articles of incorporation, and in practice. The three letters of support do not impress the Court. In fact, the Court can’t find any claim of Xoops Foundation LLC’s representing the interests of the XOOPS community in its own Articles of Incorporation. In other words: Xoops Foundation LLC was not created to represent the XOOPS community.

I personally think that legal representation of ‘the XOOPS community’ is a farce. First of all, who are ‘the XOOPS community’? All registered accounts on the xoops.org website? Then what about the Spanish, Russian, French, Japanese, Chinese, German and Dutch XOOPS support websites? All registered accounts on those websites as well? If you go by the open and inclusive spirit in the open source world, anyone who uses, has used, developed anything on or with, or derived anything on the software labelled XOOPS and licensed under the GPL, is part of ‘the XOOPS community’. ‘The XOOPS Community’ must be huge, spread over the entire globe, completely undefined and certainly unorganized.
Fact is that only three (yes, 3) members of that enormous international XOOPS community- actively agreed to having Xoops Foundation LLC legally represent their interests. The rest of the international community did not sign for that mandate when they signed up, nor when they already were members of that community.

And what are that XOOPS Community’s interests anyway? Normally, where representation of interests in any form or shape is required, a form of democracy is created to facilitate the difficult process of consensus and shaping of collective interests. ‘The collective’ is not the same as ‘the sum of all’ or ‘the voice that cries loudest’, but embodies ‘the Greater Good’, that which is best for the group. A collective is not necessarily the same as an open source software community.
The way I see it, Xoops Foundation LLC seems to be created to put pressure on myself and Stichting XOOPS to get to the funds I helped organize for the Stichting, and loudly proclaiming that this is in the best interest of the XOOPS Community. Where is the democratic process that decides on what is best for ‘the XOOPS Community’ in its entirety? How is Xoops Foundation LLC governed and controlled by that XOOPS Community?
When I asked Xoops Foundation LLC for that information, I got no answer.

Stichting XOOPS was created in 2004 to support the open source use and development of the XOOPS software, under the terms of the GNU GPL. Nowhere in the Statutes of the Stichting XOOPS will you find any exclusive relationship to any specific part of the XOOPS community. This is done on purpose, as the Stichting was not created to govern any part of the XOOPS community, but to support the open source use and development of the software. This is further explained in the XOOPS Foundation Manifesto, written by the board members of Stichting XOOPS in 2008, where the English development project hosted on the xoops.org websites and the undefinable international community of volunteers, users, developers and supporters, and the Stichting itself, each have a specific role and place.
It is a sad thing that Xoops Foundation LLC tried to claim the XOOPS Foundation Manifesto as one of its own works -so much for openness and sharing- in the case productions. But Xoops Foundation LLC was created in 2009, a full year after the publication of the draft of the Manifesto (it never was finalized as a common governance model for XOOPS). To add to the confusion, later on in Xoops Foundation LLC’s Conclusion of Reply they claim the Manifesto is written by the Stichting and shows that there is a relationship between the project and the foundation. They clearly failed to grasp the concept written down so well in the Manifesto.

The XOOPS Community are intelligent people

Next, the Court dismissed Xoops Foundation LLC’s claim that they are the exclusive not-for-profit organization for XOOPS -and that because of that all assets belonging to Stichting XOOPS should be transferred to Xoops Foundation LLC.
The Court deems the XOOPS Community intelligent people, who can decide for themselves which non-profit organization they will donate their money (or anything else, for that matter) to. Furthermore, it is up to each individual organization to decide how to spend the donations, as it sees fit.

Stichting XOOPS was created to support the open source use and development of the XOOPS system under the terms of the GNU GPL. The license that dictates the terms of the distribution of the code of the XOOPS system states that nobody can put any limitations on how anyone (re)uses that code, including changing the terms of the license. This is the spirit of open source: do not limit how anyone uses the collective work. The GPL does not transfer all copyrights of the (code) author to any central organization. All it does -and its power is in its simplicity- is give everyone a non-revocable, everlasting right to use the code as you see fit. That is what open source means.
So I do not see how any organization can claim property rights of anything created by anyone else in the spirit of open source. I feel that that just goes against the spirit of true openness, one of the foundations (no pun intended) of the open source movement. So if Xoops Foundation LLC claims to work in the spirit of open source, they are proving themselves wrong in this case. It may even be in direct violation of their Articles of Incorporation -and as such, should be held accountable. But by whom? Who has the authority to hold the board of Xoops Foundation LLC accountable for their actions?
Again, when I asked Xoops Foundation LLC this very question, they refused to answer.

This whole claim of a legal commitment from Stichting XOOPS to Xoops Foundation LLC defies logic. First of all, Stichting XOOPS was founded in 2004. Xoops Foundation LLC in 2009. There simply was no Xoops Foundation LLC to commit any rights of ownership to when Stichting XOOPS’ statutes were written.
Secondly, how would creating a legal entity such as Xoops Foundation LLC in another country, with similar goals, mean that legal ownership of assets is automatically transferred to that newly created organization? If I created a ‘Planet Wildlife Foundation’ here in the Netherlands, and give it similar goals as the WWF, would that entitle my newly formed organization to any and all assets of the WWF? Of course not! Anyone can understand that by that example. Why would it be any different in the case of Stichting XOOPS and Xoops Foundation LLC? The Court saw right through the claim and dismissed it.
It gets stranger still: Xoops Foundation LLC claimed that because I researched if it were possible and sensible to create a US-based Foundation before we founded it here in The Netherlands, Xoops Foundation LLC, being actually based in the United States, is the One True Foundation. All this strikes me as extremely far-fetched, illogical and just plain dumb.

Free as in Freedom

Finally, the Court dismissed Xoops Foundation LLC’s claim that by selling the xoops.com domain -which they claim is not even my personal property- to Stichting XOOPS for 4.000 euro means that I embezzled money -which they claim is theirs anyway- from Stichting XOOPS for private use.
The Court states that I clearly proved that I acquired the xoops.com domain as a personal asset and not as a representative of the XOOPS community. Xoops Foundation LLC failed to prove that they are legally entitled to the xoops.com domain. Stichting XOOPS is in its right to acquire the domain for any sum it deems fit, so the Court did not see any legal obligations for this transaction. So it dismissed the claim.

This claim hurt me the most. Practically, as this was the main argument to have my personal and the Stichting bank accounts (including the household account my wife and I use) frozen and seized for the amount of 25.000 euro’s. This means a whole lot of reorganization, plus a huge amount of hassle. But maybe more so emotionally, as now my wife was a victim of this suit too. And the accusation itself is harsh too: I would have stolen money from them! And this accusation was made in public too, something being picked up by popular media here in The Netherlands. My reputation was under attack, and my defense was only in court. I don’t know if you know what it means to be accused of something you didn’t do in public, but it hurts. A lot. I had sleepless nights because of this. So did my wife. And I has to inform my employers, as it was my full name they published everywhere. Suddenly it wasn’t just me fighting a battle in the virtual world -how sad and bad it may be in its own right- now it was my family, friends, my employer and my reputation that was under attack.
And for what?
I bought the xoops.com domain before Stichting XOOPS was created. So I couldn’t have bought it on its behalf. At the time, I was an active volunteer on the xoops.org website, managing some aspects of the community there. I called myself the XOOPS.org project manager. But all I was -all everyone who donates time and other resources on xoops.org is, is a volunteer. Should that mean that everything I do goes to the community (and as Xoops Foundation LLC claims, its legal representative)?
Of course not. The Open Source business model is built around the concept of Free Software. Apparently Xoops Foundation LLC thinks that it means that I am legally bound to give all my resources away for free, as in gratis. But as most of you know, the ‘free’ in Free Software stands for Freedom. As in Freedom of Speech. As in Freedom to do with my resources what I want to do with them. Be it make them available for use in a common pool -such as a community- or not. This Freedom is what powers Open Source Software development. It is what makes it great: open and free. Who are Xoops Foundation LLC to take away that freedom?

One last thing. What Xoops Foundation LLC fails to communicate about the (legally valid) transaction of the xoops.com domain from my personal to the Stichting’s assets, is that I had the domain valued by three (yes, 3) different independent domain valuating services. The lowest value of xoops.com was $6.500, the highest $14.000. The 4.000 euro -which translates to about $5.500 is below xoops.com’s market value. And now the xoops.com domain can be used by Stichting XOOPS to support the open source use and development of the XOOPS system under the terms of the GNU GPL.
One way to look at it, is that I donated $1.000 to $8.500 to the Stichting. If it now decides to sell it for its real market value, it’d have made a hell of a deal for the support of the open source use and development of the XOOPS system. And isn’t that what the XOOPS Community is all about?