Je WordPress-sites

Het paneel houdt je WordPress-installaties in de gaten: welke er zijn, of ze bij zijn, en of er een bekend lek in zit.

Eén ding vooraf, omdat het uitmaakt voor alles hieronder: er wordt niets in je WordPress geïnstalleerd. Geen plugin, geen extra bestand, geen account. Het paneel kijkt van buitenaf mee, vanaf de server zelf. Daarom blijft het ook werken als je site het even niet doet, en daarom kun je niets kapotmaken door in WordPress een plugin te verwijderen die je niet herkent.

Hoe een site in beeld komt

Je hoeft niets aan te melden. De server kijkt in je webmappen en herkent een WordPress aan zijn bestanden — of je hem nu via het paneel hebt geïnstalleerd of jaren geleden zelf met een zipje hebt neergezet. Gevonden installaties komen onder beheer te staan en krijgen een kaart.

Gevonden worden: de hoofdmap van je domein, en één map daaronder. Dus jouwsite.nl en jouwsite.nl/blog of jouwsite.nl/webshop gaan vanzelf. Staat je WordPress dieper weggestopt, vraag dan je hostingpartij hem er handmatig bij te zetten.

Onder beheer zetten verandert niets aan je website. Het is een notitie ernaast, geen ingreep erin. Ook eraf halen doet niets met je bestanden.

De markering bovenaan

Naast de paginatitel staat één markering met het WordPress-icoontje ervoor. Die vat de hele lijst samen in één woord:

• groen, bijvoorbeeld 3 SITES — alles bij, niets gevonden. Er is nu niets wat je hoeft te doen.
• amber, bijvoorbeeld 1 VRAAGT AANDACHT — er staat een update klaar of de scanner vond iets. Het getal is het aantal sites, niet het aantal problemen; welke site het is, zie je aan de kaart eronder.

Het icoontje is onze eigen tekening van het WordPress-teken, niet het officiële logo — daarover meer in Het ontwerpsysteem. De markering staat er pas zodra er ten minste één site onder beheer is.

De sitekaart

Per WordPress zie je:

• Welke versie van WordPress erop draait.
• Hoeveel updates klaarstaan — voor WordPress zelf, voor je plugins en voor je thema's.
• Welke PHP-versie de site gebruikt. Die komt uit het paneel, niet uit WordPress: het paneel bepaalt hem, dus het paneel weet hem zeker.
• Of er een SSL-certificaat op staat, en hoe lang dat nog geldig is.
• Of de WordPress-bestanden nog kloppen (zie hieronder).
• Een schermafbeelding van de voorpagina, als je hostingpartij dat heeft aanstaan.

"Gemeten om…"

Bij de kaart staat altijd wanneer er voor het laatst gekeken is. Dat is geen slordigheid maar eerlijkheid: het opmeten van een site kost tijd, dus het gebeurt periodiek en niet elke keer dat jij de pagina opent. Staat er 3 uur geleden, dan is dat wat je ziet — de stand van drie uur geleden.

Een site waar nog nooit naar gekeken is, staat er apart bij als nog niet gemeten. Die telt dus níet stilletjes mee als "alles in orde": "er is niets te doen" en "we hebben nog niet gekeken" zijn verschillende antwoorden.

Bestandscontrole

WordPress publiceert van elke versie een lijst met hoe elk bestand eruit hoort te zien. Het paneel vergelijkt jouw installatie daarmee. Vier uitkomsten:

Aangepast is de enige die alarmerend is: zo ziet het eruit als iemand code in WordPress zelf heeft gezet. Vaak is het onschuldig — een ontwikkelaar die ooit "even iets aanpaste" in een kernbestand — maar het is wel het bericht om je hostingpartij over te mailen.

Bestandsafwijking is meestal ongevaarlijk. WordPress 7.0 levert bijvoorbeeld een paar mappen mee die nog niet in de officiële controlelijst staan; elke verse installatie meldt dat. Daarom is het een aparte uitkomst en geen alarm: een waarschuwing die bij iedereen altijd aanstaat, leest niemand meer.

Kwetsbaarheden

Voor plugins en thema's bestaat een openbare database van bekende lekken. Je hostingpartij haalt die elk uur binnen en vergelijkt hem met wat er op jouw sites geïnstalleerd staat. Vind je een badge bij een plugin, dan zit er een bekend lek in precies de versie die jij draait.

De kleur zegt hoe ernstig het is: kritiek, hoog, middel, laag, of onbekend als de ernst nog niet is vastgesteld. Dat laatste betekent niet "onbelangrijk" — het betekent dat het lek zo vers is dat er nog geen cijfer aan hangt.

Twee dingen die vaak verrassen, en allebei met opzet:

• Een uitgezette plugin telt gewoon mee. De bestanden staan nog op de server en zijn in sommige gevallen ook zonder actieve plugin te bereiken. Uitzetten helpt, weghalen helpt beter.
• "Er is een update" is niet hetzelfde als "het is opgelost". Soms loopt een plugin meerdere versies achter op de versie waarin het lek gedicht is. Het paneel toont daarom in welke versie het écht gerepareerd is.

Wat je eraan doet

Twee knoppen, en welke je nodig hebt hangt ervan af:

1. Bijwerken — er is een versie waarin het lek gedicht is. Dit is bijna altijd het goede antwoord.
2. Uitzetten — er is (nog) geen reparatie uitgebracht. De plugin gaat uit, de bestanden en je instellingen blijven staan, en je kunt hem later met één klik weer aanzetten.

Wanneer het lek gerepareerd is, verdwijnt de badge bij de volgende meting.

Kloppen die cijfers wel?

Twee tijdstempels bepalen hoe actueel een waarschuwing is: wanneer jouw site voor het laatst is opgemeten, en wanneer de lekkendatabase voor het laatst is opgehaald. Het paneel toont ze allebei. Zie je iets wat niet klopt, dan is "even opnieuw meten" de eerste stap — vraag je hostingpartij daarom.

Bijwerken zonder je adem in te houden

Elke update die het paneel voor je uitvoert, doorloopt dezelfde drie stappen — en de middelste is waar het om gaat.

1. Er wordt eerst een herstelpunt gemaakt. Een kopie van de bestanden die gaan veranderen, plus een kopie van de database. Die staat op de server búiten jouw eigen schijfruimte, dus hij telt niet mee in je quota en belandt niet in je volgende backup.
2. De update draait. Je site staat de paar seconden dat de bestanden verwisseld worden in onderhoudsmodus, zodat niemand een half bijgewerkte plugin te zien krijgt.
3. De site wordt nagekeken, op zeven manieren: start WordPress nog, laadt het ook helemaal, staan er nieuwe PHP-fouten in je log, klopt de database nog, zijn de bestanden echt aangekomen, geven je pagina's nog antwoord, en zien die er nog uit als pagina's in plaats van als foutmeldingen.

Gaat er iets mis, dan wordt het automatisch teruggezet. Binnen ongeveer een minuut, zonder dat er iemand naar zit te kijken, en je krijgt een verslag van wat er misging en wat er is teruggezet.

Twee dingen over dat verslag die het waard zijn om te weten:

• Een pagina die vóór de update al stuk was, rekenen we onszelf niet aan. Die wordt als waarschuwing gemeld. De update terugdraaien had hem niet gerepareerd en had het probleem alleen verstopt.
• De database gaat alleen terug als het moet. Bij een update van WordPress zelf altijd — de kern verandert de database, en oude bestanden met een nieuwe database werken niet. Bij een plugin of thema alleen als de database zelf het probleem was. De reden is simpel rekenwerk: de database terugzetten draait ook alles terug wat er sinds de kopie is gebeurd — een bestelling, een reactie, iemand die inlogde.

Bepalen wat vanzelf bijwerkt

Je kiest het per site:

Je kunt ook één plugin uitzonderen — de webshop-plugin die altijd eerst getest moet worden, of juist die ene die zodra er iets uitkomt mee moet.

De standaard voor een nieuwe site is beveiligings- en onderhoudsreleases voor WordPress, beveiligingsfixes voor plugins en thema's. Er wordt niets bijgewerkt voor een functie waar je niet om vroeg; er wordt wél bijgewerkt wanneer níets doen het gevaarlijkere alternatief is.

Eén gevolg dat we er expliciet bij zeggen: zolang het paneel een onderdeel beheert, staan WordPress' eigen automatische updates daarvoor uit. Niet om je iets af te nemen — die updater werkt prima — maar hij kan geen herstelpunt maken, en wat hij om drie uur 's nachts doet kun je om vier uur niet terugdraaien.

En het gebeurt ook echt

Dit is nieuw sinds deze uitgave, en het is eerlijker om te zeggen waarom.

Jouw keuze hierboven werd tot nu alleen uitgevoerd als iemand er een opdracht voor gaf. De nachtelijke ronde keek naar de versie van WordPress zélf: stond je site al op de nieuwste, dan sloeg hij hem over — en daarmee ook de plugins met een gepubliceerd lek erin. Voor de meeste sites, de meeste nachten, gebeurde er dus niets. Dat is gerepareerd: de ronde vraagt nu aan jouw beleid wat er moet gebeuren, en plugins en thema's horen daarbij.

Twee dingen die je daarvan merkt:

• WordPress zelf komt uit onze eigen spiegel. Niet meer rechtstreeks bij wordpress.org: wij halen de uitgave binnen, controleren hem tegen een vastgelegd cijfer en zetten hem pas daarna klaar. Jouw site krijgt dus de versie die wij bekeken hebben, niet wat er die ochtend toevallig stond.
• Een sprong naar een nieuw hoofdnummer gebeurt nooit vanzelf. Van de ene hoofdversie naar de volgende is een verhuizing: de database verandert mee en je plugins moeten die stap ook gemaakt hebben. Die uitgave blijft wel op je kaart staan, zodat je hem zelf kunt kiezen wanneer het jou uitkomt.

Als er 's nachts iets misgaat

Dan hoor je het. De volgende ochtend staat het op je overzicht en krijg je er bericht over, in je eigen taal, met het belangrijkste eerst: je website draait — op de versie van vlak voor de update — en wat nog openstaat is de update zelf.

Hetzelfde geldt voor een plugin of thema dat in de kwetsbaarhedenlijst komt te staan terwijl er een versie is die het dichtzet. Neemt jouw beleid beveiligingsfixes, dan wordt dat in het eerstvolgende venster vanzelf bijgewerkt en hoef je niets te doen; staat je beleid voor dat onderdeel op "niets", dan blijft het lek open tot iemand het bijwerkt of uitzet. Dat is een keuze, en hij is aan jou — maar je weet nu dat hij gemaakt is.

Je site moeilijker te kraken maken

Het paneel heeft een checklist van zestien beveiligingsmaatregelen. Zes ervan worden automatisch toegepast op elke WordPress die het paneel voor je installeert; dat zijn de maatregelen die een werkende site niet kapot kunnen maken. De andere tien kies je zelf, en bij elke maatregel staat wat hij kóst en niet alleen wat hij oplevert — xmlrpc.php blokkeren legt ook de WordPress-app stil, agressieve crawlers weren weert ook crawlers waar je misschien voor betaalt.

Elke maatregel kan weer uit, behalve vier. Die zeggen dat vooraf, en er wordt eerst een herstelpunt gemaakt:

• De admin-account hernoemen — de oude naam wordt niet bewaard, en hem terugzetten zou alleen de zwakke plek terugzetten.
• De beveiligingssleutels vernieuwen — iedereen wordt uitgelogd, inclusief iemand met een gestolen sessie. Dat is precies de bedoeling.
• De databasetabelnamen willekeurig maken — grondig, en een plugin die de standaardnamen hard in zijn code heeft staan gaat stuk.
• De bestandsrechten rechtzetten — hier gaat niets van stuk; de oude rechten worden alleen niet bewaard.

De checklist leest altijd de echte toestand van je site, niet een aantekening die iemand ooit maakte. Zet je een bestand met de hand terug, dan verdwijnt het vinkje.

Eén ding wordt met opzet geweigerd. Staat een map die het paneel moet aanmaken, zoals wp-content/cache, achter een koppeling die buiten je homedirectory wijst, dan volgt de server die niet, en de maatregel zegt waarom. Een koppeling die binnen je eigen home blijft, zoals de document root die een import achterlaat, werkt zoals altijd.

De vier schakelaars

• Onderhoudsmodus — bezoekers krijgen een "zo terug"-pagina met jouw eigen tekst in plaats van de standaardzin van WordPress, en zoekmachines krijgen te horen dat het tijdelijk is.
• Debug-logging — schrijft PHP-fouten naar een logbestand. Die fouten ook aan bezoekers tonen is een aparte schakelaar en staat uit tenzij je erom vraagt: een foutmelding op een pagina verklapt een vreemde de precieze mappenstructuur van de server.
• Zoekmachines — vraagt Google en collega's de site niet te indexeren. Het is een verzoek, geen slot. Moet het écht privé, gebruik dan de volgende.
• Wachtwoordbeveiliging — de hele site, inclusief wp-admin, vraagt om een naam en wachtwoord vóórdat WordPress überhaupt start. Handig zolang een site in aanbouw is.

Teruggaan

Elk herstelpunt dat het paneel maakt staat in een lijst, met waarvoor het was en hoe oud het is. Je kunt er zelf een terugzetten, en er zelf een maken vóór je iets spannends doet. Er worden er vijf per site bewaard; de oudste valt af zodra er een nieuwe bijkomt.

Terugzetten doe je gewoon zelf, in het paneel — daar heb je geen beheerder voor nodig. Twee dingen gebeuren er automatisch omheen:

• Er wordt eerst een herstelpunt gemaakt van hoe de site nú is. Terugzetten vervangt de bestanden en de database; zonder die extra kopie zou er geen weg terug zijn. Lukt die kopie niet, dan wordt er niets teruggezet en hoor je waarom.
• Een herstelpunt hoort bij één site. Eentje van een andere site kun je hier niet gebruiken, ook niet per ongeluk.

Wil je de database laten zoals hij nu is en alleen de bestanden terugdraaien — bijvoorbeeld omdat een plugin-update de boel sloopte maar de bestellingen van vanmiddag moeten blijven — dan kan dat: zet het vinkje voor de database uit.

Waar je dit allemaal vindt

In het paneel: open je account en klik op WordPress in de balk bovenaan — naast Websites, E-mail en Databases. Je ziet een kaart per site met de versie, hoeveel updates klaarstaan, hoeveel lekken er gevonden zijn, en of er een certificaat op zit. Klik op een site en er schuift een paneel open met vijf tabbladen: het overzicht, beveiliging (de checklist en je updatebeleid), de schakelaars, de testomgeving, en het logboek.

Op elke kaart staat ook wanneer er voor het laatst gemeten is. Een site die nog nooit gemeten is, zegt dat — die telt niet stilletjes mee als "schoon".

In één keer alles

Heb je meer dan één WordPress, dan hoef je niet elke site apart te doen. Vink sites aan (of vink niets aan, dan geldt het voor allemaal) en kies:

• Alles bijwerken — elke site krijgt zijn eigen herstelpunt en zijn eigen controles, en draait zichzelf terug als er iets misgaat.
• Alles beveiligen — de kritieke maatregelen op elke site. De drie onomkeerbare doen in een bulkrun nooit mee.
• Beleid voor alle sites — in één keer instellen wat er vanzelf bijwerkt.
• Planner voor alle sites — zie hieronder.

Je krijgt een resultaat per site, ook voor de sites die overgeslagen zijn en waarom. Eén site die faalt stopt de rest niet: dat is precies waarom een site die stuk staat de andere negenennegentig niet onbeveiligd hoeft te laten.

Naar wp-admin zonder wachtwoord

Op het overzicht van een site staat Naar wp-admin. Druk erop en er opent een nieuw tabblad dat, na een tel, gewoon in het beheerscherm van je WordPress-site staat — ingelogd. Je hoeft je WordPress-wachtwoord niet te weten en je hoeft niets te kopiëren.

Stap voor stap

1. Ga naar Websites → WordPress in je account.
2. Klik op de site in de lijst. Er schuift een venster open met vijf tabbladen; je staat op Overzicht.
3. Klik op Naar wp-admin. De knop laat zien dat hij bezig is.
4. Er opent een nieuw tabblad. Even staat er "Bezig met aanmelden…"; daarna staat het dashboard van je site er.

Wat je niet ziet, en waarom dat goed is. Achter die knop zit een eenmalige link, en die link is een sleutel: wie hem heeft is beheerder van die site tot hij gebruikt is of tot hij na vijf minuten vervalt. Het paneel laat hem daarom niet zien, zet hem niet op een kaartje en kopieert hem nergens heen — hij gaat rechtstreeks het nieuwe tabblad in en is daarna op. Gebruik je hem een tweede keer, dan is er niets meer om te gebruiken.

Blijft het tabblad hangen? Als er na een paar tellen nog steeds "Aanmelden lukte niet" staat: sluit het tabblad en probeer het opnieuw. Zie je helemaal geen nieuw tabblad, dan blokkeert je browser pop-ups voor het paneel — sta ze toe voor deze site. En gaat er iets anders mis, dan staat de melding in het venster van de site zelf, niet ergens op de pagina erachter.

Geplande taken die echt draaien

WordPress voert zijn geplande taken standaard uit als er iemand langskomt. Dat gaat op twee manieren mis: een rustige site draait ze nooit (geen backups, geen bevestigingsmail, geen controle op updates), en een drukke site draait ze veel te vaak.

Onder Schakelaars staat Taken via het systeem. Zet je die aan, dan doet de server het — elke vijf minuten, bezoekers of niet — en WordPress zelf houdt ermee op. Je merkt er verder niets van, behalve dat het gaat werken.

Wat de assistent voor je mag doen

Gebruik je de AI-assistent van het paneel, dan mag die over je WordPress-sites alles meekijken: welke sites er zijn, welke versies erop draaien, welke updates klaarstaan, welke lekken er gevonden zijn, of de bestanden kloppen, hoe de schakelaars staan, wat je beleid is en wat de laatste updates gedaan hebben.

En sinds deze versie mag hij, altijd met jouw goedkeuring vooraf, vijf dingen dóen:

• bijwerken via de veilige weg (herstelpunt, controles, automatisch terug);
• een testkopie van een site maken;
• een herstelpunt maken;
• de onderhoudsmodus aan- of uitzetten;
• zoekmachines aan- of uitzetten.

Voordat er iets gebeurt krijg je een kaartje te zien met wat er precies zou veranderen — niet "ik ga plugins bijwerken", maar "hello-dolly 1.6 → 1.7.2, eerst een herstelpunt". Pas als je dat goedkeurt, gebeurt het.

De rest doet hij nooit, hoe je het ook vraagt: aanmelden op je WordPress-beheerpagina, een testkopie naar productie duwen, een herstelpunt terugzetten of weggooien, WordPress of een plugin installeren, de beveiligingsmaatregelen aan- of uitzetten, een wachtwoord op je site zetten, of iets in één keer op al je sites doen. Dat zijn geen instellingen die iemand verkeerd kan zetten — die gereedschappen bestaan simpelweg niet voor de assistent. Op het scherm AI-koppeling staat per stuk waarom.

Zelf op de commandoregel

Heb je SSH-toegang, dan kun je hetzelfde opvragen:

corectl wp sites                     # je sites en hun kaart
corectl wp updates                   # wat er klaarstaat
corectl wp vuln                      # bekende lekken
corectl wp health                    # draait alles nog

corectl wp harden jouwsite.nl        # de beveiligingschecklist en wat aanstaat
corectl wp toggles jouwsite.nl       # de vier schakelaars
corectl wp policy --site jouwsite.nl # wat er vanzelf bijwerkt
corectl wp snapshots --site jouwsite.nl  # je herstelpunten
corectl wp runs --site jouwsite.nl   # wat de laatste updates deden
corectl wp cron --site jouwsite.nl   # wie de geplande taken draait

De veranderende helft kan je hostingpartij daar ook vandaan doen:

corectl wp harden apply jouwsite.nl --measure xmlrpc
corectl wp maintenance  jouwsite.nl --state on --title 'Zo terug'
corectl wp safe-update  jouwsite.nl --type plugin --slug akismet
corectl wp snapshot     jouwsite.nl --note 'voor de themawissel'
corectl wp login        jouwsite.nl   # een eenmalige beheerderslink
corectl wp cron set     jouwsite.nl --state on --minutes 15

# en alles in één keer, met een uitkomst per site
corectl wp bulk secure --account jouwaccount --set critical
corectl wp bulk update --account jouwaccount --dry-run on   # eerst kijken

Iets eerst uitproberen

Word je zenuwachtig van een update of een wijziging, dan kun je een complete tweede kopie van de site maken op een eigen adres, daar dingen stukmaken, en alleen de onderdelen terugduwen die je wilt. Dat is Een testomgeving maken — inclusief het stuk dat de meeste gereedschappen je niet vertellen: gegevens terugduwen is overschrijven, geen samenvoegen.

Waar het paneel jouw WordPress-gegevens bewaart

Het paneel houdt twee dingen over je site bij die niet in je eigen map staan: de schermafdruk die je op de sitekaart ziet, en de lijst met bekende kwetsbaarheden waar je plug-ins tegenaan worden gehouden. Allebei staan ze op de server in een map waar alleen de beheerder bij kan, en sinds de eindcontrole van ronde 2 zijn ze ook alleen door de beheerder te lezen.

Wat er in je eigen map staat verandert daar niet door. Alles wat het paneel in je documentroot schrijft — een .htaccess-regel, een beveiligingsinstelling — houdt precies de rechten die de webserver nodig heeft om het te kunnen lezen. Een regel die de webserver niet mag lezen is namelijk geen regel.

Wil je zien wat er staat, dan kan dat vanaf de server:

ssh root@stck1.corecp.dev 'ls -l /var/lib/corecp/wp/'
ssh root@stck1.corecp.dev 'corectl wp card test300.nl'

Je hoeft hier zelf niets voor te doen; het staat er zodat je weet waar je gegevens liggen als je het ooit wilt controleren.

Je WordPress staat ook op het Applicaties-scherm

Een WordPress is een applicatie zoals een forum of een wiki, dus hij staat ook op Accounts → je account → Applicaties — met zijn herstelpunten, de geschiedenis van elke update die het platform heeft gedraaid, en zijn onderhoudsmodus.

Alles wat specifiek WordPress is, blijft hier: plug-ins en thema's, bekende kwetsbaarheden, de checklist met beveiligingsmaatregelen, de testomgeving, de inlogknop naar wp-admin. Elk scherm verwijst naar het andere, dus welke je ook opent: de rest van het antwoord is één klik weg.

Iets installeren dat geen WordPress is

Heeft je provider de applicatie-installer aangezet, dan staat rechtsboven op deze pagina de knop Open Installatron. Die opent de eigen interface van Installatron in een nieuw tabblad, al ingelogd als jouw account — geen tweede wachtwoord, geen tweede aanmeldscherm.

Het is hún scherm, geen nagebouwde kopie in CoreCP, en dat betekent dat je alles krijgt wat hun installer kan: een paar honderd applicaties, upgrades met één klik, en zijn eigen back-ups van wat hij installeerde.

Staat de knop er niet, dan staat de functie uit voor jouw platform. Zie je in plaats van een knop een zin die zegt dat er nog geen server is ingesteld, dan heeft je provider de functie wel aangezet maar er nog geen Installatron-server aan gekoppeld — daar kun je zelf niets aan doen, en een berichtje aan de helpdesk is de volgende stap.

Lijsten lezen op elk scherm

De lijst met sites is een tabel, en tabellen in CoreCP verdelen hun breedte volgens één regel: precies één kolom rekt mee — hier de naam — en alle andere staan op één regel met een afkapping als het niet past. Daardoor blijft een datum een datum in plaats van drie regels tekst, en schuift geen kolom meer over zijn buurman heen.

Naast elke rij staat een vinkje om er meerdere tegelijk te bewerken. Dat vinkje heeft een naam voor de schermlezer ("<site> selecteren"), maar die naam is niet langer zichtbaar als gewone tekst in de rij: hij stond er twee keer, één keer als kolom en één keer als label.

# de meting die dat bewaakt, over élk scherm van het paneel
node corecp-panel/web/scripts/check-tables.mjs --url=http://127.0.0.1:5199
#   67 table(s) measured, 0 finding(s)

De objectcache waar je site mee praat

Een WordPress-site op een server die er een aanbiedt, gebruikt een objectcache: een kleine key-valueserver die de uitkomsten van databasevragen vasthoudt, zodat dezelfde vraag niet twee keer gesteld wordt. De plugin die daarmee praat heet Redis Object Cache en houdt die naam — maar sinds deze uitgave is de server die antwoordt Valkey.

Voor je site verandert er niets: dezelfde plugin, dezelfde instellingen, dezelfde snelheid. De reden voor de wissel is waar de software vandaan komt — Valkey zit in het deel van Ubuntu dat beveiligingspatches krijgt, en Redis niet. Noemt het statusscherm van je cacheplugin "Redis", dan is dat het protocol dat spreekt, geen vergissing.

Zie ook

• Een testomgeving maken
• Wat je zelf kunt regelen
• Waar een website draait