Als je een nieuwe WordPress-site laat bouwen, is er een moment waarop de bouwer zegt: “Volgens mij werkt alles zoals je dat wilt. Hier is de factuur.”
Op dat moment heeft de webbouwer eerst WordPress geïnstalleerd en er vervolgens een aantal wijzigingen op aangebracht. Er zijn plugins geïnstalleerd, er is een thema gekozen en vervolgens gewijzigd, er zijn illustraties, logo’s, headers en kleuren gekozen. Dat is hopelijk netjes gegaan.

Stel dat je over een tijdje iets wilt wijzigen, en de webbouwer is niet meer beschikbaar. Die is misschien wat anders gaan doen, of neemt de telefoon niet meer op. Wat kun je dan nog met je website? Kan een andere bouwer er zó mee aan de slag?

Niet altijd, leert de ervaring.

Er zijn WordPress-websites die zó ingewikkeld zijn, dat het een significante tijd kost om erachter te komen hoe alles werkt. Het zou tijd schelen als alles netjes gedocumenteerd was…Nu is documenteren niet het sterkste punt van veel ontwikkelaars. Maar naar mijn mening mag je van webbouwers wel verwachten dat ze hun beslissingen onderbouwen.

Hier is de inhoudsopgave van de documentatie die Aspidistra Webbouw bij elke nieuwe website aan de klant overhandigt. Gewoon, standaard bij de opdracht. Want je wilt niet dat een volgende webbouwer een dag bezig is om uit te vinden waarom jouw website zus en zo in elkaar zit. Deze lijst is ontstaan uit een in de loop der jaren gegroeide wrevel, en zal nog wel eens aangevuld worden.

Checklijst documentatie nieuwe website

  1. Handleiding beheer website

Een klant hoort zelf Administrator-rechten te krijgen, vind ik, maar de interface van WordPress kan heel overweldigend zijn. Laat de bouwer een aantal verwachte basis-taken even op papier zetten, bijvoorbeeld:

    1. Nieuw bericht aanmaken Dat is over het algemeen niet zo ingewikkeld, maar weet je precies hoe de webbouwer berichten in categorieën ingedeeld heeft? Berichten van de ene categorie komen hier terecht, de andere daar, en voor een derde categorie is er een apart lijstje. Weet je hoe je een uitgelichte afbeelding toevoegt, en waar die dan terecht komt? Hoe ziet dat er op social media uit, als je je bericht wilt delen?
    2. Nieuwe gebruiker aanmaken
    3. Nieuw evenement aanmaken, etc
    4. Inloggen op klantenpanel. Je hebt de sleutels (die je van de provider hebt gekregen) doorgegeven aan de webbouwer om iets moois te maken, maar voor het geval je zelf vergeet hoe je ook alweer in moet loggen, is het handig dat hier even te bewaren. Het kan zijn dat er iets aan de DNS veranderd moet worden, of een e-mailaccount aangemaakt. Dat kan niet via WordPress.
  2. Technische informatie
    1. WordPress-instellingen anders dan verwacht. Bijvoorbeeld een andere tijdzone dan “Europe/Amsterdam”, of een andere datumnotatie. Misschien is de URL van de website wel anders dan je zou verwachten. Kunnen bezoekers automatisch reacties toevoegen aan berichten, of liever niet?
    2. Plugins geïnstalleerd, en waarom. Sommige plugins zijn nodig voor de vormgeving, andere omdat je een speciale wens over de website had.
    3. Subthema. Wat is er toegevoegd ten opzichte van het hoofdthema (templates, functies, stijlen)? Hoe werken de shortcodes/actions/hooks die de webbouwer geprogrammeerd heeft?
    4. Themaopties (via Customizer). Het is altijd een heel gezoek om te zien welke opties er in de Customizer gewijzigd zijn ten opzichte van het thema zoals dat vers geïnstalleerd was. Ook de accent- en steunkleuren dienen gedocumenteerd te worden.
    5. Welke widgets zijn er geïnstalleerd, en waarom? Ook een leuke vraag: waar stáán alle widgets op de website? Het kan wat tijd schelen als de webbouwer jou vertelt dat dat éne leuke tekstje in Footer Widget 7b Rechts staat, zodat je niet één voor één zelf alles open hoeft te klikken. Pas op dat widgets tegenwoordig ook geacht worden een “blokken”-structuur te hebben. Dat heeft nogal wat voeten in de aarde gehad: veel widgets hielden op met werken. Eventuele “classic widgets” zijn eigenlijk niet meer acceptabel, en helemaal niet als je de “Classic Widgets”-plugin nodig hebt om ze te wijzigen of überhaupt zichtbaar te maken. Of het een goed idee was om widgets een blokken-structuur te geven, daarover mopper ik een andere keer verder.
    6. Extra CSS, en waarom; en waarom staat die niet in de style.css van het subthema.
    7. Menu’s (indien noodzakelijk). Sommige websites hebben twee of drie navigatie-menu’s. Welke staat waar op de pagina?
    8. Javascript en/of jQuery, als de webbouwer die toegevoegd heeft.
    9. Database-tabellen als de webbouwer die toegevoegd heeft.
    10. E-mailadressen gebruikt op de website. Er is één algemeen administratief adres, maar diverse formulieren kunnen mail sturen namens andere adressen. Welk adres wordt waar gebruikt?
    11. Contactformulier(en). Hoe werken ze, en wat doen ze.
  3. Licenties en sleutels
    1. Plugins/Thema’s met licentiekosten (hoeveel, hoe vaak, hoe betalen, hoe sleutels beheerd worden). Ik heb meegemaakt dat een website opgeleverd werd met een aantal mooie plugins, waarvan de licentie een jaar later verstreken was, zodat er eerst betaald moest worden. De webbouwer hoort aan te geven welke plugins er geld kosten, hoeveel er voor het thema betaald moet worden, en hoe de procedure is om die licenties te verlengen. En betaalt de klant dat, of de webbouwer?
    2. Sleutels voor Google-diensten (Recaptcha, Maps, Analytics…) wie beheert die? Er is iemand nodig met een Gmail- of Gsuite-adres om die sleutels aan te maken. Dat kun je als klant misschien zelf, maar misschien ook niet. Kan de webbouwer dat overdragen? Of tot in de eeuwigheid zelf beheren?
    3. Sleutels voor overige diensten, zoals Akismet of Jetpack. Net als bij Google-diensten, maar die sleutels kunnen overal zitten. Akismet is een prima anti-spam-tool, maar om het te activeren heb je een WordPress.com-account nodig. Dat weet ook niet iedereen. Als zo’n plugin niet geactiveerd is, kan-ie beter niet geïnstalleerd zijn.