Edge Shield — Security & Performance Layer for WordPress

How It Works

Three layers, each independently deployable and removable

Edge Shield wraps your WordPress installation through native extension points — drop-ins, mu-plugins, hooks, and filters. No core hacks, no plugin patches, no theme edits.

Edge Layer

Cloudflare Worker · TypeScript

Sits at the network edge in front of WordPress. Caches responses with tag-based invalidation, blocks malicious traffic, rate-limits by IP, and proxies WebAuthn passkey authentication.

Tag-based cache with instant purge
WAF rules & blocked paths
IP rate limiting via KV
WebAuthn passkey proxy
EmDash-compatible content API

Shield Layer

PHP mu-plugins · drop-ins

Loaded at WordPress boot, before regular plugins. Monitors database queries, enforces per-plugin capability manifests, normalizes Gutenberg content to Portable Text, and adds MySQL full-text search.

Query Guardian (db.php drop-in)
Per-plugin Capability Gateway
Gutenberg → Portable Text
MySQL FULLTEXT search
Hook timing monitor

Your WordPress

Core + Plugins + Themes

Your existing installation runs exactly as before. Every plugin, every theme customization, every workflow — completely unchanged. Edge Shield operates through WordPress’s own extension points, never modifying what’s already there.

All plugins remain active
Theme files stay unmodified
Admin workflows unchanged
No database migrations

Design Principles

Built for production confidence

Every architectural decision optimizes for the same thing: you can deploy Edge Shield on a production WordPress site and sleep well.

Non-Invasive

WordPress core, plugins, and themes remain completely unmodified. Every Shield component operates through native extension points: drop-ins, mu-plugins, hooks, and filters. If WordPress supports it, that’s how Shield uses it.

Audit Before Enforce

The Capability Gateway runs in audit-only mode for weeks before blocking anything. New plugin manifests always start with enforce: false. You see exactly what would be blocked before it is.

Instant Rollback

Every component is a single file. Delete a mu-plugin — it’s gone on the next request. Remove db.php — WordPress falls back to its default. Grey-cloud DNS — the edge layer disappears entirely.

Graceful Degradation

If the Cloudflare Worker errors, WordPress keeps working — the Worker wraps WordPress, it doesn’t gate it. If a mu-plugin fails, only that component stops. Nothing is a single point of failure.

Quick Start

Up and running in five minutes

Clone the repo, start the Worker locally, and deploy Shield mu-plugins to your WordPress staging site.

terminal

# Clone the repo
$ git clone https://github.com/WisdmLabs/wordpress-edge-shield.git
$ cd wordpress-edge-shield

# Start the edge layer locally
$ cd worker && npm install
$ npx wrangler dev --remote

# Deploy Shield mu-plugins to staging
$ scp wp-content/mu-plugins/shield-*.php \
    you@staging:/path/wp-content/mu-plugins/

# Verify — site should return 200, logs should be clean
$ curl -s -o /dev/null -w "%{http_code}" https://staging.example.com/
200

Rollback

Every component is independently removable

No migration scripts, no cleanup steps. Delete the file and the component is gone.

mu-plugin

rm wp-content/mu-plugins/shield-*.php

Query Guardian

rm wp-content/db.php

Edge Worker

npx wrangler rollback

Search Index

ALTER TABLE wp_posts DROP INDEX shield_fts