Best practice differences in DB options and wp-config between live, staging and local WordPress environments?

I've been using staging sites for years. So I'm not asking about the necessary difference to setup a working staging site such as search replacing URLs, dev version control branches, changing table prefixes etc.

I'm asking for differences which improve security, workflow or quality of life. Differences in options or wp-config.php established upon initial environment creation or when transferring between different environments. Here's some examples I currently establish:

  • blog_public db option - Allow search engine crawlers in live, block search engine crawlers in staging.
  • LiteSpeed Cache plugin (or equivalent) - Activate cache in live, deactivate cache in staging.
  • JETPACK_DEV_DEBUG - Set to false in live, set true in staging.
  • WP_DEBUG in wp-config.php - Set to false in live, set true in staging (Actually I don't do this as my staging sites are publicly accessible but it's a plausible example)
  • DISALLOW_FILE_MODS in wp-config.php - Set to true in live, set false in staging.
  • AUTOMATIC_UPDATER_DISABLED - Set to true in live, set false in staging.

Things I intend to setup but haven't yet:

  • WooCommerce payment gateways - Enable test mode in staging, disable in live.
  • WooCommerce test store message - Activate WooCommerce store notice on staging, deactivate on live.

Got any more? Along with core I'm looking for differences that oil the gears of popular plugins such as WooCommerce, Wordfence, Yoast SEO, Jetpack etc.

I tried to research this topic but the search results are drowned out by the plethora of boilerplate staging site setup tutorials. I tried posting on Reddit but that was also drowned out by subsequent posts. So keen to hear your ideas!

Topic development-strategy wp-config options staging Wordpress

Category Web

1
answered at

A few I disable or change on staging and dev WP sites:

  • Redis caching
  • CDN
  • WooCommerce order notification emails - changing from whoever fulfills them on prod to dev team.
1
answered at

Seems like a good list you have going... Just a few that come to mind:

  • SCRIPT_DEBUG to false on live and true on staging.
  • WP_CACHE to true on live and false on staging.
  • ping_sites to empty on staging to disable ping services.
  • default_pingback_flag to 0 on staging to not send outgoing pingbacks.
  • Maybe install a Password Protect plugin on staging (in mu-plugins?)

If you do the last then it won't be publicly accessible and you can set WP_DEBUG to true on staging (and optionally even) WP_DEBUG_DISPLAY

Addition - Stripe Add-On for Gravity Forms, API test mode for Staging:

add_filter('gform_stripe_api_mode', function() {return 'test';} );

About

Geeks Mental is a community that publishes articles and tutorials about Web, Android, Data Science, new techniques and Linux security.