WordPress VIP, Woo at scale @ Zagreb WooCommerce meetUp

Neuralab is a WordPress VIP partner for over a year now. This means that with our specific expertise in strategy, design, and development we work closely with WordPress VIP team on building web solutions for enterprise clients. We also have the opportunity to grab some high-level foreign speakers from their lecture pool and bring them to our little community.

For this edition of our MeetUp we had the opportunity to bring Jeff Mills who has held leadership positions at digital communication companies for over 20 years. He has worked with WordPress within the enterprise for the last two years helping blue-chip companies such as NewsCorp, Penguin Books, Sky Digital, and The Daily Mail Group. As a keen accessibility advocate, he also started his own company, GrackleDocs, which ensures any document created within Google Workspace is accessible to people who use screen readers to consume information.

Surprise guest star Kenneth Lam comes from Automattic. He is a service and customer success leader at WooCommerce with extensive experience in building and leading post-sales organizations. Jeff and Ken were talking about scaling WooCommerce with some examples of WP VIP handling massive amounts of traffic.

After their presentations, Jeff and Ken were eager to answer questions from our viewers. People wanted to know about page caching recommendations, cleaner ways of handling what autoloads and what doesn’t, WP ‘bloated code’ myths… There were some questions left unanswered but our dev team managed to whip up some feedback for you.

Question: What kind of page caching would you recommend?

Neuralab Dev Team: Our contact with cache plugins is not very good, to be honest. The best of all experiences was with WP Rocket, but it is not ideal either. Simply put, the server cache needs to be resolved at the pre-WordPress level on the server, for example how Kinsta or WP Engine does it. In our experience all plugin cache options have limitations and most often there are some bugs with them. We had WP Rocket on some eCommerce projects and quite often it would be a problem because it wrote the rules in the .htaccess file (and here and there it could happen that something breaks and one plugin has to be turned off). On Kinsta this is not the case, as the caching layer is arranged at the level before and works no matter what, even whether you use WordPress or not. So we would say that for a serious and stable cache system it should be done on the server and not through a plugin layer.

There is one more thing that Kinsta (and some other hosters) offer and that is Redis. Redis provides a database cache for logged-in users. By default, when a user logs in to “WP Admin” (or in the case of WooCommerce in “My Account”) he shuts down the cache. Otherwise, the user would get the wrong data, i.e. the first user would log in and the cache would be generated with his data. This can be a problem for sites with high traffic and a lot of logged-in users. This is where Redis jumps in and caches queries to the base.

Question: Is there an incoming solution so we can store product data, orders and all the other Woo stuff in separate DB tables, as opposed to wp_options?

Neuralab Dev Team: Ken said that there are some solutions to store order data custom such as this one https://github.com/liquidweb/woocommerce-custom-orders-table. But, WooCommerce has already started to go in the “custom table” direction. Let’s say they have this concept of “lookup tables” for some things related to products where they store the price, stock status, SKU, etc. in a special table. Here is a link to the table description. The purpose of these tables is to keep essential data for products outside the post_meta table which can be quite large and slow down queries to the database. They also have their own order tables and all their meta information. Here is a description of all the tables that WooCommerce adds to the database. Here is a link to the blog post where they announce it.

Another step is their CRUD database communication system which is designed to abstract the database and not use the default WordPress writing/reading methods. Here is a link to the WooCommerce CRUD documentation.

They also have a feature plugin for moving everything to special tables. It is fully experimental (for now) and at the moment there is no announcement about when and if they will ever enter WooCommerce, but that is some of their intentions. Of course, backward compatibility is the biggest problem.

Question: How would you do an update of a live Woo store with orders happening in meanwhile during the “staging” of the store to the live update?

Neuralab Dev Team: The only way to do this is through the “atomic deployments” concept. Here is a link to a SpinupWP tutorial on the subject. This requires access to a server with a high level of authority (which means that some managed hosters will not allow it). The concept for each deploy is to make a new release (a new code folder) and then to make a new link to the last release via symlink functionality. Let’s say you have a code from 11/1/2021 in one folder and you have a symlink that tells the server when someone looks at the public folder, in essence, to show him the folder from 1.11.2021. When a new deploy arrives, a new folder is created for say 2.11.2021. and after the deploy finishes the symlink changes to look in that folder. This allows for “zero downtime” deployment and also instant rollback.

Other options are not “zero downtime”, but can reduce downtime to a minimum. Let’s say if you’re deploying via rsync functionality everything goes pretty fast, much faster than FTP. We researched this with the Buddy deployment system – the concept is to turn on (via WP CLI) the “maintenance mode” server (https://developer.wordpress.org/cli/commands/maintenance-mode/) before deployment, send the code, and turn off “maintenance mode”. You don’t do it all by hand as BuddyWorks does it for you. You would have downtime, but very small (and automatically controlled) because users do not get an error, but a message that the site is maintained. A small minus with this method is that WordPress “maintenance mode” has a limit of 5 minutes, i.e. it shuts down after 5 minutes so your deployment must be completed within that time. In our experience with BuddyWorks, we have never surpassed that limit.

Trellis also supports this concept, but it won’t be “zero downtime”. It’s also pretty fast and we think it would be possible to include the same “maintenance mode” via WP CLI.

Question: How about a cleaner way of handling what autoloads and what doesn’t? More a WordPress, than a WooCommerce question, but the idea is to help control things better from the dashboard of the CMS itself. eg. we don’t need everything from every plugin/core feature to load each time.

Neuralab Dev team: You can modify what autoloads in wp_options DB table, but you would need access to your database engine directly as we don’t currently know of any dashboard integration or plugin that does that. For example, a query for fetching what autoloads is “SELECT * FROM wp_options WHERE autoload = ‘yes’” and then after that, you would need to SQL UPDATE for any autoload option you think is fit for modifying. Here’s a more detailed link on Kinsta blog about the topic of autoloading and wp_options (and how to tackle them).

If you have any further questions for our team, don’t hesitate to contact Neuralab via all our social media channels. Hope to see y’all on the fourth edition of Zagreb WooCommerce MeetUp!