If you manage client sites or work on multi-admin WordPress projects, you already know the sinking feeling. You hand over a pristine, carefully optimized, secure site. A week later, you log back in and find three unvetted plugins installed, a bloated page builder conflict breaking the layout, and a mysterious speed optimization tool throwing fatal errors.
As developers, we try to solve this with documentation, stern warnings, and restricting user roles. But let’s be honest: agency clients or junior team members with manage_options permissions can still easily install whatever they find in the repository.
That frustration led me to build and release a new open-source WordPress plugin: WLock.
Here is why I built it, how it works under the hood, and what I learned about intercepting the WordPress installation flow along the way.
The Problem: The "Wild West" of Multi-Admin Sites
WordPress democratization is a double-edged sword. Anyone with admin privileges can go to Plugins > Add New, search for a quick fix, and hit "Install Now."
While this flexibility is great for hobby sites, it’s a nightmare for:
- Agency handoffs: Clients installing overlapping or conflicting plugins that break their site design or speed.
- Team compliance: Ensuring multiple administrators stick to an approved, secure stack of plugins and themes.
- Security & Bloat control: Preventing the accidental installation of low-quality, abandoned, or vulnerable plugins.
I didn’t want a heavy, cloud-tethered SaaS security suite just to stop unauthorized installs. I wanted a lightweight, self-hosted, deterministic whitelist guardrail.
How WLock Works
WLock is designed to be simple and self-managed. Instead of trying to lock out administrators entirely (which often backfires), it lets site owners define a strict, approved whitelist of plugin and theme slugs (e.g., woocommerce, wordpress-seo, akismet).
Once enabled:
-
Repository & Zip Guard: Any attempt to install something not on that approved list—whether searched for directly in the WordPress.org repository or uploaded manually as a
.zipfile—is instantly intercepted and blocked. - Clear Feedback: The user gets an immediate, clear on-screen explanation telling them why the installation was blocked.
- Updates Aren’t Blocked: Crucially, updates to already installed plugins and themes are never restricted. WLock only targets fresh installs.
-
Self-Managed Safety: Anyone with the
manage_optionscapability can toggle the enforcement or edit the whitelist from Settings → WLock. You can never lock yourself out permanently.
Under the Hood: Intercepting the Installer
Building this meant diving deep into how WordPress handles package installations. Whether you upload a .zip or pull from the repo, WordPress passes the installation package through specific hooks before unpacking and activating it.
WLock hooks into these routines to evaluate the incoming package slug against the admin’s saved whitelist array. If it fails the check, it aborts the process cleanly, relying entirely on core WordPress APIs (Settings API, proper nonces, and capability checks) to keep things secure and lightweight.
Because it doesn't load heavy scripts on the frontend, its performance footprint is virtually zero. It runs strictly when an installation action is triggered.
Tech Stack & Open Source
- Language: PHP 7.4+ (Compatible with modern WP versions up to 7.1+)
- WordPress Core APIs: Settings API, Options API, Transients/Sanitization routines.
The plugin is officially live on the WordPress repository. If you want to check out the code, contribute, or test it on your next client build, you can find it here:
What’s Next?
V1.0.0 is intentionally minimal—focusing purely on core whitelist enforcement for slugs. For future iterations, I'm exploring features like granular logging for blocked installation attempts and notification hooks for super-admins.
If you maintain client sites or manage multi-author WordPress installations, give it a spin and let me know how it fits into your workflow. How do you currently handle clients or teammates installing unvetted plugins? Let’s discuss in the comments!
Top comments (1)
We solved the same problem with paper before code: the care plan lists the approved plugins, and anything a client installs outside that list is billed as separate work if it breaks something. The lock helps, but the conversation matters more, because clients usually install a plugin to get a feature they asked for and didn't get.
Does WLock let a client request a plugin from inside the admin, so the ask reaches you instead of a workaround? (I run an agency at Wbcom Designs, so this is daily life for us.)