About this publication

WPSifero publishes technical writing about the software that runs a WordPress site and a WooCommerce store. The focus is deliberately narrow: the parts of the stack that behave differently once real traffic, real order volume and real money are involved.

We started this because most WordPress writing is either documentation restated or a product announcement. Neither tells you what happens on a store processing four hundred orders a day when the object cache goes cold, or why the tracking page that worked in staging returns an empty timeline in production. Those are the questions we try to answer, and we try to answer them with a measurement attached.

What we cover

The archive is organised into eight topics. They are not marketing categories; they are the areas where we keep running into the same class of problem.

WordPress Internals

The options table, hook order, WP_Query behaviour, cron, and multisite storage.

WooCommerce & Storefront

Order lifecycle, HPOS, checkout sessions, custom statuses, transactional mail.

Performance

Query budgets, object caching, Core Web Vitals, benchmark methodology.

APIs & Integrations

REST contract design, webhooks, idempotency, authentication for machines.

Security & Hardening

Capability checks, nonces, SQL safety, file handling, threat modelling.

Frontend & Accessibility

Progressive enhancement, ARIA, forms, CSS architecture for admin screens.

Tooling & Workflow

Local environments, static analysis, release packaging, production debugging.

Hosting & Infrastructure

Object cache backends, real scheduling, cache invalidation, observability.

How an article gets made

Each piece starts from a specific failure. Sometimes it is one we caused. We reproduce it on a known setup, record what the database and the logs actually did, and only then decide whether there is an article in it. Roughly half of these investigations end without one, because the answer turns out to be "the host was misconfigured" and that is not worth two thousand words.

Drafting uses machine assistance. That is worth stating plainly rather than hiding, because it changes what you should expect from us. The assistance is in turning an investigation into prose and in checking our own code samples for syntax. It is not in deciding what is true. Every article is reviewed against the source material before publication, and any claim we could not reproduce is cut rather than softened. Where a number appears, the environment that produced it appears next to it.

Editorial standards

1. Reproducibility over authority. If we cannot show the query, the log line or the profile that led to a conclusion, the conclusion does not ship.
2. State the environment. WordPress version, PHP version, cache state and dataset size are part of the finding, not footnotes.
3. Name the limit. Every article says where its advice stops working. An article with no stated limitation has not been thought through.
4. No invented sources. We do not fabricate quotations, citations, issue numbers or vendor statements. Where we describe a vendor's behaviour, we describe the pattern rather than putting words in their mouth.
5. No undisclosed interest. Commercial relationships are disclosed in the article that touches them, at the top.
6. Defensive security only. We publish technique for defending a site. We do not publish working exploits against named third-party software.

Corrections

When something here is wrong, we fix it in the article and say so. Corrections are not silently edited in: the changed passage is noted at the end of the piece, and the dateModified field updates, which readers of the RSS feed will see.

To report a problem, email dm@wpsifero.com with the article URL and the specific claim you believe is incorrect. A reproducible contradiction gets priority over a difference of preference. If you are right, the correction goes up and you are credited unless you ask us not to.

About the bylines

Articles carry one of five working bylines. Each byline is responsible for a defined area and reviews work outside it before publication. The bios on the byline registry describe subject coverage, not employment history, and they should be read that way. A byline here is an attribution of editorial responsibility for a piece, not a claim about where that person has worked.

How this is funded

The site is supported by advertising served through a third-party ad network. Ad slots are labelled. Advertisers have no input into what we write, no advance sight of drafts, and no ability to remove a critical article. We do not publish sponsored posts, and we do not accept payment for a review.

WPSifero also builds and sells WordPress plugins. When an article concerns a product we build, that relationship is disclosed at the top of that article in a labelled disclosure box. You will find an example in the archive. We would rather over-disclose than have a reader discover a commercial interest we did not mention.

Independence and trademarks

WPSifero is not affiliated with, endorsed by, or sponsored by the WordPress project, the WordPress Foundation, Automattic, or WooCommerce. Those names, and the names of other products mentioned in the archive, are trademarks of their respective owners and appear here for identification and commentary only.

Get in touch

Corrections, questions and topic suggestions all go to the same place: dm@wpsifero.com. The contact page explains what to include so that your message reaches the right byline. For cookie and advertising choices, see the cookie information page.