Testomgevingen

Elke WordPress installatie bij Kinsta kan zijn eigen gratis WordPress testomgeving hebben, volledig gescheiden van de live productiesite. Dit is erg handig voor het testen van nieuwe WordPress versies, plugins, code en algemeen ontwikkelwerk. Je maakt namelijk in een paar minuten een dev site en deelt 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 intensief moet testen of ontwikkelen, bekijk dan onze Premium testomgeving add-on.

Standaard vs. Premium testomgeving

Je kunt tot 5 Premium testomgevingen toevoegen, deze bevatten meer resources en meer functies dan Standaard omgevingen. De volgende tabel toont de verschillen tussen onze Standaard en Premium testomgevingen:

	Premium	Standaard
PHP workers	Hetzelfde als je live omgeving	1
CPU	12	1
RAM	8 GB	8 GB
CDN	Ja	Geen
Edge Caching	Ja, kan worden ingeschakeld	Geen

Lees meer over onze Premium testomgevingen add-on.

WordPress Standaard of Premium testomgeving maken

We hebben het maken van een WordPress testsite zo eenvoudig mogelijk gemaakt. Klik in MyKinsta op WordPres sites in de linker navigatie. Je ziet een lijst met je sites/installaties. Selecteer de site waarvoor je een testomgeving wilt maken, klik op het vak Ga naar of zoek en selecteer Nieuwe omgeving maken.

In de modal/popup Nieuwe omgeving maken die verschijnt, selecteer je Standaard of Premium omgeving en klik je op Doorgaan.

Vervolgens wordt je gevraagd om het type omgeving te selecteren 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 testomgeving.
2. Installeer nieuwe WordPress: Deze optie installeert een volledig functionele lege WordPress site, klaar om direct te gebruiken.
3. Lege omgeving (zonder WordPress): Deze optie installeert alle benodigde software om een WordPress site te draaien (webserver, PHP, MySQL, etc.) maar installeert WordPress zelf niet. Dit is een goede optie voor gebruikers die migreren naar Kinsta met Duplicator of een Bedrock/Trellis installatie opzetten met een aangepaste bestandsstructuur.

Optie één – Een bestaande omgeving klonen

Met de optie Een bestaande omgeving klonen kun je elke bestaande omgeving (Live of Premium testomgeving) klonen naar de nieuwe testomgeving.

• Naam omgeving: Voer een naam in voor de testomgeving; deze moet tussen 3 en 12 tekens lang zijn.
• Omgeving om te klonen: Kies een bestaande omgeving om te klonen naar de nieuwe testomgeving.

Optie twee – Nieuwe WordPress installeren

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

• Omgevingnaam: Voer een naam in voor de testomgeving; deze moet tussen de 3 en 12 tekens lang zijn.
• WordPress site titel: Hiermee kun je de sitetitel voor je WordPress site instellen. Afhankelijk van je thema zal deze zichtbaar zijn voor bezoekers van de site in het browsertabblad en op andere plaatsen. Je kunt de sitetitel wijzigen in de WordPress instellingen na het maken van de site.
• WordPress admin gebruikersnaam: Deze gebruik je om in te loggen op je WordPress installatie. Je kunt later extra gebruikers toevoegen. We raden aan om iets anders dan “admin” als gebruikersnaam te kiezen voor maximale veiligheid.
• WordPress admin wachtwoord: Dit wachtwoord gebruik je om in te loggen op je installatie. We dwingen automatisch sterke wachtwoorden af om gebruikers te beschermen. Je kunt de optie Nieuw wachtwoord genereren (pictogram herladen) gebruiken als je een nieuw wachtwoord wilt. Hier lees je hoe je later je WordPress wachtwoord kunt wijzigen.
• WordPress admin e-mail: WordPress gebruikt het admin e-mailadres om belangrijke meldingen te versturen.
• Selecteer een taal: Selecteer de taal die je wilt gebruiken in WordPress. Je hoeft inhoud niet in dezelfde taal te schrijven als je WordPress interface, dus voel je vrij om je moedertaal te kiezen, zelfs als je inhoud in het Engels schrijft.
• Installeer WordPress multisite: Selecteer dit vakje als je een WordPress Multisite installatie wilt maken. Eenmaal geselecteerd, kun je kiezen tussen een Subdomein of Subdirectory installatie.
• WooCommerce installeren: Als je een e-commerce website maakt, is WooCommerce de populairste 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.
• Easy Digital Downloads installeren: Als je een site maakt om digitale producten te verkopen, dan is Easy Digital Downloads een volledige eCommerce oplossing voor het verkopen van digitale producten. Vink dit vakje aan om het automatisch te installeren.

Optie drie – Lege omgeving (zonder WordPress)

De optie Lege omgeving is handig voor gebruikers die een lege omgeving nodig hebben voor een Duplicator migratie of het testen van een custom Bedrock/Trellis installatie.

• Omgevingsnaam: Voer een naam in voor de testomgeving; deze moet tussen de 3 en 12 tekens lang zijn.

De testomgeving maken

Klik op Doorgaan als je klaar bent. Als je een Premium omgeving aanmaakt, bevestig dan het terugkerende abonnement en klik op Premium omgeving aanmaken.

Toegang tot je testomgeving

Het aanmaken van de nieuwe omgeving kan een paar minuten duren. Als hij klaar is, klik je op het vakje Ga naar of zoek en selecteer je de omgeving.

Je kunt de testomgeving ook openen vanuit de WordPress sites lijst.

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 configuratiescherm met verbindingsinformatie, DNS, backups, tools en plugins voor je testomgeving.

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

URL-structuur en domein

De standaard URL-structuur van je testomgeving volgt deze indeling:

• Standaard: https://stg-sitenaam-omgevingsnaam.kinsta.cloud
• Premium: https://env-sitenaam-omgevingsnaam.kinsta.cloud

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

• https://staging-sitenaam-omgevingsnaam.kinsta.cloud
• https://staging-sitenaam.kinsta.cloud
• https://staging-sitenaam.kinsta.com

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

Aanvullende opmerkingen

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

Je kunt phpMyAdmin starten vanuit MyKinsta. Klik op het tabblad Info op de link Open phpMyAdmin. De URL-structuur voor phpMyAdmin testomgeving volgt dit format:

https://mysqleditor-stg-sitenaam-omgevingsnaam.kinsta.cloud

De testomgeving vernieuwen

Als je wijzigingen aanbrengt in je live site nadat je de testomgeving hebt aangemaakt en deze wijzigingen wilt weergeven in testomgeving, kun je een selective push gebruiken om je testomgeving bij te werken. Op deze manier hoef je de testomgeving niet te verwijderen en opnieuw aan te maken, wat tijd bespaart en eventuele testbackups behoudt.

Omgeving naar live of test pushen

Je kunt je WordPress testomgeving naar je live omgeving pushen als je tevreden bent met de wijzigingen die je hebt gemaakt en wilt dat ze worden toegepast op je live site.

Je kunt ook je live omgeving naar je testomgeving pushen. Dit is handig voor het verversen van de testomgeving om wijzigingen in je live omgeving weer te geven.

Met de Selective Push feature heb je uitgebreide controle over wat je wilt pushen. Specifiek kun je pushen:

• alleen je bestanden,
• alleen je database,
• specifieke bestanden en mappen,
• specifieke databasetabellen,
• alles.

Het pushen van omgevingen kan in slechts een paar klikken worden gedaan, maar lees de opmerkingen hieronder voordat je verder gaat. Ze bevatten essentiële informatie over het proces.

Belangrijke opmerkingen

• We raden aan om de Push Omgeving feature voorzichtig te gebruiken, vooral bij het pushen van test naar live. Zet het proces in gang op momenten dat er weinig verkeer is en zorg dat er een ontwikkelaar beschikbaar is voor het geval er problemen optreden. Als je de hulp van een ontwikkelaar nodig hebt, kun je die op verschillende plaatsen inhuren.
• Wij maken automatisch een backup zodat je indien nodig terug kunt gaan. Opmerking: Als je live site een e-commerce of andere dynamische en snel veranderende site is, kunnen er gegevens verloren gaan tussen het moment dat je pusht en het moment dat de backup wordt teruggezet.
• Omgevingsinstellingen (redirects, geolocatie, PHP en Nginx configuratie, etc.) worden meegenomen in de push (zelfs als alleen Bestanden of Database is geselecteerd) en zullen de instellingen van de omgeving volledig overschrijven.
• Zodra een push van test naar live is voltooid, verwijder dan alle ingebouwde cache in je thema of plugins, leeg de cache van je browser en test je site om te zien of hij werkt zoals verwacht.
• Als je bij het pushen van je database de optie Zoeken & vervangen uitvoeren aanvinkt, wordt het domein automatisch vervangen door het domein van de omgeving waarnaar je pusht.
• Als je Alle bestanden en mappen selecteert, worden alle bestanden gepusht, inclusief plugins, thema’s en bestanden in wp-content/uploads.
• Eventuele hardgecodeerde URL’s in je thema- of plugincode moeten worden bijgewerkt naar de URL van de omgeving.
• Als wachtwoordbeveiliging (.htpasswd) actief is op de omgeving van waaruit je pusht, wordt deze niet toegepast op de omgeving waarnaar je pusht. Je moet het inschakelen in de omgeving na de push.
• Als je WooCommerce gebruikt, maakt MyKinsta geen onderscheid tussen nieuwe bestellingen van klanten en oudere bestellingen wanneer je van test naar live pusht. Wanneer je een push naar live start, als je alle bestanden en mappen pusht, kopieert MyKinsta je testsite naar de live site precies zoals hij is, terwijl bestanden en de database worden overschreven. Om dit te omzeilen kun je
  • Testomgeving naar live pushen met een Selective Push en alleen bestanden pushen zodat je database niet wordt overschreven.
  • Selectief databasetabellen pushen en de benodigde WooCommerce tabellen uitsluiten.
  • De databasebestanden van live naar test pushen voordat je test naar live pusht om ervoor te zorgen dat je de meest actuele gegevens hebt.

  Raadpleeg de WooCommerce Database Beschrijving voor informatie over wat er in elke WooCommerce databasetabel staat. Bespreek deze taak met je webontwikkelaar. Als je die niet hebt of je weet het niet zeker, bekijk dan ons artikel over het inhuren van een WordPress ontwikkelaar.

• Wanneer je test naar live pusht, dubbelcheck de testsite en los eventuele fouten op voordat je naar live pusht.
• testomgevingen zijn alleen bedoeld voor ontwikkeling en testen. Ze zijn niet ontworpen om te worden gebruikt als live productiesites, en er kunnen dingen zijn die niet werken zoals verwacht. Kinsta is niet verantwoordelijk als je een testomgeving probeert te gebruiken voor een live site.
• Het pushen van een omgeving heeft geen invloed op de omgeving van waaruit je pusht, en deze blijft gescheiden van de andere omgevingen. Nadat je een testsite naar live hebt gepushed, kun je doorgaan met het ontwikkelen en testen van wijzigingen in de testsite zonder dat dit invloed heeft op je live site, totdat je de wijzigingen weer naar live pusht.
• Het pushen van test naar live zal niet interfereren met Kinsta’s CDN als het draait op je live site, maar we raden wel aan om de CDN cache te wissen na het pushen (WordPress sites > sitenaam > Caching > CDN > CDN cache wissen).
• Push voorzichtig van test naar live als je site een Multisite netwerk is. Het pushen van de database kan wel of niet werken, afhankelijk van hoe de multisite is ingesteld. Als je selectief pushen gebruikt en Alle databasetabellen of Alle databasetabellen en Alle bestanden en mappen pusht, dan wordt de volledige database-inhoud naar live gepusht en heeft dit invloed op alle sites (de hoofdsite en subsites) in je multisite netwerk.
• Als je een niet-standaard WordPress setup gebruikt, zoals Bedrock of Trellis, kan het zijn dat Kinsta de variabele DB_PASSWORD niet kan vinden en daarom het database wachtwoord niet kan bijwerken wanneer je de testomgeving naar live zet. In dit scenario moet je, wanneer je de omgeving naar live zet, handmatig het bestand bijwerken waarin je de DB_PASSWORD definieert met het nieuwe databasewachtwoord zoals gedefinieerd binnen MyKinsta.

Een omgeving pushen met een Selective Push

Volg de onderstaande stappen om je omgeving naar een andere omgeving te pushen. Met de Selective Push workflow kun je kiezen wat je wilt pushen.

1. Je omgeving selecteren

Log in op MyKinsta, klik op WordPress sites en klik op de omgeving van waaruit je wilt pushen. Als je een Premium testomgeving hebt toegevoegd, heb je meer dan één testomgeving om uit te kiezen.

2. Omgeving pushen

Klik in de omgeving op Push omgeving en selecteer Push naar omgeving in het vervolgkeuzemenu.

3. Selecteer welke bestanden en databasetabellen je wilt pushen

Kies in de Push naar omgeving popup/modal die verschijnt uit het volgende:

• Bestanden > Alle bestanden en mappen: Hiermee worden alle bestanden en mappen naar de geselecteerde omgeving gepusht.
• Bestanden > Specifieke bestanden en mappen: Kies precies welke bestanden en mappen je naar de geselecteerde omgeving wilt pushen. Je kunt het tekstgebied gebruiken om een specifiek pad/map/bestand te definiëren om te pushen. Voor meer informatie over waar elk bestand in WordPress voor wordt gebruikt, raadpleeg je onze uitgebreide handleiding over WordPress bestanden en hoe ze te gebruiken.
• Database > Alle databasetabellen: Hiermee worden alle databasetabellen naar de geselecteerde omgeving gepusht.
• Database > Specifieke databasetabellen: Kies precies welke databasetabellen je naar de geselecteerde omgeving wilt pushen. Raadpleeg voor meer informatie over de WordPress database Een beginnershandleiding voor de WordPress database: wat het is en hoe je er toegang toe krijgt.

Voer de sitenaam in om te bevestigen en klik op Push naar omgeving.

Een paar dingen om in gedachten te houden zijn:

• De tijd die nodig is om het proces te voltooien is afhankelijk van de grootte van je website.
• MyKinsta zal je op de hoogte stellen wanneer het proces is voltooid.
• Bij het pushen van test naar live zal je website een paar seconden downtime ervaren tijdens de laatste fasen van het proces.
• Omgevingsinstellingen (redirects, geolocatie, PHP en Nginx configuratie, etc.) worden meegenomen in de push (zelfs als alleen Bestanden of Databases zijn geselecteerd) en zullen de instellingen van de omgeving volledig overschrijven.

Gebruikscases en voorbeeldworkflows

Hieronder hebben we enkele voorbeelden gegeven van wanneer je alleen bestanden, alleen de database of beide zou willen pushen.

Alleen alle bestanden en mappen pushen

• Wijzigingen die direct in themabestanden worden gemaakt (inclusief HTML, CSS of PHP) waarbij geen gegevens in de database worden opgeslagen.
• Een bestand uploaden dat niet hoeft te worden opgenomen in de WordPress Mediabibliotheek.
• Als je een custom plugin op je site hebt en wijzigingen aanbrengt in de bestanden die geen invloed hebben op de database (geen gegevens in de database opslaat of wijzigt).

Specifieke bestanden en mappen pushen

• Als je wijzigingen aanbrengt in een enkel thema, kun je de specifieke map voor het thema binnen de map themes pushen.
• Als je een nieuwe versie van een plugin test op een testsite, dan kun je de specifieke map voor de plugin in de map plugins pushen.
• Je kunt wijzigingen naar live zetten voor specifieke instellingen of configuratiebestanden door het pad/map/bestand dat je wilt pushen te definiëren in het tekstgebied.

Alleen database pushen

Opmerking: Alle wijzigingen in de database van de live site sinds de testite is gemaakt gaan verloren, inclusief maar niet beperkt tot: opmerkingen, nieuwe content, aankopen op e-commerce sites, aanmeldingen op lidmaatschapssites en forumberichten.

• Het maken of bewerken van een nieuwe post of pagina zonder geüploade media (afbeeldingen, video of andere geüploade bestanden).
• Lay-outwijzigingen aan een pagina of bericht via een builder-plugin.
• De titel of slogan van de site wijzigen.

Specifieke databasetabellen pushen

• Als je een custom WordPress plugin of thema test op een testomgeving die een specifieke databasetabel-update vereist in je live omgeving.
• Als je specifieke gegevenstabellen reorganiseert of problemen met de tabellen oplost in je testomgeving en alleen de nieuwe tabellen naar live wilt pushen.
• Als je gebruikersgerelateerde gegevens of gebruikersrollen in de testomgeving wijzigt en alleen de tabellen van de gebruikersdatabase naar live wilt zetten.

Alles pushen

Opmerking: Alle wijzigingen in de database van de live site sinds de testsite is gemaakt, gaan verloren, inclusief maar niet beperkt tot: opmerkingen, nieuwe inhoud, aankopen op e-commerce sites, aanmeldingen op lidmaatschapssites en forumberichten.

• Het creëren van nieuwe inhoud met geüploade media (afbeeldingen, video of andere geüploade bestanden).
• Wijzigingen aan je thema in zowel de Customizer als de themabestanden.
• Het installeren en testen van een nieuwe plugin of bijgewerkte versie van een plugin.

Testomgeving verwijderen en vernieuwen

Als je je testsite moet verwijderen, ga dan naar WordPress sites en selecteer de testomgeving die je wilt verwijderen. Scroll naar de onderkant van de pagina en klik op Verwijder omgeving.

Bevestig in de modal/popup die verschijnt dat je begrijpt wat er wordt verwijderd, typ de sitenaam gevolgd door een streepje en het woord “staging” (SITENAAM-omgevingsnaam) in het daarvoor bestemde veld en klik vervolgens op Omgeving verwijderen.

Om je testomgeving te vernieuwen, verwijder je deze, maak je een nieuwe aan 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 terugzetten van je productiesite naar een testomgeving. Het voordeel van deze methode is dat als je een custom domein hebt toegevoegd, het niet wordt verwijderd en je het niet elke keer hoeft toe te voegen als je je testsite vernieuwt.

Een WordPress backup terugzetten naar een testomgeving

Je kunt je WordPress site vanuit een backup direct terugzetten naar je bestaande testomgeving. Bekijk hoe je een WordPress backup herstelt naar een testomgeving. Opmerking: Alle backups van de testomgeving blijven intact wanneer je een live backup herstelt naar een testomgeving.

Testomgeving herstarten

In bepaalde situaties kunnen we een test-omgeving stoppen als onderdeel van het oplossen van serverproblemen. Als je merkt dat je testomgeving is gestopt en je een 501 not implemented, een 502 error of een 521 error ziet wanneer je je site bezoekt, kun je de testomgeving opnieuw starten in MyKinsta door naar de Info pagina van je site te gaan en te klikken op Testomgeving starten.

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

Een testomgeving verwijderen

Als je klaar bent met testen of ontwikkelen, kun je de testomgeving verwijderen. Als je een Premium testomgeving add-on gebruikt, wordt deze alleen gefactureerd voor de tijd dat deze actief is; als je de Premium testomgeving verwijdert, wordt de add-on geannuleerd en worden er geen extra facturen meer in rekening gebracht.

Klik in MyKinsta op WordPress Sites en selecteer de omgeving die je wilt verwijderen.

Scroll naar de onderkant van de pagina en klik op Omgeving verwijderen.

Bevestig in de modal/popup die verschijnt dat je begrijpt wat er wordt verwijderd, voer de sitenaam gevolgd door een streepje en de omgevingsnaam (SITENAAM-NaamOmgeving) in het daarvoor bestemde veld in en klik vervolgens op Omgeving verwijderen.

Als je een Premium testomgeving gebruikt, wordt het add-on abonnement automatisch verwijderd uit Bedrijf > Mijn pakket in MyKinsta zodra de testomgeving is verwijderd.

Belangrijke opmerkingen

Als je de testomgeving gebruikt, zijn er een aantal belangrijke dingen waar je op moet letten.

1. Pagina cache instellingen voor testsites

Omdat testomgevingen bedoeld zijn voor ontwikkelingsdoeleinden, debuggen 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 vanuit de cache worden geleverd. Als je caching wilt inschakelen op een testsite binnen de testomgeving, klik dan op Caching > Server Caching > Inschakelen. Als caching is ingeschakeld op een testsite, wordt Cache wissen ingeschakeld en kun je deze gebruiken om de cache te wissen. Als je een Premium testomgeving hebt, kun je ook CDN en edge caching inschakelen.

2. Testomgeving inloggegevens

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

3. SEO

Standaard is indexering uitgeschakeld voor testsites, zodat ze de SEO op je live/productie site niet schaden. Dit wordt gedaan door de combinatie van een WordPress instelling en een HTTP header die wij automatisch toevoegen.

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

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

4. Plugins

Als je plugins voor sociale planning gebruikt, zoals CoSchedule of Social Networks Auto Poster, is het aan te raden om deze plugins te deactiveren op je testsite. Anders zouden ze kunnen beginnen met het delen naar sociale netwerken via je testomgevings-URL, die er dan uitziet als: https://stg-sitenaam-omgevingsnaam.kinsta.cloud. Dit kan dan je statistieken verstoren.

Sommige plugins, zoals de Jetpack-plugin, draaien automatisch in testmodus op Kinsta testomgevingen. Je ziet dan een bericht: “You are running Jetpack on a staging server” In de testmodus gedraagt je testsite zich in vrijwel alle opzichten als je productiesite, behalve dat er geen gegevens worden doorgegeven aan WordPress.com en dat je de testsite niet kunt ontkoppelen (om een probleem te voorkomen dat zou leiden tot problemen met je productiesite).

Plugins die op domeinnaam zijn gelicentieerd hebben mogelijk een aangepast domein nodig (in plaats van een Kinsta test subdomein) om goed te werken. Opmerking: als je eenmaal een custom domeinnaam hebt toegevoegd aan je testsite, moet je mogelijk de instellingen bijwerken waar je de licentie van je plugin beheert of contact opnemen met het ondersteuningsteam van je plugin.

5. Noteer je login URL

Als je je site kloont naar een testomgeving en een WordPress plugin gebruikt die je standaard login URL verandert, dan wordt het aangepaste deel van de URL gekopieerd naar de testsite. Voorbeeld: http://stg-sitenaam-omgevingsnaam.kinsta.cloud/jecustomlogin

6. Testomgevingen moeten alleen worden gebruikt voor ontwikkeling/testen

De standaard testomgeving heeft slechts 2 PHP workers, heeft geen optie om Kinsta’s CDN in te schakelen en kan in slaapstand gaan na 24 uur inactiviteit. Daarom moet deze alleen worden gebruikt voor ontwikkeling en testen. Testomgevingen (Standard 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 probeert te gebruiken voor een live site.

7. Schijfruimte uitgesloten van het totale pakket

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

8. Cron jobs

Server cron jobs van de live omgeving zijn niet actief in de testomgeving (zelfs als je je live site kloont naar een testomgeving), dus de cron jobs van de live site zullen niet starten op de testomgeving. Bovendien, als je de crontab in je testomgeving aanpast en een testomgeving naar je live omgeving pusht, zal het de crontab van je live omgeving overschrijven.

9. Multisite

Als je een WordPress Multisite netwerk hebt, kan het zijn dat het wel of niet werkt met onze testomgeving, afhankelijk van hoe je Multisite is opgezet.

• Als het een subdirectory Multisite is (voorbeeld.com, voorbeeld.com/subsite1, voorbeeld.com/subsite2), dan zal het prima werken met onze testomgeving.
• Als het een subdomein Multisite is (voorbeeld.com, subsite1.voorbeeld.com, subsite2.voorbeeld.com), dan werkt het prima, mits de subsites geen HTTPS nodig hebben.
  • Als het een multisite is met subdomeinen die HTTPS vereisen, dan moet je een aangepast domein met een wildcard SSL certificaat toevoegen aan je testsite zodat de subdomeinen kunnen worden gedekt door een SSL-certificaat. Dit komt omdat het SSL-certificaat dat wordt geleverd voor de standaard testsite URL alleen het testsite subdomein kan dekken (bijv. stg-sitenaam-omgevingsnaam.kinsta.cloud), dus elk extra subdomein niveau (bijv. subsite.stg-sitename-omgevingsnaam.kinsta.cloud) kan niet worden gedekt.
• Als het een domain-mapped Multisite is (laadt verschillende subsites op compleet verschillende domeinen, bijv. voorbeeld.com, voorbeeld1.com, voorbeeld2.com), dan zal het niet werken zonder een aanzienlijke handmatige instelling.
  • Optie 1: Schakel domain mapping uit en ga terug naar de standaard subdirectory/subdomein setup. Zoek en vervang handmatig in de database.
  • Optie 2: Stel testsite subdomeinen in voor elk live domein, voeg deze allemaal toe aan de testsite en voer handmatig een zoek- en vervangactie uit in de database.

10. E-mail

Op testomgevingen is het verzenden van e-mail (transactie-e-mail) standaard ingeschakeld. Als je een bestelling doet op de testsite, ontvang je gerelateerde e-mails van de testsite. Als je niet wilt dat er transactie-e-mails worden verzonden vanaf je testomgeving, kun je een plugin zoals Disable Emails gebruiken om het verzenden van e-mails vanaf de site te stoppen.

Veelgestelde vragen

Wat is pro rata?

Wanneer we een dienst zoals de Premium testomgeving add-on pro rata berekenen, betekent dit dat je betaald wordt op basis van hoe lang de dienst in gebruik was voor die maandelijkse factureringscyclus.

Voorbeeld

Je wilt een nieuwe feature inzetten op je site en je wilt deze testen met de volledige kracht van je pakket. Je maakt een Premium testomgeving aan, voegt de nieuwe feature toe en test gedurende 1 uur. Alles ziet er goed uit, dus je zet de wijziging door naar je live omgeving en verwijdert de Premium testomgeving.

• 1 maand Premium staging-omgeving kost $20.
• Op basis van een 30-daagse maand heeft deze factureringscyclus 720 uur in totaal.
  30 * 24 = 720
• Elk uur gebruik is $0,03.
  $20 / 720 = $0.03
• Je volgende factuur bevat de $0,03 voor het 1 uur dat een Premium testomgeving aan je pakket is toegevoegd.

Voorbeeld

Je koopt een Premium testomgeving in het midden van je maandelijkse factureringscyclus en gebruikt deze tot het einde van die cyclus. Er wordt een halve maand in rekening gebracht (ongeveer $10, naar rato van de tweede maand).

Kan ik de naam van een testomgeving wijzigen?

Ja. Ga naar de omgeving die je wilt hernoemen en klik op het bewerken pictogram (potlood) in de Naam omgeving veld.

Voer de nieuwe naam in en klik op Naam omgeving wijzigen.

Dit verandert de naam van de omgeving die wordt weergegeven in de omgevingsselector, maar heeft geen invloed op het kinsta.cloud-domein dat is gegenereerd tijdens het initiële aanmaken van de omgeving.

Kan ik een backup terugzetten naar een testomgeving?

Ja, maar je moet eerst een Standaard of Premium testomgeving aanmaken. In het verleden was het mogelijk om automatisch een testomgeving aan te maken bij het terugzetten van een backup. Met de introductie van Premium testomgevingen moet je eerst de testomgeving aanmaken voordat je een backup kunt terugzetten.

Je kunt ook wijzigingen van je live site naar je testsite pushen, en als je alleen bepaalde bestanden of databasetabellen wilt bijwerken kun je een Selective Push doen.

Wie heeft toegang tot Premium testomgevingen?

Site Developers en Site Administrators hebben toegang tot Premium testomgevingen die zijn aangemaakt, maar kunnen geen Premium testomgeving aanmaken of verwijderen. Alleen een Company Owner of Company Administrator kan een Premium testomgeving aanmaken of verwijderen.

Neemt een testomgeving schijfruimte in?

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

Als ik een plugin test op de testomgeving en alleen de bestanden naar live zet, worden dan de bijbehorende database tabellen voor de plugin aangemaakt?

Als je een plugin installeert op je testsite die nog nooit is geïnstalleerd op de live site, zal het pushen van alleen de bestanden van test naar live niet de database tabellen voor die plugin aanmaken.

Dit betekent ook dat alle instellingen die je in de plugin hebt geconfigureerd niet naar live worden gepushed (tenzij de instellingen zijn opgeslagen in een bestand buiten de database, zoals bijvoorbeeld in een JSON bestand).

Afhankelijk van hoe de plugin is gecodeerd, kan het inschakelen (eerst uitschakelen indien nodig) van de plugin op de live site de database structuur creëren.

Als ik alleen de bestanden naar live zet, betekent dit dan dat de oude database (van de testomgeving) de live database niet overschrijft en dat alleen de bestanden worden overschreven?

Ja, als je alleen de bestanden pusht, betekent dit dat de database op de live site ongewijzigd blijft en dat alleen de bestanden op de live site worden overschreven.

Betekent dit dat ik kan werken aan ontwerpwijzigingen op mijn testsite en deze kan pushen naar live zonder nieuwe abonnees of klanten op mijn live site te verliezen?

Ja, zolang je wijzigingen alleen in bestanden zijn aangebracht (geen wijzigingen in het WordPress dashboard – inclusief plugin, thema of customizer instellingen), kun je deze veilig naar live zetten zonder de database te pushen. Wanneer je de wijzigingen naar live zet, selecteer dan Bestanden en zorg ervoor dat Database niet geselecteerd is.

Kan ik WooCommerce bestellingen of gegevens uitsluiten of synchroniseren bij het pushen van test naar live?

Ja, wanneer je test naar live pusht met een Selective Push, kun je alleen bestanden pushen zodat je database niet wordt overschreven, of je kunt selectief databasetabellen pushen en de benodigde WooCommerce tabellen uitsluiten. Raadpleeg de WooCommerce Database Decription voor informatie over wat er in elke WooCommerce databasetabel staat. Als je niet zeker weet welke tabellen je moet pushen, raden we je aan om samen te werken met een ontwikkelaar.

Kan ik maar één site van test naar live zetten als ik een Multisite heb?

Ja, als je test naar live zet met een Selective Push, kun je ervoor kiezen om alleen de databasetabellen voor een van de subsites te pushen. Als je wilt weten welke databasetabellen in WordPress zijn opgenomen, raadpleeg dan A Beginner’s Guide to WordPress Database: Wat het is en hoe het te openen. In de bestanden worden de mappen met plugins en thema’s gedeeld door alle sites, maar de map met uploads kan worden gescheiden per site; daarom kun je ervoor kiezen om alleen de uploads voor de gewenste subsite te pushen. Als je niet zeker weet welke tabellen of bestanden je moet pushen, raden we je aan om samen te werken met een ontwikkelaar.

Kan ik Selective Push gebruiken om de PHP versie van mijn site te veranderen?

Ja, je kunt testsite gebruiken om te testen en een nieuwe PHP versie naar je live omgeving te pushen, maar het is niet strikt noodzakelijk om van test naar live te pushen om je PHP versie bij te werken. Hier is een kort overzicht van hoe je de PHP versie kunt wijzigen zonder van test naar live te pushen:

1. Maak een testsite aan.
2. Ga naar de testsite en verander de PHP versie op de testsite.
3. Als alles in orde is en werkt zoals verwacht op de testsite (zorg ervoor dat je je site grondig test), verander dan de PHP-versie op de live site.

Ik heb CSS wijzigingen aangebracht in het WordPress dashboard en bestanden gepushed. Waarom zie ik mijn wijzigingen niet, zelfs niet nadat ik alle cache heb gewist?

Afhankelijk van het type wijziging en waar die informatie is opgeslagen, moet je misschien de database pushen of die wijzigingen handmatig op de live site doorvoeren. Als je bijvoorbeeld CSS hebt toegevoegd of bewerkt in een blok of widget in het WordPress dashboard, dan wordt dat waarschijnlijk opgeslagen in de database.

Als je wijzigingen aanbrengt in iets in het WordPress dashboard, met uitzondering van wijzigingen die je aanbrengt met de Thema-editor (Appearance > Thema-editor), dan wordt die informatie meestal opgeslagen in de database.

Opmerking: Alle wijzigingen in de database van de live site sinds het maken van de testsite gaan verloren, inclusief maar niet beperkt tot: opmerkingen, nieuwe inhoud, aankopen op e-commerce sites, aanmeldingen op lidmaatschapssites en forumberichten. In dit geval raden we aan om dezelfde wijzigingen handmatig op de live site door te voeren in plaats van de database te pushen.

Hoe werkt Selective Push met een Multisite netwerk?

Als je Selective Push gebruikt om alleen de bestanden te pushen, werkt het prima, ongeacht het type Multisite netwerk. Als je alleen de database of de database en bestanden pusht, kan het wel of niet werken, afhankelijk van hoe je Multisite is opgezet:

• Als het een subdirectory Multisite is (voorbeeld.com, voorbeeld.com/subsite1, voorbeeld.com/subsite2), dan zal push to live werken zoals verwacht.
• Als het een subdomein Multisite is (voorbeeld.com, subsite1.voorbeeld.com, subsite2.voorbeeld.com), dan werkt het prima, mits de subsites geen HTTPS nodig hebben.
• Als het een domain-mapped Multisite is (laadt verschillende subsites op totaal verschillende domeinen, bijvoorbeeld voorbeeld.com, voorbeeld1.com, voorbeeld2.com), dan zal het niet werken zonder een aanzienlijke handmatige configuratie.
  • Optie 1: Schakel domain mapping uit en ga terug naar de standaard subdirectory/subdomein setup. Zoek en vervang handmatig in de database.
  • Optie 2: Stel testsubdomeinen in voor elk live domein, voeg deze allemaal toe aan de testsite en voer handmatig een zoek- en vervangactie uit in de database om elk domein bij te werken na het pushen van testnaar live.