Avoid WooCommerce staging environments

Over the years I’ve faced lots of problems with staging environments. A cure-all for me has been deleting them and using LocalWP for local sandbox environments. Plus it adds so many useful features!

I’m inspired to write this post because to this day I hear technical support representatives ask to try something on staging, or to give them staging access. No!

Here’s why staging environments suck:

• Customers can find their way to them and place orders there; then Customer Support has a hard time when they find order number 1234 seems to be from another customer, great confusion and a difficult remediation.
• Emails can go out; think order receipts, waitlists, abandoned carts, renewals, password resets, and more.
• Subscriptions sites can process renewal payments if not carefully disabled, especially since plugins tend to be left active, and often times staging is spun up from a backup set from X days ago where renewals have queued.
• Security exposure of sensitive customer and business information, more exposed to trial administrator accounts, and not monitored for activities.
• Search engines might cache it, especially if you aren’t using an also problematic password wall (see below).
• Can be really slow to use when lacking the level of caching that production has, especially since there’s a tendency to leave all 50 plugins running.
• Software updates pile up in an online resource that may go unattended for years at a time.
• Subtracts from your allotted storage and server resources, depending on your hosting plan.
• If you release portions of it and forget to search/replace the URLs you may not know it for some time, since images and links may look correct until you check the network within your browser inspector and see things pulling off staging.
• Cloud services (e.g. Facebook, Klaviyo, Searchanise) can cache the staging URL instead of production then serve it to users on production. I’ve seen it happen multiple times.
• Third party licensed themes and plugins (e.g. Elementor Pro) can reject the URL and fail to activate, update, let you use them fully, or give other incredibly annoying drama like warning banners.
• Giving multiple developers access can mean folks stepping on each other, sporadically treating a shared environment as their own sandbox, which is what they should be using instead.
• Password walls meant to protect staging can not only cache bust, but also cause certain asynchronous interfaces to fail.

Less common positive uses for Staging:

• Sharing progress on a site not yet launched.
• Sharing a new theme or major development between developers and project managers that will be released piece by piece later on.
• Connecting an online resource to a third party cloud service for testing pre launch, since some integrations can require a public URL.
• Testing particularities of the hosting platform such, caching, security, and server settings.