Limbus Maintenance Kit – Client PDF Reports, Alerts, Update Log & Checkout Test for WooCommerce

Description

Limbus Maintenance Kit keeps the record of a site’s upkeep, and produces the three things an agency has to show for that work: a client report that goes out on its own, an e-mail the moment something breaks, and a test that walks a customer’s path through the shop.

Built for agencies and freelancers who look after WordPress and WooCommerce sites for other people. Every feature is available without a time limit, and there is no paid version.

No data about the site is sent anywhere. No account, no API key, no external service, no telemetry. Every finding is read from what the site already holds: the update data WordPress maintains, the plugin headers on disk, the site’s own options. The only address the plugin calls is the site’s own.

The client report, sent on its own

The document a client receives once a month: your logo, your accent colour, your signature, and no mention of this plugin anywhere in it. The PDF is built inside the plugin with embedded fonts, so nothing is downloaded and no service is called to produce it. It is attached to an e-mail that carries the same report in its body.

It goes out on a site nobody visits. WP-Cron does not fire without traffic, which is how a monthly report silently stops arriving on a client site with forty visits a month. The due date is not left in the cron table: it is compared on every page load, admin pages included. A report is never sent twice, nothing is sent until an address has been entered, and the site administrator address is never used as a default.

The report can be written in a language of its own, different from the site’s: a French agency with an English client sends an English report from a French site.

Every report is filed exactly as it was sent. A client writing in March about the report they received in September receives that document, not a new one about the same months — which would differ, because the log has been purged since, the score recomputed and the notes overwritten. Any archived report can be downloaded or sent again. Nothing is written to disk: the file is generated from the stored snapshot for the length of one download, and recipient addresses are never stored, only how many there were.

What it contains is measured, not typed: the updates applied with their before and after versions, the checks that followed them, the maintenance score with every deduction and its reason, the response time over the period, and the work you wrote down yourself.

An e-mail when something breaks

A list of its own, separate from the client’s: the monthly report is for a client, and “the site stopped answering at three in the morning” is for whoever can do something about it.

Always raised: a fatal error caught by WordPress, a plugin removed from the WordPress.org directory, a site that did not answer after an update, a shop with no usable payment method, a background job queue that has stopped.

Optional, each with its own switch and threshold: a customer can no longer fill a cart, the maintenance score falls below a figure you set, the site answers slower than a threshold three measurements running, nothing is scheduled to back the site up, updates have been waiting longer than you allow, PHP approaches its end of security support, and the client report could not be sent.

An alert is raised on the change, never on the state. A site under its score threshold for a month is one e-mail, not thirty; the return to normal is written in the log rather than e-mailed. One e-mail per kind of problem per day, four a day at most, and nothing at all until an address has been entered. A button sends a test alert, so a site that cannot send mail is found out before something breaks rather than during.

The checkout path test

Every other measurement this plugin takes on a shop is read from the database — and a database looks perfectly normal while nobody can buy anything. A broken update, a lost session cookie, an emptied checkout page: none of them changes a row anywhere. The only way to know is to be a customer.

So this test is one: it requests the shop page, a product page, adds that product to a cart, then asks for the cart and the checkout page, using the site’s own address. Daily, weekly or monthly, from an hour you choose, and on demand from a button on the screen that reports it.

It stops before payment, and that is the whole design. The checkout form is never filled in, no order is placed, no stock is changed, and no payment gateway is reached — so it never takes a payment, never leaves a pending order in a client’s list and never appears in their revenue figures. The claim it makes is narrow and the screen says so in as many words: a customer can reach the shop and fill a cart. Whether a card would be charged, nothing can prove without charging one.

Whether the cart actually filled is read from WooCommerce’s own cart cookies, and from the Store API when those say nothing — not from the page’s markup, where a block-based cart ships its “empty cart” template in every response and would be read as an empty one. Where nothing settles the question, the step says it could not be read rather than raising an alarm.

The rest of the shop

Six faults that stop a shop working without taking the site down: a scheduled-action queue that has stopped draining, no usable payment method, a customer-facing e-mail switched off, webhooks WooCommerce has disabled, orders unpaid for more than a week, and theme templates behind the WooCommerce originals. Also reported: order storage (HPOS or the posts table) with the extensions that declare themselves incompatible, cart and checkout implementation, stock anomalies, and the size of the WooCommerce tables.

Every call into WooCommerce is guarded. Where it does not answer as expected, the line reads unknown rather than a figure.

The maintenance log

Every update is recorded with the version before and the version after — “Yoast SEO 28.4 → 28.5” — including automatic updates applied overnight. Activations, deactivations, theme changes and failed updates are recorded, as are manual entries signed with your name and timestamped, which cannot be edited or deleted afterwards. Logins and content changes are not recorded.

Maintenance score

Six categories out of a hundred: updates left waiting, security support, plugins removed from the directory, whether the site answered, whether anything is scheduled to take a backup, and the measurements of the installation.

A hundred is reachable, and nothing is deducted for a site being small or old. A category that could not be measured is left out of the calculation and the others are rescaled, rather than counted against the site. Every deduction is listed with its reason, and the deductions add up exactly to the distance from a hundred. An update published this week costs nothing.

Check after an update

Two minutes after an update, the site requests its own home page and checks the response. The address carries a parameter never used before, so a page cache cannot answer in the site’s place.

Three deliberate limits. A request the server refuses to make at all is reported as “the check cannot run here” rather than as an outage — many hosts block loopback requests. A maintenance page is not counted as a failure; if the Limbus maintenance page is up, the check goes behind it and reads the real site. And a check more than a day late is dropped rather than run, since it would no longer concern that update.

Behind some caches or a web application firewall the check can succeed while the admin area is broken. It detects a site that has stopped answering, not every possible fault.

Copies taken before an update

Optionally, the folder of each plugin and theme is copied immediately before WordPress replaces it, commercial ones included, and can be restored from the log. The copies go in wp-content, under a name carrying eight random characters, with an index.php and a .htaccess denying access where Apache reads one — not in uploads, because what is copied is executable plugin source and uploads is served over HTTP. Restoring puts the files back and nothing else: a plugin that migrated the database while updating does not migrate it back.

Updates that would break the site

Each plugin declares the PHP and WordPress versions it requires, and that information arrives with the update itself. An update that cannot run on this server is named before anything is installed, rather than discovered by applying it.

Also reported: a pending update whose version this site has only just been offered. A version published two hours ago has been tested by its author and by nobody else, and the age is counted from the moment this site was first offered it, which requires no external service.

Nothing here takes part in the update itself. The plugin reports; you decide. No update is postponed, blocked, hidden or installed, and the plugin registers no filter on any update decision.

Plugins removed from the directory

A plugin removed from the WordPress directory stops receiving fixes, including security fixes, and WordPress reports this nowhere. The plugin keeps its own dated record of what the directory recognised and compares it over time. A plugin that was never in the directory — a commercial plugin, for instance — is never reported, since the transition is what is detected, not the absence. Several plugins disappearing at the same moment is treated as incomplete update data and nothing is recorded.

End of security support

A PHP version past its end of support still runs; it simply receives no further fixes. The plugin ships the dates published by php.net and reports where this server stands, with no version check leaving the site. A version newer than the shipped table is reported as unknown rather than estimated.

State of the installation, and performance

Seven measurements, taken every six hours at most: post revisions, the weight loaded on every page view, transients and how many have expired, tables WordPress did not create, plugins installed but deactivated, scheduled jobs running late, and administrator accounts. Nothing is deleted, optimised or cleaned. WordPress records no last login, so dormant administrator accounts cannot be identified by any plugin; the count is reported as a count.

Four performance figures: response time, weight of the home page, number of stylesheets and scripts the browser must load, and the weight loaded on every page view — with the trend that matters more than any single reading. Taken from the request the plugin already makes after an update, otherwise once a day from an admin page load, never from a visitor’s request. This is not a PageSpeed score: producing one would mean sending the site to an external service.

Backups and security

Which backup and security plugins are active, and whether their jobs are on WordPress’s schedule — a backup plugin that is active but no longer scheduled is the case that matters.

Another plugin’s private records are not read to obtain the date of the last backup: those keys are internal, change between versions, and a wrong one produces a plausible date rather than an error. The filter limbus_maintenance_kit_backup_last_run accepts that date where it can be supplied reliably.

Several sites

Settings export as a block of text to paste on the next site; e-mail addresses are never exported. Everything that only observes is on from installation. Everything that writes a file, sends mail or changes WordPress behaviour is off until enabled. Nothing of the plugin loads on a page served to a visitor — no hook, no query, no file.

External services

This plugin sends nothing anywhere, and calls no external service. No account, no API key, no telemetry. Every figure it reports is read from what the site already holds: the update information WordPress keeps, the plugin headers on disk, the site’s own options and tables. The only address it ever requests is the site’s own — its home page, for the check after an update, and its shop, cart and checkout pages for the WooCommerce checkout path test. Both requests stay on this site.

Two ordinary links in the admin interface point outside the site. A link transmits nothing until somebody clicks it, and clicking it is an ordinary visit made by that person’s browser, not by the plugin; no data about the site, and no personal data, is added to either address.

• wordpress.limbus.fr — the page describing the maintenance service of Limbus Studio, the author of this plugin. One button, on the “Human support” tab, which the Settings tab removes entirely along with the rest of that tab. Nothing is sent when the tab is opened; the address carries no parameter. Terms: https://wordpress.limbus.fr/conditions-generales-de-vente-cgv/ — Legal notice: https://wordpress.limbus.fr/mentions-legales/ — Privacy policy: https://wordpress.limbus.fr/politique-de-confidentialite/
• wordpress.org — the WordPress.org plugin directory, for the page of a plugin the “Maintenance Page” tab mentions, and only for a user who cannot install plugins from their own admin. No data is added to the address beyond the plugin’s own slug. Terms: https://wordpress.org/about/terms/ — Privacy policy: https://wordpress.org/about/privacy/