Elke WordPress installatie bij Kinsta kan zijn eigen gratis WordPress testomgeving hebben, volledig gescheiden van de live productiesite. Dit is ideaal voor het testen van nieuwe WordPress versies, plugins, code, en algemeen ontwikkelingswerk. Maak in enkele minuten een testomgeving en deel deze met je team.

Als je extra testomgevingen wilt toevoegen, een testomgeving nodig hebt die meer overeenkomt met je live omgeving, of als je site-tests of -ontwikkeling met veel resources moet uitvoeren, bekijk dan onze Premium testomgeving add-on.

WordPress testomgeving maken

We hebben het maken van een WordPress testsite zo eenvoudig mogelijk gemaakt. Klik in MyKinsta op WordPress Websites in de linker navigatie. Je ziet een lijst van je sites/installaties. Kies de site waarvoor je een testomgeving wilt maken, klik op de Omgevingskiezer naast de sitenaam, en kies Maak een nieuwe omgeving uit het keuzemenu.

Een nieuwe Kinsta testomgeving maken in MyKinsta
Een nieuwe Kinsta testomgeving maken in MyKinsta.

In de Maak een nieuwe omgeving modal/pop-up die verschijnt geef je je omgeving een naam, kies Standaard omgeving, en klik op de Maak een nieuwe omgeving knop.

De omgevingsnaam moet tussen 3 en 12 tekens lang zijn.

Kies om een standaard testomgeving te maken.
Kies om een standaard testomgeving te maken.

Vervolgens wordt je gevraagd om het type omgeving te kiezen dat je wilt maken. Er zijn drie opties.

  1. Een bestaande omgeving klonen: Met deze optie kun je een bestaande omgeving (live of een premium testomgeving) klonen naar de nieuwe standaard testomgeving.
  2. Geen WordPress installeren: Deze optie installeert een volledig functionele lege WordPress site, klaar om onmiddellijk te gebruiken.
  3. Geen WordPress installeren (lege omgeving): Deze optie installeert alle nodige software om een WordPress site te draaien (webserver, PHP, MySQL, enz.) maar installeert WordPress zelf niet. Dit is een goede optie voor gebruikers die naar Kinsta migreren met Duplicator of een Bedrock/Trellis installatie opzetten met een aangepaste bestandsstructuur.

Optie 1 – Een bestaande omgeving klonen

Met de optie Een bestaande omgeving klonen kun je een bestaande omgeving (live of premium testomgeving) klonen naar de nieuwe standaard testomgeving.

Kloon een bestaande omgeving.
Kloon een bestaande omgeving.

Omgevingsnaam

Als je de omgevingsnaam wilt veranderen, kun je dat hier doen. De omgevingsnaam moet tussen 3 en 12 tekens lang zijn.

Omgeving om te klonen

Kies een bestaande omgeving om te klonen naar de nieuwe standaard testomgeving.

Optie 2 – Installeer WordPress

De optie Installeer WordPress bevat verschillende velden om je site aan te passen. Dit is wat je over elk veld moet weten.

Installeer nieuwe WordPress in je testomgeving.
Installeer nieuwe WordPress in je testomgeving.

Omgevingsnaam

Als je de omgevingsnaam wilt veranderen, kun je dat hier doen. De omgevingsnaam moet tussen de 3 en 12 tekens zijn.

WordPress site titel

Hiermee kun je de sitetitel voor je WordPress site instellen. Afhankelijk van je thema is die zichtbaar voor site bezoekers in de browsertab en op andere plaatsen. Je kunt de site titel wijzigen in de WordPress instellingen na het maken van de site.

WordPress admin gebruikersnaam

Je gebruikt dit om in te loggen op je WordPress installatie. Je kunt er later extra gebruikers aan toevoegen. We raden aan iets anders dan “admin” te kiezen voor de gebruikersnaam voor maximale veiligheid.

Wachtwoord voor WordPress admin

Je gebruikt dit wachtwoord om in te loggen op je installatie. We dwingen automatisch sterke wachtwoorden af om gebruikers te beschermen. Je kunt de optie Nieuw wachtwoord genereren (herlaad icoon) gebruiken als je een nieuw wachtwoord wilt. Hier staat hoe je later je WordPress wachtwoord kunt veranderen.

WordPress admin email

WordPress gebruikt het admin e-mailadres om belangrijke meldingen te sturen.

Selecteer een taal

Kies de taal die je in WordPress wilt gebruiken. Je hoeft geen inhoud te schrijven in dezelfde taal als je WordPress interface, dus voel je vrij om je moedertaal te kiezen, ook al schrijf je inhoud in het Engels.

WordPress Multisite installeren

Kies dit vakje als je een WordPress Multisite installatie wilt maken. Eenmaal geselecteerd kun je kiezen tussen een Subdomein of Submap installatie.

WooCommerce installeren

Als je een e-commerce website maakt, is WooCommerce de meest populaire e-commerce plugin die er is. Vink dit vakje aan om het automatisch te installeren.

Yoast SEO installeren

Yoast SEO is de populairste SEO plugin voor WordPress, met meer dan 3 miljoen installaties en een waardering van 5 van de 5 sterren. Vink dit vakje aan om het automatisch te installeren.

Installeer Easy Digital Downloads

Als je een site maakt om digitale producten te verkopen, is Easy Digital Downloads een complete e-commerce oplossing om digitale producten te verkopen. Vink dit vakje aan om het automatisch te installeren.

Optie 3 – Geen WordPress installeren (lege omgeving)

De optie Geen WordPress installeren is handig voor gebruikers die een lege omgeving nodig hebben voor Duplicator migratie of het testen van een aangepaste Bedrock/Trellis installatie.

Maak een lege nieuwe omgeving zonder WordPress.
Maak een lege nieuwe omgeving zonder WordPress.

Omgevingsnaam

Als je de omgevingsnaam wilt veranderen, kun je dat hier doen. De omgevingsnaam moet tussen 3 en 12 tekens lang zijn.

De standaard testomgeving maken

Als je klaar bent, klik je op de knop Maak een nieuwe omgeving.

Toegang tot je testomgeving

Het aanmaken van de nieuwe omgeving kan een paar minuten duren. Als hij klaar is, kun je de nieuwe standaard testomgeving kiezen in de Omgevingsselector dropdown naast de sitenaam.

Selecteer de standaard testomgeving.
Selecteer de standaard testomgeving.

Elke omgeving heeft een kleurgecodeerde cirkel bij zijn naam: groen voor live, zwart voor standaard testomgeving, en oranje voor premium testomgeving. Je krijgt dan een apart controlepaneel met verbindingsinformatie, DNS, backups, hulpmiddelen, en plugins voor je staging omgeving.

Om snel je testsite te bezoeken, ga je naar de Domeinen tab in je testomgeving en klik je op de URL openen link. Je kunt ook snel naar de WordPress admin van je testsite gaan door op de WordPress Admin openen link te klikken.

URL structuur en domein

De standaard URL structuur van je Standaard Staging Omgeving volgt dit formaat:

https://stg-sitename-environmentname.kinsta.cloud

Als je een oudere testsite hebt, kan je URL er als volgt uitzien:

  • https://staging-sitename-environmentname.kinsta.cloud
  • https://staging-sitename.kinsta.cloud
  • https://staging-sitename.kinsta.com

Je kunt ook een eigen domein aan je testsite toevoegen als je liever een eigen domein gebruikt.

Extra opmerkingen

Als je SSL hebt ingeschakeld op je live site en je kloont de site naar een testsite, dan wordt SSL ook ingeschakeld op je testsite.

Je kunt phpMyAdmin direct vanuit MyKinsta starten. Op het tabblad Info klik je op de link phpMyAdmin openen. De URL structuur voor phpMyAdmin in een testomgeving volgt dit format:

https://mysqleditor-stg-sitename-environmentname.kinsta.cloud

Testomgeving verwijderen en verversen

Als je je testsite moet verwijderen, ga je naar WordPress Websites > sitenaam en schakel je over naar de testomgeving. Scroll naar de onderkant van de pagina en klik op de knop Omgeving verwijderen.

Bevestig in de modal/popup die verschijnt dat je begrijpt wat er verwijderd zal worden, typ de naam van de site gevolgd door een streepje en het woord “staging” (SITENAAM-omgevingsnaam) in het daarvoor bestemde veld, en klik dan op de Omgeving verwijderen knop.

Verwijder een staging omgeving in MyKinsta.
Verwijder een staging omgeving in MyKinsta.

Om je testomgeving te vernieuwen, verwijder je hem, maak je een nieuwe, en kies je Optie 1 – een bestaande omgeving klonen. Deze nieuw gekloonde testomgeving bevat de meest recente versie van je productiedatabase en -bestanden om te testen.

Je kunt ook een backup van je productiesite terugzetten naar de testomgeving. Het voordeel van deze methode is dat als je een custom domein hebt toegevoegd, het niet wordt verwijderd, en dat je het niet telkens hoeft toe te voegen als je de testomgeving vernieuwt.

Testomgeving naar live pushen

Om de database of bestanden van je live site te overschrijven; of om de hele site te overschrijven met je testsite, kun je de feature Testomgeving live pushen gebruiken.

Een WordPress backup naar je testomgeving herstellen

Je kunt je WordPress site ook vanuit een backup direct naar je bestaande testomgeving herstellen. Kijk hier hoe je een WordPress backup naar je testomgeving kunt herstellen. Opmerking: Alle testbackups blijven intact bij het terugzetten van een live backup naar een testomgeving.

Opnieuw starten van de testomgeving

In bepaalde situaties kunnen we een testomgeving stoppen als onderdeel van het oplossen van problemen met de server. Als je merkt dat je testomgeving gestopt is en je ziet een 501 Not Implemented, een 502 Error, of een 521 Error als je je site bezoekt, kun je de testomgeving in MyKinsta opnieuw starten door naar de Info pagina van je site te gaan en op Testomgeving starten te klikken.

Herstart je testomgeving in MyKinsta.
Herstart je testomgeving in MyKinsta.

Als je je testomgeving niet opnieuw kunt starten of de knop niet ziet in MyKinsta, open dan een nieuwe chat met ons ondersteuningsteam voor verdere hulp.

Belangrijke opmerkingen over testomgevingen

Bij gebruik van de testomgeving zijn er verschillende belangrijke dingen waar je op moet letten.

1. Paginacache-instellingen voor testsites

Omdat testomgevingen bedoeld zijn voor ontwikkelingsdoeleinden, debugging, en testen, zijn Kinsta’s full-page caching en OPcache standaard uitgeschakeld. Als je website snelheidstesten uitvoert, zul je hoger dan gemiddelde laadtijden zien omdat de pagina’s niet uit cache worden geleverd. Als je caching op een testsite wilt inschakelen, klik je op de knop Cache inschakelen op de Extra pagina van de testomgeving van je site. Als caching op een testsite is ingeschakeld, wordt de knop Cache wissen ingeschakeld en kun je die gebruiken om de cache te wissen.

Schakel caching in voor een testomgeving.
Schakel caching in voor een testomgeving.

2. Inloggegevens voor de testomgeving

Als de testomgeving een kloon is van je productiesite, zullen je WordPress admin inloggegevens dezelfde zijn voor zowel je live als je testsites, tenzij je ze verandert na het aanmaken van je testomgeving.

3. SEO

Standaard wordt indexering uitgeschakeld voor testsites, zodat ze de SEO op je live/productie site geen schade toebrengen. Dit gebeurt met de combinatie van een WordPress instelling en een HTTP header die we automatisch toevoegen.

Je kunt de WordPress instelling zien door te gaan naar Settings > Reading in het WordPress dashboard van je testsite. De optie om zoekmachines te ontmoedigen de site te indexeren is aangevinkt naast Search Engine Visibility.

Zoekmachine indexering uitgeschakeld op staging site.
Zoekmachine indexering uitgeschakeld op staging site.

Kinsta tijdelijke URL’s en test URL’s hebben ook een robot-beperkende X-Robots-Tag: noindex, nofollow, nosnippet, noarchive HTTP header, wat betekent dat de tijdelijke URL’s niet geïndexeerd worden door de zoekmachines. Deze headers kunnen niet worden verwijderd van tijdelijke Kinsta URL’s of URL’s van testomgevingen. Als je deze headers wilt verwijderen van de testsite, moet je er een aangepast domein aan toevoegen.

4. Plugins

Als je plugins voor planning op sociale media gebruikt, zoals CoSchedule of Social Networks Auto Poster, is het aan te bevelen deze plugins op je testsite uit te schakelen. Anders zouden ze kunnen beginnen met delen naar sociale netwerken via je testURL, die er dan uitziet als: https://stg-sitename-environmentname.kinsta.cloud. Dit zou dan je analytics scheef kunnen trekken.

Sommige plugins, zoals de Jetpack plugin, zullen automatisch in testmode draaien op Kinsta testomgevingen. Je ziet dan een melding als: “Je draait Jetpack op een testserver”. In de testmodus gedraagt je testsite zich in vrijwel alle opzichten als je productie site, behalve dat er geen gegevens worden doorgegeven aan WordPress.com, en dat je de testsite niet kunt ontkoppelen (om een probleem te voorkomen dat tot problemen met je productiesite zou leiden).

Plugins die op domeinnaam gelicentieerd zijn kunnen een eigen domein nodig hebben (in plaats van een Kinsta testsubdomein) om goed te werken. Opmerking: als je eenmaal een eigen domeinnaam aan je testsite hebt toegevoegd, moet je misschien de instellingen bijwerken waar je je pluginlicentie beheert of contact opnemen met de ondersteuningsdienst van je plugin.

5. Noteer je inlog URL

Als je je site naar een testomgeving kloont en een WordPress plugin gebruikt die je standaard inlog URL verandert, wordt het aangepaste deel van de URL naar de testsite gekopieerd. Voorbeeld: http://stg-sitename-environmentname.kinsta.cloud/yourcustomlogin

6. Test moet alleen voor ontwikkeling/testen gebruikt worden

De standaard testomgeving heeft slechts 2 PHP workers, heeft geen optie om Kinsta’s CDN in te schakelen, en kan na 24 uur inactiviteit in slaapstand gaan. Daarom moet hij alleen voor ontwikkeling en testen gebruikt worden. Testomgevingen (standaard en premium) zijn niet ontworpen om te worden gebruikt voor live productiesites, en er kunnen dingen zijn die niet goed werken. Kinsta is niet verantwoordelijk als je een testomgeving voor een live site probeert te gebruiken.

7. Schijfruimte uitgesloten van het pakkettotaal

Om je zoveel mogelijk ruimte te geven, worden testsites uitgesloten van onze rapportage bij het berekenen van je totale schijfruimteverbruik. Alleen live sites tellen mee voor je schijfruimteverbruik.

8. Cron jobs

Server cron jobs van de live omgeving zijn niet actief in de testomgeving (zelfs niet als je je live site naar een testomgeving kloont), dus de cron jobs van de live site zullen niet werken op de testomgeving. Bovendien, als je de crontab in je testomgeving wijzigt en je testomgeving naar je live omgeving pusht, overschrijft die de crontab van je live omgeving.

9. Multisite

Als je een WordPress Multisite netwerk runt, kan het wel of niet werken met onze testomgeving, afhankelijk van hoe je Multisite is opgezet.

  • Als het een submap Multisite is (voorbeeld.com, voorbeeld.com/subsite1, voorbeeld.com/subsite2), werkt hij prima met onze testomgeving.
  • Als het een subdomein Multisite is (voorbeeld.com, subsite1.voorbeeld.com, subsite2.voorbeeld.com), werkt het prima, mits de subsites geen HTTPS nodig hebben.
    • Als het een subdomein Multisite is die HTTPS vereist, moet je een custom domein met een wildcard SSL certificaat toevoegen aan je testsite, zodat de subdomeinen gedekt kunnen worden door een SSL certificaat. Dit komt omdat het SSL certificaat voor de standaard test URL alleen het testsubdomein kan dekken (bijv. stg-sitename-environmentname.kinsta.cloud), dus elk extra subdomein niveau (bijv. subsite.stg-sitename-environmentname.kinsta.cloud) kan niet worden gedekt.
  • Als het een domain-mapped Multisite is (laadt verschillende subsites op totaal verschillende domeinen, bv. voorbeeld.com, voorbeeld1.com, voorbeeld2.com), zal het niet werken zonder aanzienlijke handmatige configuratie.
    • Optie 1: Schakel domain-mapping uit en ga terug naar de standaard submap/subdomein opzet. Doe handmatig een zoek-en-vervang in de database.
    • Optie 2: Zet voor elk live domein testsubdomeinen op, voeg die allemaal toe aan de testsite, en voer handmatig een zoek-en-vervang uit in de database.

10. E-mail

Testomgevingen hebben standaard mail-verzending (transactie e-mail) ingeschakeld. Als je op de testsite een bestelling doet, ontvang je bijbehorende e-mails van de testsite. Als je geen transactiemails van je testomgeving wilt ontvangen, kun je een plugin als Disable Emails gebruiken om te voorkomen dat de site emails verstuurt.

Verwante documentatie