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 threads | Hetzelfde als je live omgeving | 2 |
| PHP geheugenlimiet | Hetzelfde als je live omgeving | Hetzelfde als je live omgeving |
| PHP geheugen per thread | Hetzelfde als je live omgeving | Het maximale aantal threads in een standaard staging-omgeving is 2 en het geheugen per thread is hetzelfde als in de live-omgeving. Als de live-omgeving bijvoorbeeld een geheugenpool van 2 GB heeft met 4 PHP-threads, heeft elke thread een geheugenlimiet van 512 MB. In de standaard testomgeving zijn dit 2 PHP-threads, elk met een geheugenlimiet van 512 MB. Dit geldt alleen voor pakketten die toegang hebben tot de PHP Performance add-on. |
| 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 makkelijk mogelijk gemaakt. Klik in MyKinsta op WordPress sites in het navigatiemenu aan de linkerkant. Je ziet dan een lijst met je sites/installaties. Kies de site waarvoor je een testomgeving wilt maken, klik op het omgevingstype, bijvoorbeeld Live, en selecteer Nieuwe omgeving maken. Je kunt ook op het zoekvak Springen naar of Zoeken klikken en Nieuwe omgeving maken selecteren.
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.
- Een bestaande omgeving klonen: Met deze optie kun je een bestaande omgeving (live of een Premium testomgeving) klonen naar de nieuwe testomgeving.
- Installeer nieuwe WordPress: Deze optie installeert een volledig functionele lege WordPress site, klaar om direct te gebruiken.
- 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 deze klaar is, klik je binnen de site op het omgevingstype, bijvoorbeeld Live, en selecteer je de staging-omgeving. Je kunt ook op het vakje Springen naar of zoeken klikken om de omgeving te selecteren.
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 pushen
Wanneer je klaar bent om je testomgeving naar live te pushen, volg je de stappen in Omgevingen pushen. Je kunt bovendien elke live- of testomgeving naar een andere site pushen.
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.
Als je de Premium testomgeving add-on verwijdert en je zit nog in de eerste 30 dagen van je WordPress Hosting-pakket, wordt er een evenredig deel van de kosten voor de add-on toegevoegd aan je volgende factuur voor de periode dat deze was ingeschakeld. Als je WordPress Hosting-pakket al langer dan 30 dagen actief is, krijg je een evenredig deel van de kosten voor de add-on teruggestort op je accountsaldo voor de resterende dagen van de huidige factureringsperiode. Het tegoed wordt automatisch gebruikt om het aan Kinsta verschuldigde bedrag op je volgende factuur te verrekenen. Raadpleeg voor meer informatie onze WordPress Hosting niet-goed-geld-terug-garantie.
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) of een subdomein Multisite (voorbeeld.com, subsite1.voorbeeld.com, subsite2.voorbeeld.com) werkt het prima met onze testomgeving. Alle subdomeinen vallen onder het gratis SSL-certificaat van Kinsta.
- 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 de Info pagina op het bewerkingspictogram (potlood) in het veld Omgevingsnaam.
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:
- Maak een testsite aan.
- Ga naar de testsite en verander de PHP versie op de testsite.
- 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.