Skip to content

Upgrade WooCommerce on VIP

Keeping the WooCommerce plugin and related extensions running on the most up to date release version is essential for application security, benefitting from bug fixes and performance improvements, as well as having access to new features. 

It is recommended that all VIP customers with WooCommerce stores follow the WooCommerce Development Blog to receive notifications of available version releases in a timely manner.

Thorough testing of a new release version on non-production environments is an essential development step prior to upgrading a plugin on production. Multiple environments are provided on VIP to facilitate a thorough testing process, and steps for testing can be found below.

Error logging methods

New release versions of the WooCommerce plugin and WooCommerce extensions should be tested as soon as possible in a local development environment, followed by testing in a non-production environment on VIP.

Local development environment

  • On local development environments, WP_DEBUG can be used to log issues while testing extension and core updates. 

VIP non-production environment

  • As a precaution, a back up of the environment’s database should be run prior to deploying the upgraded plugin. Requests for database backups can be submitted to VIP Support.
  • The WC_Logger class is recommended for custom logging, and WooCommerce has a published in-depth explanation for its use.
  • Custom errors can be manually logged in New Relic. VIP Support can assist with activation of New Relic on an environment and user access to the New Relic dashboard.

Testing and validation criteria


Third-party integrations for WooCommerce on non-production environments should be set to “test-mode”, “non-production” or “sandbox” mode to prevent sending and receiving live order data, or prevent sending test order data to production integration endpoints.

Tools and materials provided by WooCommerce are available for end-to-end testing to assist with the plugin upgrade process.

Below are two sets of non-exhaustive lists of features and functionality that should be tested as part of a WooCommerce plugin upgrade. Results of each test should have identical results on non-production and production in order for the test to be considered as “successful”.

Front end functionality testing

Visually confirm that WooCommerce pages load as expected such as

  • product pages
  • category pages
  • shop page
  • cart
  • checkout

Log into the “My Account” page for a test user

  • Confirm that user account information for the test user appears as expected
  • Confirm that order history for the test user appears as expected

Test purchase flow functionality such as

  • adding and removing items in a cart
  • applying a coupon code to a checkout page
  • removing a coupon from a checkout page
  • shipping costs are calculated correctly
  • taxes are calculated correctly and for the correct region
  • completing a purchase
  • checkout flow and experience should be identical to the production site

Back end WordPress admin testing

  • In the WordPress Admin, test order processing by performing each step of the order fulfillment process. Unique or multiple order processes (manual invoicing, telesales, etc.) should also be tested individually.
  • Test backend search by searching for customer data and order data.
  • Test if products can be added/modified, or removed as expected.
  • Refer to stock management data and verify if data is modified as expected for incoming orders, processed returns, and stock deliveries.

Steps to upgrade plugins on production

  • Deploying a plugin upgrade to production is recommended only after thorough testing on non-production environments has been completed.
  • Determine a time of day to perform the plugin upgrade that will be least disruptive to a site based on average daily site traffic and the availability of internal or third-party development team resources.. 
  • As an extra precaution, a database backup can be generated just prior to a scheduled plugin upgrade. Scheduled backup requests should be submitted to VIP Support at least 24 hours before the requested backup time.
  • Once a Pull Request for a plugin upgrade is merged to the GitHub branch that deploys to production, monitor New Relic for warnings and errors, and run end-to-end tests on production.

Before upgrading, have a recovery plan in place. The plan should outline what types of issues or errors your team can handle without assistance from VIP Support and which ones require VIP Support. Having this plan in place beforehand will allow your team to act more quickly and confidently to resolve the issue.

With that being said, if the issue requires VIP Support (or you are unsure what corrective action to take):

  • Open an urgent ticket to get VIP Support to review the issue immediately. If possible, please reference the upgrade ticket you opened earlier.
  • If a code reversion is necessary, VIP will revert the codebase to the last stable commit. From there, your team should test the production site to see if the pull request reversion solved the issues. 
  • If there is data loss from an unexpected issue during the production environment upgrade, VIP will also restore the pre-upgrade backup database. 

Last updated: December 26, 2023

Relevant to

  • WordPress