WordPress Redis object cache: setup and measurement
Originally published at hamzaahmadaslam.com.
How this article was made: drafted with AI assistance from a researched brief, then checked against primary documentation before publishing.
Short answer: A WordPress Redis object cache keeps WordPress object-cache data available across requests, so PHP can reuse cached query results and other objects instead of rebuilding them each time. It helps most on requests that still execute WordPress, such as logged-in pages, wp-admin, WooCommerce flows, and uncached front-end requests.
What a WordPress Redis object cache changes
WordPress includes WP_Object_Cache, but the default implementation keeps cached objects only for the current request. WordPress documents that behavior in the WP_Object_Cache reference. A persistent object cache replaces that request-only storage with a backend that survives between requests.
WordPress loads a persistent cache through wp-content/object-cache.php. The Redis Object Cache plugin installs that object-cache.php drop-in and routes WordPress wp_cache_*() calls to Redis.
This is separate from full-page caching. A page cache can return stored HTML before WordPress runs. Redis helps after PHP and WordPress are involved, which is why it is most useful for admin screens, authenticated traffic, API requests, cart and checkout activity, and pages that miss the page cache.
A cache hit can avoid database work or repeated computation. A miss still has to build the value, then Redis can store it for later requests.
How to set up the Redis Object Cache plugin
The current Redis Object Cache project documentation lists these WP-CLI commands:
wp redis enable
wp redis status
wp redis disable
wp redis update-dropin
wp redis enable enables the persistent object cache. wp redis status shows connection and drop-in diagnostics. wp redis disable disables it, and wp redis update-dropin refreshes the installed drop-in.
Run the status command after enabling Redis:
wp redis enable
wp redis status
Check that the plugin reports a connected Redis backend and a valid object-cache.php drop-in. If status reports that Redis is not connected, fix the Redis service, hostname, port, authentication, or socket path before measuring performance.
Configure the connection and key namespace
The plugin currently documents 127.0.0.1 as the default host, 6379 as the default port, database 0 as the default database, and one second for both connection and read/write timeouts.
A basic wp-config.php setup can look like this:
define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_DATABASE', 0 );
define( 'WP_REDIS_PREFIX', 'example-prod:' );
define( 'WP_REDIS_TIMEOUT', 1 );
define( 'WP_REDIS_READ_TIMEOUT', 1 );
define( 'WP_REDIS_MAXTTL', 0 );
WP_REDIS_PREFIX is the current plugin setting for separating key namespaces. WP_REDIS_MAXTTL has a documented default of 0, which means the plugin does not impose a maximum TTL.
The plugin documentation now marks WP_CACHE_KEY_SALT as deprecated and says WP_REDIS_PREFIX replaces it. Do not add a new WP_CACHE_KEY_SALT for this plugin. If a legacy installation already uses one, plan the namespace change carefully because changing prefixes makes existing Redis keys unreachable to that site.
Isolate shared Redis and multisite installations
Every independent WordPress installation sharing a Redis service needs its own key namespace. Use a unique WP_REDIS_PREFIX for each installation. The plugin also supports selecting a Redis database with WP_REDIS_DATABASE where the Redis topology supports database selection.
On WordPress multisite, one network still needs a namespace that does not collide with another WordPress installation. WordPress object-cache APIs also distinguish global groups from site-specific groups, so do not try to create per-site prefixes manually inside plugin code.
How to measure cache hits, misses, and memory
Do not judge Redis only by whether wp redis status says "connected." Measure whether requests are reusing cached objects and whether Redis is under memory pressure.
Redis exposes the required counters through the INFO command.
Run:
redis-cli INFO stats
redis-cli INFO memory
If Redis is on another host:
redis-cli -h redis.internal -p 6379 INFO stats
redis-cli -h redis.internal -p 6379 INFO memory
For authenticated environments, use the authentication method required by that Redis deployment rather than placing secrets directly in shell history.
Example output from INFO stats might look like this. These values are illustrative:
keyspace_hits:1250400
keyspace_misses:246000
evicted_keys:3100
expired_keys:18422
Compute the cache hit ratio as:
hit ratio = keyspace_hits / (keyspace_hits + keyspace_misses) * 100
hit ratio = 1250400 / (1250400 + 246000) * 100
hit ratio = 83.6%
That percentage is only the result of this example. It is not a universal target. Compare the ratio before and after configuration changes, and compare it with page generation time, database query work, and Redis latency.
Example output from INFO memory might look like this:
used_memory:268435456
used_memory_human:256.00M
maxmemory:536870912
maxmemory_human:512.00M
maxmemory_policy:allkeys-lru
used_memory shows Redis-managed memory in use. maxmemory is the configured memory ceiling. maxmemory_policy reports the active eviction policy.
How Redis evictions affect WordPress
For a Redis instance used only as a cache, set a deliberate memory ceiling and an eviction policy that can remove cache entries when the limit is reached. Redis documents allkeys-lru as a cache configuration example in its Redis configuration guide.
A Redis configuration can include:
maxmemory 512mb
maxmemory-policy allkeys-lru
The memory size here is an example configuration value, not a recommendation for every site. Size the limit from the workload and available memory.
allkeys-lru makes all keys eligible for approximate least-recently-used eviction. That is a reasonable fit when the Redis instance contains disposable cache data only. Do not apply it blindly to a Redis server that also stores data that must never be evicted.
Watch evicted_keys in INFO stats. A rising value means Redis is removing keys because it reached the maxmemory limit. Occasional eviction can be normal for a bounded cache, but sustained growth can lower reuse and force WordPress to rebuild objects repeatedly.
If used_memory stays close to maxmemory, evicted_keys keeps climbing, and misses rise, the cache may be too small for the active working set.
How non-persistent groups differ from plugin ignored groups
WordPress provides wp_cache_add_non_persistent_groups() so code can mark groups that should not survive between requests. Core currently registers groups such as counts, plugins, and theme_json as non-persistent.
Plugin or theme code can register its own request-only group:
wp_cache_add_non_persistent_groups(
array(
'my_request_only_data',
)
);
Use this only when the data is safe for the current request but should not be reused by later requests. Examples include values that depend on request-specific state that the cache key does not fully represent.
WP_REDIS_IGNORED_GROUPS is different. It is a Redis Object Cache plugin configuration constant. The plugin documents it as a list of groups that should not be cached between requests in Redis, with an empty array as the default.
The two mechanisms can produce similar persistence behavior with this plugin, but they are not the same API. wp_cache_add_non_persistent_groups() is the WordPress cache interface. WP_REDIS_IGNORED_GROUPS is plugin-specific configuration. Do not copy core groups into the plugin constant unless a specific compatibility case requires it.
How to tell when Redis is making WordPress slower
Redis can add time instead of removing it when each lookup costs more than the work it avoids.
A remote Redis server adds network round trips to object-cache calls. Measure that path from the WordPress host:
redis-cli -h redis.internal -p 6379 --latency
Example output might look like this:
min: 1, max: 4, avg: 1.62 (420 samples)
Redis documents --latency as repeated PING timing in milliseconds. This is not PHP application timing, but it helps reveal network delay between the WordPress host and Redis.
A low hit ratio is another warning. If many cache lookups miss, WordPress pays for the Redis request and still performs the database or computation work.
Large serialized values can also hurt. They cost transfer time plus PHP serialization or unserialization work. The alloptions object deserves special attention because WordPress loads and caches autoloaded options together. A very large autoloaded set can turn one cache lookup into a large payload on many requests. An autoloaded option rewritten on every request also replaces that cached copy each time, and the option-churn plugin finds such options by counting writes across many requests and naming the plugin, theme or core function that made them.
Frequent full cache flushes erase reuse. If hits fall sharply after deploys, imports, scheduled jobs, or plugin actions, look for code that flushes the entire object cache instead of invalidating only affected data.
What happens when Redis is unavailable
The Redis Object Cache 2.3.0 changelog says, "Throw errors when connection error occurs." The current documentation does not provide a transparent fallback that silently switches to the default WordPress cache after Redis fails.
Current Redis Object Cache documentation lists WP_REDIS_DISABLED as an emergency switch that bypasses the object cache without deleting the drop-in:
define( 'WP_REDIS_DISABLED', true );
The same documentation describes WP_REDIS_GRACEFUL as a setting that "Prevents exceptions from being thrown, but will cause data corruption." Do not use it as an automatic failover setting.
The practical failure plan is to keep Redis available where the site depends on it, monitor connection errors, and have a controlled way to set WP_REDIS_DISABLED during an outage. That lets WordPress run without the persistent Redis backend while the service is repaired.
Test this path before production incidents. Disable Redis in a staging environment, confirm WordPress still boots, then verify the application under the non-persistent object cache behavior.
What Redis changes for WooCommerce
WooCommerce's WC_Session_Handler has stored sessions in a custom database table since WooCommerce 2.5. The current WooCommerce WC_Session_Handler source uses the WordPress table prefix plus woocommerce_sessions.
The session handler also caches each session row through the WordPress object-cache API under its session cache group. It reads the cached value with wp_cache_get() before querying the table, and uses wp_cache_add() or wp_cache_set() when caching session data.
With a persistent Redis object cache active, an active WooCommerce session can therefore be read from Redis while the custom session table remains the source of truth. Redis does not replace WooCommerce's session table.
Redis also helps a store because WooCommerce requests read many WordPress objects outside session storage. Products, metadata, options, users, terms, and plugin data can all involve object-cache lookups.
Cart, checkout, account, and admin requests often bypass full-page caching, so persistent object caching can matter more there than on a fully cached brochure page. Measure those request types separately instead of relying on homepage results.
What to do next
After Redis is connected, compare time to first byte on uncached and authenticated requests. If wp-admin remains slow, follow the slow WordPress admin guide.
If alloptions is large, measure ownership and autoload size with the WordPress autoloaded options guide. For site-wide profiling and remediation, use the WordPress performance optimization service.
Why Online Stores Crash During Mexico's Buen Fin (and How to Prevent It): The 2026 Technical Guide
El Buen Fin, Mexico's answer to Black Friday, runs from Friday November 13 to Tuesday November 17, 2026. Almost everything published about getting a store ready for it is about banners, coupons and email. This guide is the other half: what breaks technically when the visitors you paid to attract all show up at once, and what to do beforehand. Nearly all of it is written down in your host's, your payment gateway's and your platform's documentation, and almost nobody reads it until the store is already down.
Last year's numbers show why it matters. According to Mexico's Ministry of Economy, the 2025 edition sold 219.2 billion pesos, and digital commerce was 21% of the total, growing 31% year over year. The public AMVO report (Mexico's online sales association) counted 1.686 billion page views on e-commerce sites and traffic 56% higher than the previous edition (which went from four days to five). The retailers' association ANTAD reports that the last day alone took 26.1% of online sales. The peak doesn't spread out: it arrives, and it arrives all at once.
If you sell into Mexico from abroad, or build stores for Mexican clients, the local details are what catch people out: the cash-at-OXXO payment method, the Mexican shared-hosting plans small businesses actually run on, and a gateway landscape where Mercado Pago matters as much as Stripe. I've built WooCommerce stores with catalogues in the thousands, Mercado Pago payments and WhatsApp checkout. This is what I check on each one before a date like this, with a source for every limit.
What those five days look like
| Buen Fin 2025 | Figure | Source |
|---|---|---|
| Total sales | 219.2 billion pesos | Ministry of Economy |
| Online sales | 21% of the total, +31% YoY (45.9 billion per AMVO) | Economy / AMVO |
| Traffic to online stores | +56% over the 5 days, +24% on comparable days | AMVO (Similarweb data) |
| Average ticket | $1,063 MXN online vs $780 overall | Mexican Banking Association, cited by Economy |
| How people paid online | Credit 48%, debit 43%, store cards 17%, card-free instalments 12%, cash at retail chains 12% | AMVO |
| Consumer agency complaints | 220 filed, 205 settled; mostly unhonoured prices and refused delivery | Profeco |
Two rows matter for the technical side. One in eight online buyers paid cash at a retail chain (OXXO and similar), which has a consequence for your inventory that I explain below. And 37% of consumers, per the AIMX survey the ministry cites, fear a data leak: an expired-certificate warning or a checkout page that looks off on your busiest day costs sales even if the site stays up.
Not everything that fails is yours, either. During Buen Fin 2024, Santander and BBVA customers reported card payment failures; during Hot Sale in May 2026 BBVA confirmed on X that its systems were down, with over five hours of Downdetector reports. And on November 18, 2025, the day after Buen Fin ended, Cloudflare had a global outage of more than three hours. You can't stop your customer's bank from going down. You can have a second payment method ready when it does.
1. Shared hosting has a ceiling, and it's in writing
The shared hosting plan that costs a few hundred pesos a year isn't "slow": it has exact limits, and when you hit them it doesn't slow down, it returns errors. Hostinger publishes its limits on its plan parameters page and says reaching them produces "503 – Service temporarily unavailable":
| Hostinger plan | CPU | RAM | Concurrent PHP workers | MySQL connections |
|---|---|---|---|---|
| Web Single | 1 | 1 GB | 20 | 25 |
| Web Premium | 1 | 2 GB | 40 | 50 |
| Unlimited (formerly Business) | 2 | 3 GB | 60 | 75 |
HostGator Mexico puts it differently in its help centre: a cap of 25% CPU sustained for 90 seconds or more, and 25 concurrent processes per cPanel account.
Do the maths with your own store. An uncached WooCommerce product page holds a PHP worker while it renders. If it takes one second and you have 20 workers, your ceiling is about 20 pages per second; visitor number 21 doesn't wait in line, they get an error. That's why caching, next, isn't an optimization: it decides whether those limits ever reach you.
2. Caching: what can be cached and what can't
The idea is simple: most visitors, the ones just browsing, should get a prebuilt copy of the page and cost your server nothing. Only the cart, checkout and account pages need to reach the server every time.
What almost nobody knows is that Cloudflare doesn't cache HTML by default, on free or paid plans. Its documentation is explicit: "The Cloudflare CDN does not cache HTML or JSON by default." If you put your store behind Cloudflare and configured nothing else, images, CSS and JavaScript are cached, but every page still hits your host. The free plan gives you up to 10 Cache Rules and one is enough. This expression is for a Spanish-language WooCommerce store (adjust the paths to yours):
(http.host eq "tutienda.mx"
and not starts_with(http.request.uri.path, "/wp-admin")
and not http.request.uri.path contains "/carrito"
and not http.request.uri.path contains "/finalizar-compra"
and not http.request.uri.path contains "/mi-cuenta"
and not http.cookie contains "woocommerce_items_in_cart"
and not http.cookie contains "wordpress_logged_in")
With the "Eligible for cache" action and a short edge TTL (5 to 10 minutes), browsers get the cached copy, and anyone with something in the cart or a logged-in session goes straight to your server. Two warnings:
- Purge the cache when prices change. If your discounts start at midnight on the 13th, a copy cached at 11:58 pm still shows the old price, and "the price wasn't the advertised one" is among the complaints Profeco receives most. Purge when you switch the offers on.
- A cookie on every page breaks everything. Cloudflare won't cache a response carrying Set-Cookie, and some plugins (currency switchers, geolocation, popups) send one on every visit. Check it like this:
curl -sI https://tutienda.mx/producto/tu-mas-vendido/ | grep -iE "set-cookie|cf-cache-status"
What you want to see, from the second request on, is cf-cache-status: HIT and no set-cookie. If you see DYNAMIC or BYPASS, that page is still hitting your server.
Two things look like safety nets and aren't. Always Online is on every plan, but it only kicks in on 52x errors, serves Internet Archive snapshots and can't serve dynamic content: nobody checks out from an archived copy. And Cloudflare's Waiting Room, the virtual queue big retailers use, only exists on Business and Enterprise plans.
On WooCommerce, also check cart fragments: the script that updates the cart counter by calling the server on every page. WooCommerce acknowledges that on heavily trafficked stores "this could severely impact the load on the server", and since version 7.8 it no longer loads on every page, but plenty of themes and plugins turn it back on. Open a product page with your browser's dev tools and look for a request to ?wc-ajax=get_refreshed_fragments. If it fires on pages without a mini cart, that's one server request per visit that caching can't remove.
And slim down your product photos: they're most of a store's page weight, and on mobile, where most Mexican shoppers buy, every megabyte shows.
> Free tool: Image Compressor — Compress and optimize JPG, PNG or WebP images without visible quality loss, with quality control, format change and resizing. All in your browser.
3. Your payment gateway has a limit too
The server isn't the only thing that can say no. Stripe publishes its rate limits: 100 requests per second in live mode, with most individual endpoints capped at 25. And it says plainly that "a sudden increase in charge volume, such as a flash sale, might result in rate limiting"; if you expect a spike, it asks you to contact support beforehand. Mercado Pago doesn't publish a number, but its Orders API answers 429 Too Many Requests with a Retry-After header when you exceed it.
For a small business, 100 charges a second is plenty. The problem shows up when the integration makes several calls per purchase (create customer, create payment intent, poll status) or retries without backing off: a badly handled 429 becomes "we couldn't process your payment" for a customer who had the funds.
Bank verification (3-D Secure, the "confirm in your app" screen) changes the flow too. Mexico has no regulatory mandate for it, but Mercado Pago recommends enabling it in optional mode, and when the bank asks for a challenge the payment sits in pending with detail pending_challenge. If your integration treats "pending" as "declined", you're cancelling good orders. AMVO lists "payment method rejected" among the barriers to buying online.
4. The problem nobody mentions: cash at OXXO locks your inventory
This is what worries me most for a store with limited stock, and I didn't see it in any Buen Fin guide I read. When a customer chooses to pay cash, the gateway issues a voucher with an expiry date, and until they pay, the item is in limbo:
| Gateway | Voucher validity | If they pay late |
|---|---|---|
| Stripe (OXXO) | 5 days by default, configurable from 1 to 7; confirmation arrives the next business day | The voucher expires (docs) |
| Mercado Pago (OXXO, Paycash) | Configurable from 1 to 30 days; they recommend 3. Crediting takes up to 2 business hours | "The amount will be refunded" (docs) |
| Conekta | Set by your integration with expires_at; signalled by the order.expired webhook | Up to your integration (docs) |
Now the WooCommerce side. Its "Hold stock" setting reserves items for orders pending payment for as long as you configure (60 minutes is the recommended value) and then cancels them, according to its guide. But the same guide says delayed payment methods leave the order on hold, where that automatic cancellation doesn't apply. If your gateway plugin doesn't cancel the order when the voucher expires, the item stays reserved for days by someone who may never pay, while you tell the customer holding a card that it's sold out.
Before the 13th:
1. Shorten voucher validity for the campaign. One or two days instead of five or thirty.
2. Check that your plugin cancels the order on expiry. Place a test cash order with the minimum validity, don't pay it, and check the next day that the order was cancelled and the stock came back.
3. If you sell over WhatsApp with payment links, give them a short expiry. Clip, for example, lets a link expire the same day.
5. Overselling: two people buy the last unit
Since version 4.3, WooCommerce reserves stock during checkout to stop two simultaneous purchases taking the same unit (PR #26395). Even so, issue #44273, where the team confirms that "a race condition like this is possible", is still open today. On a normal day it almost never happens. During Buen Fin, with hundreds of people on your best seller, is when it does.
For low-stock products: keep a buffer (list 18 if you have 20), cap quantity per customer, and decide in advance what you'll do if it happens, with an apology and a fast refund. Refused delivery was among the complaints that dominated Profeco's 2025 figures. Shopify's flash sale guide recommends switching to manual payment capture for the same reason: charge only for what you can actually ship.
6. What runs in the background
Order confirmation emails, payment webhooks and stock updates in WooCommerce go through Action Scheduler, which by default processes batches of 25 actions for 30 seconds, triggered by WP-Cron. And WP-Cron only runs when someone visits the site. With caching done right, hardly anyone reaches the server, and tasks can pile up. The result: customers who paid and don't get their confirmation, and message you asking whether the order went through.
The fix is a real server cron instead of the visit-driven one: set DISABLE_WP_CRON in wp-config.php and schedule a call to wp-cron.php every minute from your hosting panel. Almost every shared host allows it.
7. Test it first with fake traffic
All of the above can be checked without waiting for the 13th. A load test simulates many visitors at once and shows you where errors start. Two free options:
- k6, by Grafana: free on your own machine, and its free cloud tier includes 500 virtual user hours a month.
- Loader.io: the free plan allows 10,000 clients per test for one minute, run from US data centres.
A minimal k6 script that visits the home page and your best seller:
import http from 'k6/http';
import { check, sleep } from 'k6';
export const options = {
stages: [
{ duration: '2m', target: 50 }, // ramp to 50 concurrent visitors
{ duration: '5m', target: 50 }, // hold
{ duration: '1m', target: 0 },
],
thresholds: {
http_req_failed: ['rate<0.01'], // under 1% errors
http_req_duration: ['p(95)<2000'], // 95% under 2 seconds
},
};
export default function () {
check(http.get('https://tutienda.mx/'), { home: (r) => r.status === 200 });
sleep(3);
check(http.get('https://tutienda.mx/producto/tu-mas-vendido/'), { product: (r) => r.status === 200 });
sleep(5);
}
Run it with k6 run test.js. Three rules: test pages, never your payment gateway; on shared hosting, tell your provider first, because a load test looks a lot like an attack; and aim at three to five times your normal peak hour. There's no public figure for how much a small store's traffic rises during Buen Fin compared with an ordinary day; if your analytics kept last year's, use that. If the test fails at 50 visitors, you know what to fix, and you have seven weeks to do it.
If your store runs on Shopify or Tiendanube
Infrastructure isn't your problem: Shopify handled 489 million requests per minute at its edge over Black Friday and Cyber Monday 2025, and its guide says special preparation is only needed if you expect "tens of thousands of customers" starting checkout within minutes. Yours are the other sections: theme weight and the apps you load on every page, the gateway and its pending states, cash voucher validity, and your stock buffer.
The two-weeks-before checklist
| What | How you verify it |
|---|---|
| HTML caching on for browsers | cf-cache-status: HIT on the second request to a product page |
| No page sends Set-Cookie to visitors | The same curl -sI as above |
| Cart, checkout and account excluded from cache | Add something to the cart in another window and check the counter updates |
| New prices visible | Purge the cache when offers go live and check in a private window |
| Short cash-voucher validity | Test OXXO order you don't pay: on expiry, order cancelled and stock back |
| "Pending" payments treated as pending | Test purchase with 3-D Secure that you don't complete |
| Real server cron | DISABLE_WP_CRON in wp-config.php and a task every minute |
| Buffer on best sellers | Listed stock below real stock |
| SSL certificate valid past November 17 | Domain health report (HTTPS, redirect and HSTS) |
| Load test passed | k6 or Loader.io with no errors at three times your peak |
| Plan B for payments | Payment link and WhatsApp ready in case the gateway or the bank fails |
If you need a store or site in Mexico built to survive a date like this, that's what I do.
Frequently asked questions
When is Buen Fin 2026?
From Friday November 13 to Tuesday November 17, 2026. It is the 16th edition and runs five days because it includes Monday November 16, the observed Revolution Day holiday. Business registration is free at elbuenfin.org, from September 8 to November 12.
Why do online stores crash during Buen Fin?
Usually because every visit reaches the server uncached and the host runs out of the processes it allows. Shared plans have fixed limits (20 PHP workers on Hostinger's entry plan, 25 processes per cPanel account on HostGator Mexico) and return a 503 error past them. The payment gateway can also fail when it rate-limits, or the customer's bank, which is out of your hands.
Does Cloudflare's free plan protect a store from Buen Fin traffic?
It helps, but not just by switching it on. Cloudflare does not cache HTML by default, so without a Cache Rule every page still hits your host. The free plan allows up to 10 rules, and one is enough to cache pages for browsers while excluding cart, checkout and account. The virtual queue (Waiting Room) only exists on Business and Enterprise plans.
Does a pending OXXO payment lock my inventory?
It can, for days. Stripe OXXO vouchers expire after 5 days by default (configurable from 1 to 7) and Mercado Pago's after 1 to 30. In WooCommerce, delayed-payment orders go on hold and the 60-minute hold-stock setting only cancels orders pending payment, so the item stays reserved until the gateway plugin cancels the order when the voucher expires. Shorten validity for the campaign and test it with an order you do not pay.
How do I load test an online store?
With k6, free and open source, or Loader.io, whose free plan runs up to 10,000 clients in a one-minute test. Simulate visitors on the home page and best sellers, never on the payment gateway, aim at three to five times your peak hour, and warn your shared hosting provider first, because a load test looks like an attack.
---
Originally published on ortamarco.me.
Mentions
WordPress Redis object cache: setup and measurement Originally published at hamzaahmadaslam.com. How this article was made: drafted with AI assistance from a researched brief, then checked against primary documentation before publishing. Short answer: A WordPress Redis object cache keeps WordPress object-cache data available across requests, so PHP can reuse cached query results and other objects instead of rebuilding them each time. It helps most on requests that still execute WordPress, such as logged-in pages, wp-admin, WooCommerce flows, and uncached front-end requests. What a WordPress Redis object cache changes WordPress includes WP_Object_Cache, but the default implementation keeps cached objects only for the current request. WordPress documents that behavior in the WP_Object_Cache reference. A persistent object cache replaces that request-only storage with a backend that survives between requests. WordPress loads a persistent cache through wp-content/object-cache.php. The Redis Object Cache plugin installs that object-cache.php drop-in and routes WordPress wp_cache_*() calls to Redis. This is separate from full-page caching. A page cache can return stored HTML before WordPress runs. Redis helps after PHP and WordPress are involved, which is why it is most useful for admin screens, authenticated traffic, API requests, cart and checkout activity, and pages that miss the page cache. A cache hit can avoid database work or repeated computation. A miss still has to build the value, then Redis can store it for later requests. How to set up the Redis Object Cache plugin The current Redis Object Cache project documentation lists these WP-CLI commands: wp redis enable wp redis status wp redis disable wp redis update-dropin wp redis enable enables the persistent object cache. wp redis status shows connection and drop-in diagnostics. wp redis disable disables it, and wp redis update-dropin refreshes the installed drop-in. Run the status command after enabling Redis: wp redis enable wp redis status Check that the plugin reports a connected Redis backend and a valid object-cache.php drop-in. If status reports that Redis is not connected, fix the Redis service, hostname, port, authentication, or socket path before measuring performance. Configure the connection and key namespace The plugin currently documents 127.0.0.1 as the default host, 6379 as the default port, database 0 as the default database, and one second for both connection and read/write timeouts. A basic wp-config.php setup can look like this: define( 'WP_REDIS_HOST', '127.0.0.1' ); define( 'WP_REDIS_PORT', 6379 ); define( 'WP_REDIS_DATABASE', 0 ); define( 'WP_REDIS_PREFIX', 'example-prod:' ); define( 'WP_REDIS_TIMEOUT', 1 ); define( 'WP_REDIS_READ_TIMEOUT', 1 ); define( 'WP_REDIS_MAXTTL', 0 ); WP_REDIS_PREFIX is the current plugin setting for separating key namespaces. WP_REDIS_MAXTTL has a documented default of 0, which means the plugin does not impose a maximum TTL. The plugin documentation now marks WP_CACHE_KEY_SALT as deprecated and says WP_REDIS_PREFIX replaces it. Do not add a new WP_CACHE_KEY_SALT for this plugin. If a legacy installation already uses one, plan the namespace change carefully because changing prefixes makes existing Redis keys unreachable to that site. Isolate shared Redis and multisite installations Every independent WordPress installation sharing a Redis service needs its own key namespace. Use a unique WP_REDIS_PREFIX for each installation. The plugin also supports selecting a Redis database with WP_REDIS_DATABASE where the Redis topology supports database selection. On WordPress multisite, one network still needs a namespace that does not collide with another WordPress installation. WordPress object-cache APIs also distinguish global groups from site-specific groups, so do not try to create per-site prefixes manually inside plugin code. How to measure cache hits, misses, and memory Do not judge Redis only by whether wp redis status says "connected." Measure whether requests are reusing cached objects and whether Redis is under memory pressure. Redis exposes the required counters through the INFO command. Run: redis-cli INFO stats redis-cli INFO memory If Redis is on another host: redis-cli -h redis.internal -p 6379 INFO stats redis-cli -h redis.internal -p 6379 INFO memory For authenticated environments, use the authentication method required by that Redis deployment rather than placing secrets directly in shell history. Example output from INFO stats might look like this. These values are illustrative: keyspace_hits:1250400 keyspace_misses:246000 evicted_keys:3100 expired_keys:18422 Compute the cache hit ratio as: hit ratio = keyspace_hits / (keyspace_hits + keyspace_misses) * 100 hit ratio = 1250400 / (1250400 + 246000) * 100 hit ratio = 83.6% That percentage is only the result of this example. It is not a universal target. Compare the ratio before and after configuration changes, and compare it with page generation time, database query work, and Redis latency. Example output from INFO memory might look like this: used_memory:268435456 used_memory_human:256.00M maxmemory:536870912 maxmemory_human:512.00M maxmemory_policy:allkeys-lru used_memory shows Redis-managed memory in use. maxmemory is the configured memory ceiling. maxmemory_policy reports the active eviction policy. How Redis evictions affect WordPress For a Redis instance used only as a cache, set a deliberate memory ceiling and an eviction policy that can remove cache entries when the limit is reached. Redis documents allkeys-lru as a cache configuration example in its Redis configuration guide. A Redis configuration can include: maxmemory 512mb maxmemory-policy allkeys-lru The memory size here is an example configuration value, not a recommendation for every site. Size the limit from the workload and available memory. allkeys-lru makes all keys eligible for approximate least-recently-used eviction. That is a reasonable fit when the Redis instance contains disposable cache data only. Do not apply it blindly to a Redis server that also stores data that must never be evicted. Watch evicted_keys in INFO stats. A rising value means Redis is removing keys because it reached the maxmemory limit. Occasional eviction can be normal for a bounded cache, but sustained growth can lower reuse and force WordPress to rebuild objects repeatedly. If used_memory stays close to maxmemory, evicted_keys keeps climbing, and misses rise, the cache may be too small for the active working set. How non-persistent groups differ from plugin ignored groups WordPress provides wp_cache_add_non_persistent_groups() so code can mark groups that should not survive between requests. Core currently registers groups such as counts, plugins, and theme_json as non-persistent. Plugin or theme code can register its own request-only group: wp_cache_add_non_persistent_groups( array( 'my_request_only_data', ) ); Use this only when the data is safe for the current request but should not be reused by later requests. Examples include values that depend on request-specific state that the cache key does not fully represent. WP_REDIS_IGNORED_GROUPS is different. It is a Redis Object Cache plugin configuration constant. The plugin documents it as a list of groups that should not be cached between requests in Redis, with an empty array as the default. The two mechanisms can produce similar persistence behavior with this plugin, but they are not the same API. wp_cache_add_non_persistent_groups() is the WordPress cache interface. WP_REDIS_IGNORED_GROUPS is plugin-specific configuration. Do not copy core groups into the plugin constant unless a specific compatibility case requires it. How to tell when Redis is making WordPress slower Redis can add time instead of removing it when each lookup costs more than the work it avoids. A remote Redis server adds network round trips to object-cache calls. Measure that path from the WordPress host: redis-cli -h redis.internal -p 6379 --latency Example output might look like this: min: 1, max: 4, avg: 1.62 (420 samples) Redis documents --latency as repeated PING timing in milliseconds. This is not PHP application timing, but it helps reveal network delay between the WordPress host and Redis. A low hit ratio is another warning. If many cache lookups miss, WordPress pays for the Redis request and still performs the database or computation work. Large serialized values can also hurt. They cost transfer time plus PHP serialization or unserialization work. The alloptions object deserves special attention because WordPress loads and caches autoloaded options together. A very large autoloaded set can turn one cache lookup into a large payload on many requests. An autoloaded option rewritten on every request also replaces that cached copy each time, and the option-churn plugin finds such options by counting writes across many requests and naming the plugin, theme or core function that made them. Frequent full cache flushes erase reuse. If hits fall sharply after deploys, imports, scheduled jobs, or plugin actions, look for code that flushes the entire object cache instead of invalidating only affected data. What happens when Redis is unavailable The Redis Object Cache 2.3.0 changelog says, "Throw errors when connection error occurs." The current documentation does not provide a transparent fallback that silently switches to the default WordPress cache after Redis fails. Current Redis Object Cache documentation lists WP_REDIS_DISABLED as an emergency switch that bypasses the object cache without deleting the drop-in: define( 'WP_REDIS_DISABLED', true ); The same documentation describes WP_REDIS_GRACEFUL as a setting that "Prevents exceptions from being thrown, but will cause data corruption." Do not use it as an automatic failover setting. The practical failure plan is to keep Redis available where the site depends on it, monitor connection errors, and have a controlled way to set WP_REDIS_DISABLED during an outage. That lets WordPress run without the persistent Redis backend while the service is repaired. Test this path before production incidents. Disable Redis in a staging environment, confirm WordPress still boots, then verify the application under the non-persistent object cache behavior. What Redis changes for WooCommerce WooCommerce's WC_Session_Handler has stored sessions in a custom database table since WooCommerce 2.5. The current WooCommerce WC_Session_Handler source uses the WordPress table prefix plus woocommerce_sessions. The session handler also caches each session row through the WordPress object-cache API under its session cache group. It reads the cached value with wp_cache_get() before querying the table, and uses wp_cache_add() or wp_cache_set() when caching session data. With a persistent Redis object cache active, an active WooCommerce session can therefore be read from Redis while the custom session table remains the source of truth. Redis does not replace WooCommerce's session table. Redis also helps a store because WooCommerce requests read many WordPress objects outside session storage. Products, metadata, options, users, terms, and plugin data can all involve object-cache lookups. Cart, checkout, account, and admin requests often bypass full-page caching, so persistent object caching can matter more there than on a fully cached brochure page. Measure those request types separately instead of relying on homepage results. What to do next After Redis is connected, compare time to first byte on uncached and authenticated requests. If wp-admin remains slow, follow the slow WordPress admin guide. If alloptions is large, measure ownership and autoload size with the WordPress autoloaded options guide. For site-wide profiling and remediation, use the WordPress performance optimization service.
Bulk editing in WooCommerce can add categories and brands, but can’t remove them. This PR fixes that, while preserving mixed assignments you leave untouched. Demo below 👇 woocommerce#70226 t.co
Manufacturer part numbers (MPN) support is now in core! Available for products and variations, with CSV import/export, REST API support and product structured data. Keep it alongside your own SKU. woocommerce#60286
Why Online Stores Crash During Mexico's Buen Fin (and How to Prevent It): The 2026 Technical Guide El Buen Fin, Mexico's answer to Black Friday, runs from Friday November 13 to Tuesday November 17, 2026. Almost everything published about getting a store ready for it is about banners, coupons and email. This guide is the other half: what breaks technically when the visitors you paid to attract all show up at once, and what to do beforehand. Nearly all of it is written down in your host's, your payment gateway's and your platform's documentation, and almost nobody reads it until the store is already down. Last year's numbers show why it matters. According to Mexico's Ministry of Economy, the 2025 edition sold 219.2 billion pesos, and digital commerce was 21% of the total, growing 31% year over year. The public AMVO report (Mexico's online sales association) counted 1.686 billion page views on e-commerce sites and traffic 56% higher than the previous edition (which went from four days to five). The retailers' association ANTAD reports that the last day alone took 26.1% of online sales. The peak doesn't spread out: it arrives, and it arrives all at once. If you sell into Mexico from abroad, or build stores for Mexican clients, the local details are what catch people out: the cash-at-OXXO payment method, the Mexican shared-hosting plans small businesses actually run on, and a gateway landscape where Mercado Pago matters as much as Stripe. I've built WooCommerce stores with catalogues in the thousands, Mercado Pago payments and WhatsApp checkout. This is what I check on each one before a date like this, with a source for every limit. What those five days look like | Buen Fin 2025 | Figure | Source | |---|---|---| | Total sales | 219.2 billion pesos | Ministry of Economy | | Online sales | 21% of the total, +31% YoY (45.9 billion per AMVO) | Economy / AMVO | | Traffic to online stores | +56% over the 5 days, +24% on comparable days | AMVO (Similarweb data) | | Average ticket | $1,063 MXN online vs $780 overall | Mexican Banking Association, cited by Economy | | How people paid online | Credit 48%, debit 43%, store cards 17%, card-free instalments 12%, cash at retail chains 12% | AMVO | | Consumer agency complaints | 220 filed, 205 settled; mostly unhonoured prices and refused delivery | Profeco | Two rows matter for the technical side. One in eight online buyers paid cash at a retail chain (OXXO and similar), which has a consequence for your inventory that I explain below. And 37% of consumers, per the AIMX survey the ministry cites, fear a data leak: an expired-certificate warning or a checkout page that looks off on your busiest day costs sales even if the site stays up. Not everything that fails is yours, either. During Buen Fin 2024, Santander and BBVA customers reported card payment failures; during Hot Sale in May 2026 BBVA confirmed on X that its systems were down, with over five hours of Downdetector reports. And on November 18, 2025, the day after Buen Fin ended, Cloudflare had a global outage of more than three hours. You can't stop your customer's bank from going down. You can have a second payment method ready when it does. 1. Shared hosting has a ceiling, and it's in writing The shared hosting plan that costs a few hundred pesos a year isn't "slow": it has exact limits, and when you hit them it doesn't slow down, it returns errors. Hostinger publishes its limits on its plan parameters page and says reaching them produces "503 – Service temporarily unavailable": | Hostinger plan | CPU | RAM | Concurrent PHP workers | MySQL connections | |---|---|---|---|---| | Web Single | 1 | 1 GB | 20 | 25 | | Web Premium | 1 | 2 GB | 40 | 50 | | Unlimited (formerly Business) | 2 | 3 GB | 60 | 75 | HostGator Mexico puts it differently in its help centre: a cap of 25% CPU sustained for 90 seconds or more, and 25 concurrent processes per cPanel account. Do the maths with your own store. An uncached WooCommerce product page holds a PHP worker while it renders. If it takes one second and you have 20 workers, your ceiling is about 20 pages per second; visitor number 21 doesn't wait in line, they get an error. That's why caching, next, isn't an optimization: it decides whether those limits ever reach you. 2. Caching: what can be cached and what can't The idea is simple: most visitors, the ones just browsing, should get a prebuilt copy of the page and cost your server nothing. Only the cart, checkout and account pages need to reach the server every time. What almost nobody knows is that Cloudflare doesn't cache HTML by default, on free or paid plans. Its documentation is explicit: "The Cloudflare CDN does not cache HTML or JSON by default." If you put your store behind Cloudflare and configured nothing else, images, CSS and JavaScript are cached, but every page still hits your host. The free plan gives you up to 10 Cache Rules and one is enough. This expression is for a Spanish-language WooCommerce store (adjust the paths to yours): (http.host eq "tutienda.mx" and not starts_with(http.request.uri.path, "/wp-admin") and not http.request.uri.path contains "/carrito" and not http.request.uri.path contains "/finalizar-compra" and not http.request.uri.path contains "/mi-cuenta" and not http.cookie contains "woocommerce_items_in_cart" and not http.cookie contains "wordpress_logged_in") With the "Eligible for cache" action and a short edge TTL (5 to 10 minutes), browsers get the cached copy, and anyone with something in the cart or a logged-in session goes straight to your server. Two warnings: - Purge the cache when prices change. If your discounts start at midnight on the 13th, a copy cached at 11:58 pm still shows the old price, and "the price wasn't the advertised one" is among the complaints Profeco receives most. Purge when you switch the offers on. - A cookie on every page breaks everything. Cloudflare won't cache a response carrying Set-Cookie, and some plugins (currency switchers, geolocation, popups) send one on every visit. Check it like this: curl -sI https://tutienda.mx/producto/tu-mas-vendido/ | grep -iE "set-cookie|cf-cache-status" What you want to see, from the second request on, is cf-cache-status: HIT and no set-cookie. If you see DYNAMIC or BYPASS, that page is still hitting your server. Two things look like safety nets and aren't. Always Online is on every plan, but it only kicks in on 52x errors, serves Internet Archive snapshots and can't serve dynamic content: nobody checks out from an archived copy. And Cloudflare's Waiting Room, the virtual queue big retailers use, only exists on Business and Enterprise plans. On WooCommerce, also check cart fragments: the script that updates the cart counter by calling the server on every page. WooCommerce acknowledges that on heavily trafficked stores "this could severely impact the load on the server", and since version 7.8 it no longer loads on every page, but plenty of themes and plugins turn it back on. Open a product page with your browser's dev tools and look for a request to ?wc-ajax=get_refreshed_fragments. If it fires on pages without a mini cart, that's one server request per visit that caching can't remove. And slim down your product photos: they're most of a store's page weight, and on mobile, where most Mexican shoppers buy, every megabyte shows. > Free tool: Image Compressor — Compress and optimize JPG, PNG or WebP images without visible quality loss, with quality control, format change and resizing. All in your browser. 3. Your payment gateway has a limit too The server isn't the only thing that can say no. Stripe publishes its rate limits: 100 requests per second in live mode, with most individual endpoints capped at 25. And it says plainly that "a sudden increase in charge volume, such as a flash sale, might result in rate limiting"; if you expect a spike, it asks you to contact support beforehand. Mercado Pago doesn't publish a number, but its Orders API answers 429 Too Many Requests with a Retry-After header when you exceed it. For a small business, 100 charges a second is plenty. The problem shows up when the integration makes several calls per purchase (create customer, create payment intent, poll status) or retries without backing off: a badly handled 429 becomes "we couldn't process your payment" for a customer who had the funds. Bank verification (3-D Secure, the "confirm in your app" screen) changes the flow too. Mexico has no regulatory mandate for it, but Mercado Pago recommends enabling it in optional mode, and when the bank asks for a challenge the payment sits in pending with detail pending_challenge. If your integration treats "pending" as "declined", you're cancelling good orders. AMVO lists "payment method rejected" among the barriers to buying online. 4. The problem nobody mentions: cash at OXXO locks your inventory This is what worries me most for a store with limited stock, and I didn't see it in any Buen Fin guide I read. When a customer chooses to pay cash, the gateway issues a voucher with an expiry date, and until they pay, the item is in limbo: | Gateway | Voucher validity | If they pay late | |---|---|---| | Stripe (OXXO) | 5 days by default, configurable from 1 to 7; confirmation arrives the next business day | The voucher expires (docs) | | Mercado Pago (OXXO, Paycash) | Configurable from 1 to 30 days; they recommend 3. Crediting takes up to 2 business hours | "The amount will be refunded" (docs) | | Conekta | Set by your integration with expires_at; signalled by the order.expired webhook | Up to your integration (docs) | Now the WooCommerce side. Its "Hold stock" setting reserves items for orders pending payment for as long as you configure (60 minutes is the recommended value) and then cancels them, according to its guide. But the same guide says delayed payment methods leave the order on hold, where that automatic cancellation doesn't apply. If your gateway plugin doesn't cancel the order when the voucher expires, the item stays reserved for days by someone who may never pay, while you tell the customer holding a card that it's sold out. Before the 13th: 1. Shorten voucher validity for the campaign. One or two days instead of five or thirty. 2. Check that your plugin cancels the order on expiry. Place a test cash order with the minimum validity, don't pay it, and check the next day that the order was cancelled and the stock came back. 3. If you sell over WhatsApp with payment links, give them a short expiry. Clip, for example, lets a link expire the same day. 5. Overselling: two people buy the last unit Since version 4.3, WooCommerce reserves stock during checkout to stop two simultaneous purchases taking the same unit (PR #26395). Even so, issue #44273, where the team confirms that "a race condition like this is possible", is still open today. On a normal day it almost never happens. During Buen Fin, with hundreds of people on your best seller, is when it does. For low-stock products: keep a buffer (list 18 if you have 20), cap quantity per customer, and decide in advance what you'll do if it happens, with an apology and a fast refund. Refused delivery was among the complaints that dominated Profeco's 2025 figures. Shopify's flash sale guide recommends switching to manual payment capture for the same reason: charge only for what you can actually ship. 6. What runs in the background Order confirmation emails, payment webhooks and stock updates in WooCommerce go through Action Scheduler, which by default processes batches of 25 actions for 30 seconds, triggered by WP-Cron. And WP-Cron only runs when someone visits the site. With caching done right, hardly anyone reaches the server, and tasks can pile up. The result: customers who paid and don't get their confirmation, and message you asking whether the order went through. The fix is a real server cron instead of the visit-driven one: set DISABLE_WP_CRON in wp-config.php and schedule a call to wp-cron.php every minute from your hosting panel. Almost every shared host allows it. 7. Test it first with fake traffic All of the above can be checked without waiting for the 13th. A load test simulates many visitors at once and shows you where errors start. Two free options: - k6, by Grafana: free on your own machine, and its free cloud tier includes 500 virtual user hours a month. - Loader.io: the free plan allows 10,000 clients per test for one minute, run from US data centres. A minimal k6 script that visits the home page and your best seller: import http from 'k6/http'; import { check, sleep } from 'k6'; export const options = { stages: [ { duration: '2m', target: 50 }, // ramp to 50 concurrent visitors { duration: '5m', target: 50 }, // hold { duration: '1m', target: 0 }, ], thresholds: { http_req_failed: ['rate<0.01'], // under 1% errors http_req_duration: ['p(95)<2000'], // 95% under 2 seconds }, }; export default function () { check(http.get('https://tutienda.mx/'), { home: (r) => r.status === 200 }); sleep(3); check(http.get('https://tutienda.mx/producto/tu-mas-vendido/'), { product: (r) => r.status === 200 }); sleep(5); } Run it with k6 run test.js. Three rules: test pages, never your payment gateway; on shared hosting, tell your provider first, because a load test looks a lot like an attack; and aim at three to five times your normal peak hour. There's no public figure for how much a small store's traffic rises during Buen Fin compared with an ordinary day; if your analytics kept last year's, use that. If the test fails at 50 visitors, you know what to fix, and you have seven weeks to do it. If your store runs on Shopify or Tiendanube Infrastructure isn't your problem: Shopify handled 489 million requests per minute at its edge over Black Friday and Cyber Monday 2025, and its guide says special preparation is only needed if you expect "tens of thousands of customers" starting checkout within minutes. Yours are the other sections: theme weight and the apps you load on every page, the gateway and its pending states, cash voucher validity, and your stock buffer. The two-weeks-before checklist | What | How you verify it | |---|---| | HTML caching on for browsers | cf-cache-status: HIT on the second request to a product page | | No page sends Set-Cookie to visitors | The same curl -sI as above | | Cart, checkout and account excluded from cache | Add something to the cart in another window and check the counter updates | | New prices visible | Purge the cache when offers go live and check in a private window | | Short cash-voucher validity | Test OXXO order you don't pay: on expiry, order cancelled and stock back | | "Pending" payments treated as pending | Test purchase with 3-D Secure that you don't complete | | Real server cron | DISABLE_WP_CRON in wp-config.php and a task every minute | | Buffer on best sellers | Listed stock below real stock | | SSL certificate valid past November 17 | Domain health report (HTTPS, redirect and HSTS) | | Load test passed | k6 or Loader.io with no errors at three times your peak | | Plan B for payments | Payment link and WhatsApp ready in case the gateway or the bank fails | If you need a store or site in Mexico built to survive a date like this, that's what I do. Frequently asked questions When is Buen Fin 2026? From Friday November 13 to Tuesday November 17, 2026. It is the 16th edition and runs five days because it includes Monday November 16, the observed Revolution Day holiday. Business registration is free at elbuenfin.org, from September 8 to November 12. Why do online stores crash during Buen Fin? Usually because every visit reaches the server uncached and the host runs out of the processes it allows. Shared plans have fixed limits (20 PHP workers on Hostinger's entry plan, 25 processes per cPanel account on HostGator Mexico) and return a 503 error past them. The payment gateway can also fail when it rate-limits, or the customer's bank, which is out of your hands. Does Cloudflare's free plan protect a store from Buen Fin traffic? It helps, but not just by switching it on. Cloudflare does not cache HTML by default, so without a Cache Rule every page still hits your host. The free plan allows up to 10 rules, and one is enough to cache pages for browsers while excluding cart, checkout and account. The virtual queue (Waiting Room) only exists on Business and Enterprise plans. Does a pending OXXO payment lock my inventory? It can, for days. Stripe OXXO vouchers expire after 5 days by default (configurable from 1 to 7) and Mercado Pago's after 1 to 30. In WooCommerce, delayed-payment orders go on hold and the 60-minute hold-stock setting only cancels orders pending payment, so the item stays reserved until the gateway plugin cancels the order when the voucher expires. Shorten validity for the campaign and test it with an order you do not pay. How do I load test an online store? With k6, free and open source, or Loader.io, whose free plan runs up to 10,000 clients in a one-minute test. Simulate visitors on the home page and best sellers, never on the payment gateway, aim at three to five times your peak hour, and warn your shared hosting provider first, because a load test looks like an attack. --- Originally published on ortamarco.me.
WooCommerceのモノレポ構成から見る開発環境構築の判断ポイント 業務上の課題 WooCommerceを使ったECサイトの開発や保守に関わる際、コア本体だけでなく拡張機能や内部ツールのソースコードがどこで管理され、どのように連携しているのかを把握する必要があります。特に複数のプラグインやパッケージを横断して修正を加える場合、個々のリポジトリがばらばらに管理されていると、依存関係の整合性を保つのが難しくなります。WooCommerceはこの課題に対して、コア、拡張、パッケージ、ツールを一つのリポジトリでまとめて管理するモノレポ構成を採用しています。 モノレポが提供する機能 公式READMEによると、このリポジトリにはWooCommerce本体のプラグイン、PHPおよびJavaScriptのパッケージ、開発を支援するツール群がまとめて収録されています。ディレクトリ構成としては、pluginsディレクトリにWooCommerce本体を含む各種プラグインが置かれ、packagesディレクトリには内部依存を示すinternal-という接頭辞が付いたものを含むPHPおよびJavaScriptのパッケージが配置されています。toolsディレクトリには、モノレポ内で使う補助的なスクリプトやユーティリティ、場合によっては外部ツールも含まれるとされています。開発環境の前提としては、PNPMを実行するためのNode.js、依存管理とビルド・テストスクリプトのためのPNPM自体、PHP7.4以上、PHPパッケージやプラグインの依存管理に使うComposerが挙げられています。Node.jsのバージョンはpnpm-workspace.yaml内のuseNodeVersionで指定され、.nvmrcにも同じ内容が反映されており、PNPMがスクリプト実行時に自動でそのバージョンを利用する仕組みになっている点が説明されています。また、POSIX準拠のOSを前提としており、Windows環境ではWSLの利用が推奨されています。 導入検討の場面 社内でWooCommerceのコアに手を入れる予定がある場合や、複数の自社拡張機能を同時に開発していてパッケージ間の依存関係を一元管理したい場合には、このモノレポ構成を参考にする価値があります。また、既存の拡張機能開発で個別リポジトリの管理コストが問題になっている場合、同様のpnpmワークスペースとComposerを組み合わせた構成が自社の開発フローに合うかどうかを検討する材料になります。一方で、単一の軽量な拡張プラグインを開発するだけであれば、モノレポ全体を導入する必要はなく、該当パッケージやプラグインのディレクトリを個別に参照する方が適している場合もあります。 READMEだけでは断定できない点 公式READMEはリポジトリの構成や前提ツール、貢献手順の案内を示していますが、実際のビルド時間や依存解決の挙動、各パッケージ間の具体的な結合度についての記載はありません。また、サポートはこのリポジトリのissueトラッカーではなくコミュニティフォーラムやSlack、公式サポート窓口を通じて行うことが明記されている一方、個々の拡張機能の開発体験や保守のしやすさについては触れられていません。実際の導入を検討する場合は、CONTRIBUTING.mdや開発者向けドキュメント、tools/README.mdに記載されているモノレポ運用の詳細を別途確認する必要があります。 出典: github.com/woocommerce/woocommerce/blob/trunk/REA… 公式READMEをもとに、AIを執筆・推敲支援に使用しています。実機検証の報告ではありません。
I see you managed to do wordpress/gutenberg too! It took a bit longer 10 hours over here, but I got @woocommerce up at woocommerce/woocommerce. Also , 100% free and open source.
My first WooCommerce core PR in years got merged! 😅 woocommerce#69799
If you're using WooCommerce in a language different from English, I fixed a few translation issues: -woocommerce#69700 - woocommerce#69697 Please let me know if other parts of WooCommerce Core aren't translated even if GlotPress says that the plugin is 100% translated in your language (translate.wordpress.org)