Met een aparte WordPress-testomgeving kunt u een plugin, thema of update proberen voordat bezoekers ermee werken. WP Toolkit kan de website voor u klonen. Daarna controleert u zelf of de kopie een eigen database gebruikt, afgeschermd is en geen echte klantacties uitvoert.
1. Kies de bron en bereid een lege bestemming voor
Log in op Plesk met toegang tot de betreffende website en open “WordPress” of “WP Toolkit”. Controleer het domein op de installatiekaart. Maak eerst een recente backup en zorg dat er genoeg ruimte is voor de websitebestanden en een tweede database. Ontbreekt de kloonfunctie, laat dan de rechten en beschikbare licentie controleren.
Kies een afzonderlijk testadres, bijvoorbeeld staging.example.com, met een eigen documentroot. Gebruik een lege bestemming: klonen kan bestaande inhoud daar overschrijven. Controleer onder “Websites & Domains” dat uw testadres naar de bedoelde hosting wijst en een geldig HTTPS-certificaat krijgt. Bewaar bronadres, testadres en doelmap in uw eigen testplan.
Een kopie kan dezelfde klantgegevens en toegang tot externe diensten bevatten als productie. Regel daarom vooraf toegangsbeperking voor de bestemming. Laat bij een actieve webshop of automatische koppelingen ook uitgaande mail, API-acties en achtergrondtaken voor de testomgeving afschermen voordat u kloont. Een wachtwoord voor bezoekers blokkeert geen uitgaand verkeer vanaf de server.
2. Maak de kopie in WP Toolkit
Klik op “Clone” op de kaart van de broninstallatie.
Kies “Create subdomain” voor een nieuw subdomein, of “Use existing domain or subdomain” voor de lege bestemming die u heeft voorbereid.
Controleer de doelnaam en de nieuwe database. Pas de voorgestelde databasenaam zo nodig aan zodat u de testkopie herkent.
Klik op “Start” en wacht tot de nieuwe installatiekaart verschijnt. Controleer de taakmelding voordat u verdergaat.
Deze Engelse labels volgen de Plesk-handleiding voor klonen. De vertaling en zichtbare opties kunnen per account verschillen. Controleer op de kaart van de kopie nogmaals het adres. Een herkenbaar label zoals staging helpt om de twee installaties uit elkaar te houden.
3. Scherm de kopie af en controleer de database
Zet op de kaart van de testkopie “Password protection” aan, kies afzonderlijke toegangsgegevens en bevestig met “Protect”. Schakel ook “Search engine indexing” uit. Controleer in een nieuw privévenster dat zonder de extra toegang geen website-inhoud verschijnt. Alleen de WordPress-inlogpagina of noindex is geen afscherming van alle pagina’s en bestanden.
Controleer via de bestandsbeheerder het wp-config.php van de testkopie. De waarde van DB_NAME moet bij de nieuwe database horen, niet bij de productiedatabase. Vergelijk alleen de benodigde instellingen en deel het volledige bestand niet. Staat Redis of een andere externe cache aan, controleer dan ook dat de testkopie geen ongewenst gedeelde cache van productie gebruikt.
Open de testsite pas wanneer de toegang en externe acties onder controle zijn. Controleer het adres in de browser en in WordPress bij “Instellingen”, “Algemeen”. Loop enkele interne links na. Een knop die teruggaat naar het live domein kan anders een testactie op productie uitvoeren.
4. Zet mail, betalingen en koppelingen in teststand
E-mail: gebruik een mailopvang of gecontroleerde testontvanger voor de kopie. Controleer zowel WordPress-mail als een SMTP- of maildienstplugin. Stuur testberichten niet naar echte klanten.
Betalingen: gebruik de sandbox van de betaalprovider met bijbehorende testsleutels. Controleer welke callback- of webhookadressen de testomgeving gebruikt. “Start” geen echte betaling om te zien of klonen is gelukt.
Koppelingen: controleer voorraad, boekhouding, nieuwsbrief, CRM en externe opslag. Gebruik testaccounts of schakel de koppeling op de kopie uit. Een andere domeinnaam verandert gekopieerde API-sleutels niet vanzelf.
Achtergrondtaken: controleer WordPress-taken, “Geplande taken” in Plesk en externe triggers. Stop of verplaats alleen taken van de testkopie. De productieplanning moet blijven werken.
De WP Toolkit-optie “Take over wp-cron.php” verplaatst de aansturing naar een geplande taak. Dat is geen algemene pauzeknop voor alle WordPress-taken. Loop de planning en de relevante pluginwachtrijen na voordat u testgegevens gaat invoeren. Bij een afgeschermde site kunnen callbacks juist niet binnenkomen; stem een testbare route af zonder de hele kopie openbaar te maken.
5. Gebruik een vast controlelijstje
Project:
Bronadres:
Testadres:
Datum van de kopie:
Doel van de test:
[ ] Testadres en documentroot zijn anders dan productie
[ ] Eigen database gecontroleerd
[ ] Toegang zonder wachtwoord wordt geweigerd
[ ] Zoekmachine-indexering staat uit
[ ] Mail gaat alleen naar een testbestemming
[ ] Betalingen gebruiken sandbox en testsleutels
[ ] API-koppelingen en webhooks zijn gecontroleerd
[ ] Achtergrondtaken voor de kopie zijn gecontroleerd
[ ] Cache-inrichting is passend voor de testkopie
[ ] Pagina's, inloggen en formulieren werken
[ ] Webshopscenario in teststand doorlopen, indien van toepassing
[ ] Wijzigingen, versies en bevindingen vastgelegd
Geteste wijziging:
Verwachte uitkomst:
Werkelijke uitkomst:
Nog te herstellen:
Wie geeft akkoord voor de volgende stap:Kopieer de lijst naar uw projectdocument. Noteer geen wachtwoorden, API-sleutels of volledige klantgegevens.
Begin met een controle van de ongewijzigde kopie. Werkt die al niet goed, los dat eerst op. Voer daarna één samenhangende wijziging uit en herhaal dezelfde controles. Bekijk ook de mobiele weergave en relevante foutlogs. Het kunnen openen van alleen de homepage is geen volledige test van een webshop of applicatie.
6. Als het klonen of testen niet lukt
“Clone” ontbreekt: controleer de juiste installatiekaart en vraag welke kloonrechten en functies bij uw account horen.
De taak mislukt: lees de foutmelding en controleer vrije ruimte, doelmap en database. “Start” niet herhaaldelijk een kloon naar een bestemming waarvan de inhoud onduidelijk is.
De kopie opent de live site: controleer het testadres, redirects en applicatie-instellingen. Test pas verder wanneer duidelijk is welke installatie de actie verwerkt.
Een formulier of betaling geeft geen callback: controleer de testsleutels en bereikbaarheid van het testadres. Wachtwoordbeveiliging kan de callback tegenhouden; haal die niet zonder afstemming voor de hele site weg.
Een onverwachte mail of voorraadwijziging: stop de betreffende actie op de kopie, bewaar de melding en controleer welke koppeling nog productietoegang gebruikt.
7. Bepaal wat er terug naar productie gaat
Een geslaagde proef maakt de kopie niet automatisch geschikt om in zijn geheel terug te zetten. Sinds het klonen kunnen op productie nieuwe bestellingen, accounts en berichten zijn toegevoegd. Gebruik het plan voor staging naar productie om te bepalen welke bestanden en instellingen worden overgenomen. De WooCommerce-uitleg over updates behandelt ook testen en backups rond wijzigingen.
Verwijder de testomgeving zodra die niet meer nodig is, inclusief overbodige database, testtoegangen en tijdelijke sleutels. Controleer vóór verwijderen de domeinnaam en map opnieuw. Bewaar de testbevindingen bij uw project. Zo weet u welke wijziging is gecontroleerd en hoeft u voor een volgende update niet opnieuw te bedenken wat u moet nalopen.
Voorbeeld: één pluginupdate beoordelen
Maak eerst de ongewijzigde testkopie functioneel werkend. Noteer de huidige WordPress-, PHP-, thema- en pluginversies. Kies vervolgens één pluginupdate en beschrijf welke bezoekerstaak daarvan afhankelijk is, bijvoorbeeld het invullen van een formulier of het berekenen van verzendkosten. Gebruik een testontvanger of sandbox voor de verwerking.
Voer diezelfde taak vóór en na de update uit. Controleer zowel de bevestiging voor de bezoeker als de verwerking in het beheer of de externe testdienst. Werkt de nieuwe versie niet, herstel de testomgeving of draai de wijziging daar terug. Pas productie pas aan met een apart plan en een actuele backup; neem een oudere testdatabase niet automatisch over.
Toegang en achtergrondtaken opnieuw controleren
Open na wijzigingen nogmaals een privévenster zonder bestaande logins en controleer dat de testsite afgeschermd blijft. Bekijk of er geen andere kopie, publiek archief of alternatieve domeinnaam toegang tot dezelfde gegevens geeft. Een wachtwoord op één adres beschermt niet automatisch iedere andere route naar de bestanden.
Controleer daarnaast dat de beoogde testtaken worden uitgevoerd en productietaken niet dubbel draaien. Als afscherming een testcallback blokkeert, regel dan een beperkte route voor die test. Maak niet de hele kopie openbaar om één integratie te kunnen proberen. Leg na afronding vast welke tijdelijke uitzondering weer is ingetrokken.