WordPress staging-omgeving: hoe je er een maakt en veilig gebruikt

Een complete, neutrale gids voor het opzetten van een WordPress staging-omgeving: managed host, WP STAGING plugin, handmatige kloon en lokale tools, plus de valkuilen rond staging afschermen van Google, synchroon houden met productie en veilig terugpushen zonder live bestellingen te wissen.

Updates rechtstreeks op productie deployen is de goedkoopste manier om een WordPress-site te slopen. Een plugin-update botst met het theme, een security-patch reageert raar met een page builder, een PHP-upgrade duwt een deprecated functie van het dak, en plotseling zie je een wit scherm of, nog erger, een half kapotte checkout die tóch nog bestellingen aanneemt. Een staging-omgeving is de goedkope verzekering daartegen. Dit artikel behandelt vier manieren om er eentje op te tuigen: via de ingebouwde staging van je managed host, via de WP STAGING plugin, via een handmatige kloon op een subdomein, en via een lokale development-tool. Elke methode heeft andere trade-offs en, belangrijker, andere antwoorden op het lastigste deel van staging: je wijzigingen weer terugzetten op productie zonder live data kapot te trekken.

De scope is bewust beperkt. Dit is een how-to, geen conceptueel essay over deployment-pipelines. Wil je de achtergrond bij wp-config.php-constants of de mechanica van de WordPress URL search-replace, dan staan die in aparte artikelen waar ik ze inline naar link.

Wat een staging-omgeving doet, en waarom je er een nodig hebt

Een WordPress staging-omgeving is een complete kopie van je productiesite die op een aparte URL draait, een eigen database heeft en niet toegankelijk is voor zoekmachines. Hij bestaat zodat je drie dingen kunt doen die op productie onveilig zijn: plugin- en theme-updates testen voor je ze toepast, configuratie- of content-wijzigingen uitproberen voor je je eraan committeert, en problemen debuggen die alleen met echte data verschijnen. De WordPress handbook-pagina over environment types introduceerde in WordPress 5.5 een WP_ENVIRONMENT_TYPE-constante, precies zodat plugins en themes kunnen detecteren dat ze op staging draaien en dingen die daar nooit mogen gebeuren (analytics, payment capture, transactionele e-mail, cache busting) kunnen uitzetten.

Staging is niet hetzelfde als een backup. Een backup is een momentopname die je terugzet nadat er iets kapot is gegaan. Staging is een actieve omgeving die je gebruikt om te voorkomen dat het überhaupt kapot gaat. Je hebt allebei nodig.

Staging is ook niet hetzelfde als een lokale development-omgeving. Een lokale omgeving is waar je code bouwt. Een staging-omgeving bootst productie genoeg na (server, PHP-versie, caching, CDN, database-engine, hoeveelheid data) om betrouwbaar voorspellingen te doen over hoe iets zich op productie gaat gedragen. Dat onderscheid doet ertoe, want lokale tools zoals LocalWP en DevKinsta zijn top voor development, maar ze bootsen de productie-caching, load balancers, object cache en CDN-edge niet na. Voor verificatie vlak voor een deploy wil je staging meestal op dezelfde infrastructuur als productie.

Wat je van tevoren nodig hebt

Een productiesite waar je controle over hebt. Je hebt hostingpaneel-toegang, FTP/SSH-toegang of WordPress-admintoegang nodig, afhankelijk van welke methode je kiest.
Een recente backup van productie. Elke methode hieronder kopieert de database, en elke kloon is veiliger met een verse backup ernaast. Maak een database- en filesbackup vlak voor je begint, ongeacht de geplande backups.
Een aparte URL voor staging. Een subdomein (staging.voorbeeld.nl), een apart domein (voorbeeld-staging.nl), of een staging-URL die je host uitdeelt. Staging in een subfolder van je productiedomein draaien kan wel met WP STAGING Free, maar brengt eigen URL- en redirect-eigenaardigheden mee.
De mogelijkheid om wp-config.php te bewerken. Minimaal voor het zetten van WP_HOME, WP_SITEURL en WP_ENVIRONMENT_TYPE op de staging-kopie.
De mogelijkheid om je webserver-configuratie te bewerken (.htaccess bij Apache, het server block bij nginx), of een hostingpaneel waarin je HTTP basic auth op een subdomein kunt aanzetten. Dit is niet optioneel voor de indexing-preventiestap verderop.
WP-CLI-toegang (optioneel maar aan te raden). WP-CLI maakt de search-replace-stap een stuk veiliger. Zie de aparte WordPress search-replace-gids voor het waarom.

Methode 1: staging via het hostingpaneel van je managed host

Als je host een ingebouwde stagingfunctie heeft, gebruik die dan. Het is bijna altijd de snelste, betrouwbaarste en minst foutgevoelige optie, want de host regelt het subdomein, het SSL-certificaat, de bestandskopie, de database-kloon, de search-replace en de noindex-stap in één klik voor je.

Wie staging standaard meelevert:

WP Engine levert op alle plannen development-, staging- en productie-omgevingen. Je maakt met één klik een staging-kopie van productie, pusht bestanden of database terug, en wisselt omgevingen. De WP Engine staging-documentatie loopt de hele workflow door.
Kinsta levert staging op alle plannen via MyKinsta, met een selective push-functie waarmee je bestanden en database los van elkaar naar live kunt pushen. Dat is de veiligste aanpak als maar een deel van staging vooruit hoeft.
Pressable levert staging op alle plannen. De interessante differentiator zit in twee push-modes: een data-sync-push voor selectieve wijzigingen en een domain-swap-flip voor complete overhauls.
SiteGround, Bluehost en Flywheel leveren ook one-click staging op de meeste van hun plannen.

Zo gebruik je het veilig:

Maak in het hostingpaneel een staging-kopie van productie. De host kloont bestanden en database naar de staging-omgeving en draait de URL-replace zodat het staging-domein klopt.
Controleer dat de staging-site laadt op de staging-URL en dat de WordPress-admin bereikbaar is.
Kijk of de host noindex-bescherming heeft toegevoegd (basic auth, X-Robots-Tag of een eigen gate). Zo niet, regel je dat zelf via de sectie staging afschermen van zoekmachines hieronder.
Zet WP_ENVIRONMENT_TYPE op staging in de wp-config.php van de staging-kopie zodat plugins weten waar ze draaien. Sommige hosts doen dit automatisch.
Doe je testwerk op staging.
Als je klaar bent om je wijzigingen terug te zetten, gebruik dan de push-tool van de host. Voor een WooCommerce-winkel altijd een selective push (alleen bestanden, of bestanden plus een specifieke subset tabellen), nooit een volledige database-overwrite. Meer daarover in de sectie wat je niet moet terugkopieren.

De belangrijkste beperking is vendor lock-in. Stap je weg bij de host, dan gaat de staging-functie mee. Maar voor een managed WordPress-klant is dit gewoon de schoonste setup die er is.

Methode 2: de WP STAGING plugin

WP STAGING is de meest gebruikte staging-plugin voor WordPress. Hij kloont de site in een aparte kopie die op dezelfde server leeft, meestal onder een subfolder-URL zoals jouwsite.nl/staging-abc123. De kloon draait op eigen database-tabellen (met een andere prefix) en is op databaseniveau geisoleerd van productie.

Het belangrijkste onderscheid: WP STAGING Free kloont naar staging maar kan wijzigingen niet terugpushen van staging naar productie. Dat is een Pro-only-functie. Dit overvalt veel mensen. De documentatie op wp-staging.com is er duidelijk over, maar het besef valt meestal pas nadat je al een staging-workflow rondom de gratis versie hebt gebouwd. Was je plan "de update testen op staging en dan naar live promoten", dan stopt de gratis versie je bij stap twee, en sta je weer handmatig de wijziging op productie toe te passen.

Wat Free je wel geeft:

Een one-click kloon naar een aparte subfolder-URL met eigen database-tabellen.
Selectieve uitsluiting van grote mappen (zoals wp-content/uploads) tijdens het klonen.
Automatische noindex op de staging-kloon.
Correcte afhandeling van de URL-replace binnen serialised WordPress-data tijdens het klonen.

Wat Pro daar bovenop legt:

Push van staging naar productie, met selective sync van specifieke tabellen en bestanden.
Subdomein- en apart-domein-staging in plaats van alleen de subfolder-modus van Free.
Multisite-ondersteuning.
WooCommerce-specifieke tabel-uitsluiting bij push (zodat je geen live orders overschrijft).
Geplande backups.

Zo gebruik je WP STAGING goed:

Installeer WP STAGING vanuit de WordPress plugin-directory op de productiesite.
Ga in wp-admin naar WP STAGING Jobs en klik op "Create new staging site". Geef hem een naam.
Op het scope-scherm sluit je wp-content/uploads uit als je uploads-map groot is en je geen volledige mediabibliotheek nodig hebt op staging. Doe hetzelfde voor andere grote mappen. Dat versnelt de kloon aanzienlijk.
Op het database-tabellen-scherm laat je standaard alle tabellen aanstaan, tenzij er een specifieke reden is om er een over te slaan.
Start de kloon en wacht tot hij klaar is.
Bezoek de staging-URL (WP STAGING laat die zien aan het eind van de kloonjob). Log in met dezelfde credentials als op productie.
Controleer dat de noindex-header aanwezig is: kijk in de browser-devtools onder Network naar een staging-response en zoek naar X-Robots-Tag: noindex, nofollow of naar de noindex-meta-tag. WP STAGING zet de meta-tag automatisch.
Leg een extra laag bescherming boven de default noindex van WP STAGING. De meta-tag alleen is niet genoeg (het waarom staat in de sectie hieronder). Zet op z'n minst HTTP basic auth op de staging-subfolder via .htaccess.
Doe je testwerk op staging.
Heb je WP STAGING Pro, gebruik dan Push Changes met selective sync om specifieke tabellen en bestanden terug te pushen naar productie. Zit je op Free, dan moet je de wijzigingen handmatig opnieuw toepassen op productie.

Methode 3: handmatige kloon op een subdomein

De handmatige methode geeft je de meeste controle en werkt op elke host, maar heeft de meeste stappen en de meeste dingen die fout kunnen gaan. Gebruik dit als je host geen staging heeft, je geen staging-plugin wilt, en je prettig werkt met WP-CLI of phpMyAdmin.

Het globale plaatje: bestanden kopieren, database kopieren, een subdomein opzetten, wp-config.php bijwerken, een URL search-replace draaien, noindex en basic auth erop, klaar.

Stap voor stap (subdomein-staging op dezelfde server):

Maak een subdomein. In je hostingpaneel (cPanel, Plesk of gelijkwaardig) maak je staging.voorbeeld.nl aan en wijs je het document root toe aan een nieuwe map, bijvoorbeeld /home/voorbeeld/staging.voorbeeld.nl/.
Regel een SSL-certificaat voor het subdomein. De meeste hosts geven automatisch een gratis Let's Encrypt-certificaat uit als je een subdomein aanmaakt. Controleer dat het actief is voor je verder gaat. Basic-auth credentials mogen nooit over plain HTTP reizen, daarom komt SSL voor de kloon.

Kopieer de bestanden. Vanaf het productie-document-root:

cd /home/voorbeeld/public_html/
rsync -av ./ /home/voorbeeld/staging.voorbeeld.nl/

Maak een nieuwe database voor staging. In cPanel of rechtstreeks in MySQL:

CREATE DATABASE voorbeeld_staging;
CREATE USER 'voorbeeld_staging'@'localhost' IDENTIFIED BY 'sterk-wachtwoord';
GRANT ALL PRIVILEGES ON voorbeeld_staging.* TO 'voorbeeld_staging'@'localhost';
FLUSH PRIVILEGES;

Dump en importeer de database.

cd /home/voorbeeld/public_html/
wp db export /tmp/productie.sql
cd /home/voorbeeld/staging.voorbeeld.nl/
mysql -u voorbeeld_staging -p voorbeeld_staging < /tmp/productie.sql

Werk de staging-wp-config.php bij. Zet de database-constants naar de staging-database, en voeg de environment- en URL-constants toe. Die overrulen de waarden die nog in de database staan:

// In /home/voorbeeld/staging.voorbeeld.nl/wp-config.php
define( 'DB_NAME',     'voorbeeld_staging' );
define( 'DB_USER',     'voorbeeld_staging' );
define( 'DB_PASSWORD', 'sterk-wachtwoord' );
define( 'DB_HOST',     'localhost' );

define( 'WP_HOME',             'https://staging.voorbeeld.nl' );
define( 'WP_SITEURL',          'https://staging.voorbeeld.nl' );
define( 'WP_ENVIRONMENT_TYPE', 'staging' );
define( 'WP_DEBUG',            true );
define( 'WP_DEBUG_LOG',        true );
define( 'WP_DEBUG_DISPLAY',    false );

Belangrijke nuance uit de WordPress handbook: WP_HOME en WP_SITEURL in wp-config.php overrulen de waarden in wp_options tijdens runtime, maar ze herschrijven niets in de database zelf. De staging-database bevat nog steeds de productie-URL op tientallen plekken: in post content, menu's, widgets, serialised plugin-opties. Dat is wat de volgende stap aanpakt.

Draai de URL search-replace op de staging-database. Dit is de stap waar mensen onderuit gaan. Een rauwe SQL UPDATE sloopt serialised WordPress-data. Gebruik WP-CLI:
```
cd /home/voorbeeld/staging.voorbeeld.nl/
# Altijd eerst een dry-run
wp search-replace 'https://voorbeeld.nl' 'https://staging.voorbeeld.nl' \
  --all-tables --precise --skip-columns=guid --dry-run
# Als de dry-run-output klopt, draai je hem echt
wp search-replace 'https://voorbeeld.nl' 'https://staging.voorbeeld.nl' \
  --all-tables --precise --skip-columns=guid
```
De --precise-vlag forceert PHP-based processing, zodat serialised data correct wordt afgehandeld. --skip-columns=guid is hierin bepalend: de officiele WP-CLI search-replace-documentatie legt uit dat GUIDs permanente post-identifiers zijn die door feedreaders worden gebruikt, en dat hen herschrijven duplicate-content waarschuwingen oplevert. De mechanica van deze stap en de Gutenberg JSON-escaped URL-val die soms een tweede pass vraagt, staan volledig in de WordPress search-replace-gids.
Laad https://staging.voorbeeld.nl/ en verifieer dat de site rendert, dat interne links naar staging.voorbeeld.nl wijzen, en dat wp-admin bereikbaar is.
Zet noindex en basic auth op via de aparte sectie hieronder. Niet overslaan.

Verwachte output na stap 7 (geslaagde dry-run):

Success: 742 replacements to be made.

Verwachte output na stap 8 (staging openen):

De site laadt op https://staging.voorbeeld.nl/, iedere interne link in de header naar staging.voorbeeld.nl wijst, en je browser redirect niet terug naar voorbeeld.nl. Als dat wel gebeurt, staat WP_HOME of WP_SITEURL niet goed, of heeft de URL-replace een tabel gemist.

Methode 4: lokale development-tools als staging-vervanger

Lokale tools als LocalWP, DevKinsta, Lando en kale Docker Compose zetten een WordPress-omgeving op je laptop neer. Voor code schrijven en dingen uitproberen zijn ze uitstekend, maar ze zijn geen directe vervanger voor staging op dezelfde infrastructuur als productie. De productieserver draait een specifieke PHP-versie, een specifieke database-engine, een specifieke object cache (of geen), en meestal een CDN en full-page cache ervoor. Een lokale tool reproduceert WordPress, niet de productie-edge.

Gebruik een lokale tool als:

Je code schrijft (custom plugin, theme-aanpassing, block templates) en een snelle lokale edit-reload-loop wilt.
Je een plugin-configuratie wilt uitproberen zonder je ergens aan te committeren.
Je een probleem debugt dat lokaal reproduceerbaar is.

Gebruik een lokale tool niet als:

Je de finale check voor een deploy doet op een plugin-update die mogelijk met je caching-laag botst.
Je performance of caching-gedrag wilt testen.
Je een CDN- of edge-specifieke configuratie wilt valideren.

De tools:

LocalWP (vroeger Local by Flywheel) is de makkelijkste instap. Gratis, cross-platform, GUI-gedreven, met ingebouwde SSL, MailHog voor het vangen van uitgaande e-mail en one-click Live Link-sharing. Hij integreert met Flywheel en WP Engine voor push/pull, waardoor het een development-naar-staging-naar-productie-pipeline wordt als je daar gehost bent.
DevKinsta is het equivalent van Kinsta, Docker-based, met one-click push/pull naar Kinsta staging en productie. Handig als je bij Kinsta zit, minder zinvol als dat niet zo is.
Lando is een open-source Docker Compose-wrapper die niet WordPress-specifiek is. Hij ondersteunt WordPress, Drupal, Laravel en meer via YAML-recipes. Er zit een steilere leercurve op, maar je hebt wel meer controle en met een checked-in .lando.yml is hij prettig voor teams.
Docker Compose zonder wrapper geeft maximale flexibiliteit. Je schrijft je eigen docker-compose.yml, regelt je eigen volumes en networking, en krijgt precies de omgeving die je definieert. Dat is de juiste keuze voor DevOps-engineers die staging als infrastructure-as-code willen.

Een realistische workflow combineert een lokale tool met een echte staging-omgeving: code lokaal bouwen, dan naar staging op de productie-infra pushen, daar verifieren en dan promoten naar productie. De lokale tool en de staging-omgeving hebben verschillende taken en beide verdienen een plek.

Staging verbergen: noindex, X-Robots-Tag en basic auth

De grootste fout die mensen met staging maken, is leunen op één laag bescherming. De WordPress-reading-instelling "Ontmoedig zoekmachines deze site te indexeren" is een goede start, maar op zichzelf niet genoeg. Hier is waarom elke losse laag tekortschiet en waarom je ze wil stapelen.

Laag 1: de WordPress reading-instelling. Instellingen, Lezen, "Ontmoedig zoekmachines deze site te indexeren". Dit voegt <meta name="robots" content="noindex,nofollow"> toe aan elke pagina. Google respecteert het wel, maar third-party crawlers en scrapers doen dat niet. Nog erger: de crawler moet de pagina sowieso ophalen om de meta-tag te lezen, wat betekent dat je staging-inhoud al in het geheugen van elke crawler zit die langs is geweest.

Laag 2: robots.txt. Disallow: / voor alle user agents. Het addertje is dat robots.txt adviserend is, en let op: als een staging-URL al eens gevonden en geindexeerd is, haal je die met een robots.txt disallow niet meer uit de index weg. Voor verwijdering uit de index heb je een noindex-directive nodig, en robots.txt is dat niet.

Laag 3: X-Robots-Tag HTTP-header. Dit is de noindex-directive op server-niveau. Hij wordt als HTTP-response-header meegestuurd voordat er ook maar een byte content wordt gelezen, werkt op elk filetype (ook PDF's en afbeeldingen), en kan niet per ongeluk door een theme- of plugin-update verwijderd worden. Yoasts uitleg over X-Robots-Tag loopt de mechanica in detail door.

Als de stagingfunctie van je host dit automatisch regelt (Kinsta, WP Engine en Pressable doen dat allemaal), controleer dan dat het aanwezig is maar voeg het niet handmatig toe. Moet je het zelf instellen, open dan het .htaccess-bestand van de staging-site via de bestandsbeheerder van je hostingpaneel (of via SFTP) en voeg onderstaande regel toe.

Voor Apache (.htaccess):

Header set X-Robots-Tag "noindex, nofollow"

Voor nginx (vereist toegang tot de server-block-config, meestal via SSH):

add_header X-Robots-Tag "noindex, nofollow";

Laag 4: HTTP basic auth. Dit is de enige laag die daadwerkelijk voorkomt dat crawlers en niet-ingelogde mensen überhaupt bij content kunnen. Zoekmachine-crawlers kunnen niet authenticeren, dus ze worden al aan de voordeur gestopt en krijgen de pagina nooit te zien. Dat is waarom basic auth het minimale niveau is voor een staging-site die echte klantdata bevat.

De meeste managed hosts hebben een toggle "Beveilig dit subdomein met een wachtwoord" of "Directory Privacy" in het hostingpaneel (cPanel, Plesk en DirectAdmin hebben er allemaal een). Dat is onder de motorkap gewoon basic auth. Gebruik die als de optie er is; het is de snelste en minst foutgevoelige route.

Heb je SSH-toegang en wil je het handmatig instellen, of heeft je host geen paneel-toggle:

Voor Apache maak je een .htpasswd-bestand buiten het document root en voeg je dit toe aan de staging-.htaccess:

AuthType Basic
AuthName "Staging - alleen voor toegestane gebruikers"
AuthUserFile /home/voorbeeld/.htpasswd
Require valid-user

Het .htpasswd-bestand maak je met:

htpasswd -c /home/voorbeeld/.htpasswd staging

Voor nginx zet je basic auth aan in het server-block:

location / {
    auth_basic "Staging - alleen voor toegestane gebruikers";
    auth_basic_user_file /home/voorbeeld/.htpasswd;
    try_files $uri $uri/ /index.php?$args;
}

De regel: X-Robots-Tag plus basic auth is het minimum. De WordPress reading-instelling is een nice-to-have, maar op zichzelf geen bescherming. Basic auth op een niet-HTTPS staging-site stuurt credentials in het klare, dus zorg dat SSL actief is voor je hem aanzet.

Staging synchroon houden met productie

Een staging-site die drie maanden geleden gekloond is, is geen bruikbare staging-site. Plugins zijn verder, content is gewijzigd, en de productie-database is gedriftet. Je hebt drie opties om staging redelijk vers te houden.

Optie A: vers klonen wanneer je het nodig hebt. Verwijder de huidige staging-site, maak een nieuwe kloon van productie, doe je tests, weg ermee. Dit is de simpelste workflow en werkt goed voor incidenteel testen (kwartaal-plugin-updates, sporadische theme-wijzigingen). De kloonstap is wat de methodesecties hierboven behandelen.

Optie B: refresh op schema. Sommige managed hosts laten je wekelijks of maandelijks een refresh van productie naar staging plannen. Dat houdt staging recent, maar ieder werk-in-uitvoering dat op staging staat, wordt overschreven als de refresh draait. Gebruik dit alleen als je niets langdurigs op staging laat staan.

Optie C: handmatige selectieve refresh. Trek periodiek alleen de productie-database in staging en laat de staging-bestanden met rust. Handig als je een code-wijziging test die recente productie-data nodig heeft. WP STAGING Pro ondersteunt dit, en op managed hosts zit meestal een equivalente optie in het staging-paneel.

Optie A is de veiligste default. Optie B is prima voor sites waar staging een wegwerp-testbank is en er niets langdurig op leeft. Optie C is voor teams die actief tegen realistische data ontwikkelen.

Wijzigingen veilig terugpushen van staging naar productie

Dit is het deel waar sites sneuvelen. Een geslaagde test op staging is niet een one-click promote naar live. Het mentale model uit de Pantheon-gids over staging-to-production is het juiste: code gaat vooruit, data blijft op productie. Push themes, plugins en custom code. Push de live database niet over productie heen.

De veilige workflow:

Maak een backup van productie (bestanden en database) vlak voor de push. On-demand, niet de geplande backup van gisteren. Dit is je undo-knop.
Push alleen bestanden van staging naar productie. Dat dekt theme-updates, plugin-updates, custom-code-wijzigingen, nieuwe uploads-mappen en alles wat in bestanden leeft (zoals een bijgewerkte robots.txt of .htaccess).
Moet je toch database-wijzigingen meenemen (nieuwe ACF-velddefinities, nieuwe rijen in plugin-instellingen, een menu-wijziging), synchroniseer dan alleen de specifieke tabellen die gewijzigd zijn, nooit de volledige database. Voor WordPress komt dat meestal neer op een subset van wp_options en wp_postmeta, niet de hele dump.
Draai nooit een volledige database dump-restore van staging over productie. Zo verwijder je elke order, reactie, gebruikersaccount, formulier-inzending en membership-activiteit die tussen de kloon en de push heeft plaatsgevonden. Zonder backup is dat niet terug te halen.
Verifieer na de push de kritieke user flows op productie. Log in, plaats een test-order, dien een contactformulier in, controleer of geplande posts nog draaien. De Pantheon-gids noemt checkout, login en donation-flows expliciet als het minimum voor verificatie.

Managed hosts als Kinsta en WP Engine hebben dit model geimplementeerd in hun selective push-tools. WP STAGING Pro doet het via zijn selective-sync-functie. Heeft jouw setup geen selective push-tool, dan is de veilige aanpak: bestanden pushen via rsync of git, en database-wijzigingen handmatig opnieuw toepassen op productie via wp-admin (de plugin-instelling opnieuw invoeren, het menu opnieuw bouwen) in plaats van database-rijen over te kopieren.

Wat je niet moet terugkopieren: bestellingen, gebruikers, live formulierdata

De tabellen en data die op productie moeten blijven staan, ongeacht de methode, zijn de dingen die tussen de kloon en de push zijn aangekomen. Een niet-uitputtende lijst:

WooCommerce-bestellingen en klantdata. Met High-Performance Order Storage (HPOS) aan leven orders in wc_orders, wc_order_addresses, wc_order_items, wc_order_operational_data en gerelateerde tabellen. Voor HPOS leefden orders binnen wp_posts en wp_postmeta met een shop_order post type. Hoe dan ook: deze tabellen bevatten transacties die na je staging-kloon zijn gebeurd en mag je niet overschrijven. WP STAGING Pro sluit WooCommerce-ordertabellen om deze reden standaard uit bij een push.
Reacties. wp_comments en wp_commentmeta groeien tussen kloon en push.
Gebruikers die na de kloon zijn aangemaakt. wp_users en wp_usermeta. Die overschrijven verwijdert iedereen die zich na de kloondatum heeft ingeschreven.
Formulier-inzendingen. Plugins als Gravity Forms, Contact Form 7 Database, WPForms en Ninja Forms slaan inzendingen op in eigen tabellen (wp_gf_entry, wp_wpforms enzovoort). Die worden in een volledige database-push stilletjes overschreven.
Membership- of abonnementsstatus. MemberPress, Paid Memberships Pro, Restrict Content Pro bewaren per-gebruiker abonnementsstatus in custom tabellen die niet mee terug horen naar productie.
Payment-gateway-webhook-state. Stripe, PayPal, Mollie en andere gateways sturen webhooks naar productie-URL's. Staging hoort geen productie-webhooks te ontvangen, en de webhook-configuratie op productie moet je bij een push onberoerd laten.
Uploads die na de kloon op productie zijn toegevoegd. De wp-content/uploads/JJJJ/MM/-mappen waarin JJJJ/MM na de kloondatum ligt. Een file-push moet die uitsluiten, anders verwijder je uploads die productie-gebruikers sindsdien hebben toegevoegd.

De regel: heb je het niet in staging gewijzigd, push het dan ook niet vanaf staging. De veiligste push is de kleinste push. Eén bestand pushen is veiliger dan een directory; een directory is veiliger dan de hele site; bestanden pushen is veiliger dan de database; een subset tabellen pushen is veiliger dan de hele database.

Wil je een sterker vangnet rond deze hele workflow, dan behandelt de WordPress backup-strategie-gids de rotatie- en retentiepatronen waarmee je kunt herstellen als er toch iets doorheen glipt, en de WordPress-beveiliging-verhardingsgids de DISALLOW_FILE_EDIT en file-permission-defaults die staging en productie allebei moeilijker kapot te maken maken.

WordPress onderhoud zonder omkijken?

Ik regel updates, backups en beveiliging, en houd performance strak—zodat storingen en traagheid niet terugkomen.

Bekijk WordPress onderhoud