wp core verify-checksums
Success: WordPress installation verifies against checksums.This is the command I trust more than any dashboard badge. It downloads the md5 checksums WordPress.org published for your installed version, compares them against your files, and names anything that does not match. It never loads WordPress and never interprets a file. The whole thing answers one question: did these bytes change. It’s also the clearest everyday example I know of quantum error correction, which asks about a property of the data instead of the data itself.
That connection is why I kept reading Davinder Singh’s article on Towards Data Science about keeping quantum information alive for machine learning. His piece explains why the field needs error correction at all, and it starts from a trade-off web developers make all the time: a cheap signal that says something changed, versus an expensive look at the thing itself.
Why quantum error correction can’t copy its way out
Classical error handling is built on redundancy. Store the bit three times, read all three back, take the majority. That works because a classical bit can be copied and inspected without consequence. A qubit gets neither. The no-cloning theorem says an unknown quantum state can’t be perfectly duplicated, and measurement collapses the superposition you were trying to protect. Both obvious strategies are unavailable, and the reason is physics rather than cost.
Singh walks through the three fundamental errors: X for a bit flip, Z for a phase flip, and Y for both. The one with no classical equivalent is Z. The qubit still measures 0 or 1 with the same probabilities, and only the relative phase moved. Quantum algorithms live on interference between amplitudes, so the computation breaks downstream. It fails quietly, which any developer recognizes.
Measure a property instead of the state
The fix on the quantum side is to encode one logical qubit across several physical qubits, then measure carefully chosen properties of the group. Those properties, called syndromes, reveal where an error happened without revealing what the state is. IBM’s Foundations of Quantum Error Correction course covers this properly if you want the linear algebra. The shape of the trick should look familiar, though. A checksum answers whether a thing changed, and nothing else.
Hashing does read every byte, so it is not literally free, but it never interprets them and the stored verdict is short. That is why the command is safe to point at a live site: per the WP-CLI docs, it runs before WordPress loads. A small mu-plugin gives you the same guard for files nobody publishes checksums for:
<?php
// mu-plugin: snapshot files you care about, verify later
function bbioon_snapshot_files( array $paths ): void {
$snapshot = array();
foreach ( $paths as $path ) {
$snapshot[ $path ] = md5_file( $path );
}
update_option( 'bbioon_file_snapshot', $snapshot, false );
}
function bbioon_files_drifted(): array {
$snapshot = get_option( 'bbioon_file_snapshot', array() );
$drifted = array();
foreach ( $snapshot as $path => $hash ) {
if ( md5_file( $path ) !== $hash ) {
$drifted[] = $path;
}
}
return $drifted;
}If you want this kind of guard on client sites, with snapshot checks wired to cron alerts and checksum runs in the deploy script, that is work I do regularly, and I’m glad to scope it for your setup.
What the redundancy costs
Error correction is never free, and the quantum version prices it openly. IBM’s gross code protects 12 logical qubits with 288 physical ones, where a surface code doing roughly the same job needs nearly 3,000. That is about twenty-four physical qubits per useful one, on the good end of current options. WordPress has the same asymmetry: core is verifiable only because WordPress.org publishes checksums for every release, and that is where file integrity checks stop working. Nothing publishes a reference hash for your mu-plugins, uploads folder, or order tables.
So the check catches an edited wp-admin file and misses a drifted option value or a half-written order row. That is a different error class, so it needs a different tool.
What I still wonder
My open question is whether the syndrome idea transfers to data. Files have a publisher who can hand you a reference hash; order rows do not. But stores have invariants: an order total should equal the sum of its line items, term counts should match the posts they index, and foreign keys should balance. Could a handful of checks like those act as syndromes and flag drift in WooCommerce data without a row-by-row audit? I don’t know the answer, and it matters, because the damage that hurts stores is the kind checksums cannot see.
