The werun.Toolkit WordPress plugin is our own product, and this site had no write-up of it. This post is the release-notes companion for engineers: how the plugin is organized, how we document modules and fixes, how to read its compatibility claims and how to upgrade it without risking production.
One decision up front. We do not print module names, version numbers or release dates in a blog post. A post goes stale the day after it publishes, and a stale changelog is worse than none. The current description lives on the werun.Toolkit product page, and each release carries its own changelog.
What you get here is the method: how to read an entry, what each area of a changelog can break, and a staging-first procedure that works for this plugin and any other.
Key takeaways
- werun.Toolkit is a modular WordPress plugin built by werun.dev for teams that maintain WordPress and WooCommerce sites.
- Module names, versions and dates are published in each release's changelog and on the product page, never copied into a post that will go stale.
- Compatibility is a tested range, so confirm it against your own WordPress, PHP and WooCommerce versions on staging.
- Every update, for this plugin or any other, goes through backup, changelog review and staging before it reaches production.
What the werun.Toolkit WordPress plugin is
werun.Toolkit is a WordPress plugin that we build and maintain at werun.dev. It is organized in modules, and it is written for teams that would rather run one maintained codebase than a stack of single-purpose plugins.
A modular plugin, not a bundle of unrelated features
A module is a unit with a defined job, its own entries in the changelog and its own footprint in your site: hooks, options, admin screens or REST routes. That boundary is what makes a release readable. You can tell which part of the plugin changed and decide whether it touches you.
The reason to consolidate is operational. Every extra plugin is another vendor, another update cadence and another place for a conflict. We covered that trade-off in the plugin problem: how WordPress's ecosystem creates both power and complexity.
Who it is built for
We write for CTOs, engineers and WordPress leads who own uptime as well as features.
- Teams that maintain several WordPress sites and want one changelog to read instead of many.
- Online stores on WooCommerce, where an update has to be safe at checkout.
- Agencies that hand sites to clients and need to explain what changed.
It is not the right tool if you need one narrow feature and nothing else. A single-purpose plugin, or a custom WordPress plugin, will carry less code.
How we document werun.Toolkit modules
Each module entry answers the same five questions. We write them for the person deciding whether to update on a Friday afternoon, not for someone reading marketing copy.
| Field | What it tells you | Why engineers need it |
|---|---|---|
| What it does | The module's job in one sentence | Scope: is this a feature you need |
| Use case | A short, concrete scenario | Fit: does it replace something you run |
| Surface touched | Hooks, options, REST routes, admin screens | Risk: what could conflict with your code |
| Introduced in | The release that added it | Audit trail for your own change log |
| Breaking changes | What an upgrade can break | The reason to read before updating |
We follow the Keep a Changelog structure: releases in reverse chronological order, ISO dates, and entries grouped under Added, Changed, Deprecated, Removed, Fixed and Security. An entry looks like this. The placeholders are deliberate: this is the format, not a real release.
## [x.y.z] - YYYY-MM-DD
### Added
- Module: <module name>. What it does in one sentence. Hooks and options it registers.
### Changed
- Area: what changed and what it can affect.
### Fixed
- Area: the bug and the symptom you would have seen.
### Security
- What was addressed and whether you should update immediately.Source of truth
The changelog that ships with a release and the product page are the record for module names, versions and dates. If this post and a changelog ever disagree, the changelog is right.
Choosing which modules to turn on
Whatever the settings screen allows in the version you run, the goal is the smallest code surface that does the job. Per-module switches and their defaults are described in the plugin's settings and release notes, so confirm them there.
A practical order for a site that already has plugins installed:
- List the jobs your current plugins do: forms, redirects, SEO helpers, custom blocks.
- Match each job to a module description and mark the duplicates.
- Enable one module at a time on staging, and remove the plugin it replaces only after the flow is tested.
Improvements and fixes by area
We group changelog entries by the area of the site they affect, so you can scan for your stack first. For each area, here is what to look for in an entry.
Admin and settings
Look for renamed options, changed defaults and new capability requirements. A renamed option is a data migration, and a changed default can alter behavior on a site you did not touch. If a release changes who can reach a settings screen, check your editor and shop manager roles.
Performance and loading
Look for changes to the scripts and styles loaded on the front end, queries that run on every request and autoloaded options. Do not trust a note that says "faster". Measure LCP and INP before and after on a template that uses the plugin. Google's good thresholds are 2.5 seconds for LCP and 200 milliseconds for INP at the 75th percentile, as documented on web.dev.
Security and data handling
Entries tagged Security get read first. Look at what was addressed (input sanitization, output escaping, nonces, capability checks) and whether it is exploitable without a login. The WordPress Plugin Handbook documents those practices and is the reference we write against. Also check whether a release changes what data is stored or sent to third parties.
Developer experience and hooks
If your theme or a mu-plugin extends the plugin through actions and filters, search your code for every hook named under Changed, Deprecated or Removed. A deprecated hook still works until the release that removes it.
# Set HOOK to a hook named in the changelog's Changed, Deprecated or Removed entries
HOOK="your_hook_name"
grep -rn --include=*.php "$HOOK" wp-content/themes wp-content/mu-plugins wp-content/pluginsEntries that add hooks are the good news. They are the supported way to customize behavior without editing plugin files.
WordPress and WooCommerce compatibility
Compatibility in a changelog is a statement of what was tested, not a guarantee about your site. We state tested versions per release, and you confirm them against your own stack.
Tested WordPress and PHP versions
The plugin header declares the WordPress version it was tested up to and the minimum PHP version it requires. Read both, then match them to production, not to your local machine. A PHP minor version mismatch between staging and production is a common source of surprises.
| Layer | Confirm | How to check |
|---|---|---|
| WordPress core | Version is inside the tested range | wp core version |
| PHP | Version meets the requirement and matches production | wp --info |
| WooCommerce | Version is inside the tested range (stores only) | wp plugin get woocommerce --field=version |
| Theme and other plugins | No duplicate features or overlapping hooks | Smoke test on staging |
WooCommerce support
On a store, an update is only safe if checkout is safe. After updating on staging, place a test order end to end: add to cart, shipping, payment in the gateway's test mode, confirmation email and order status in the admin. Also check whether the release declares compatibility with WooCommerce's High-Performance Order Storage, which matters for any code that reads or writes orders.
New integrations
A new integration is new surface. Read it as new outbound requests, new credentials and new data leaving your site. Keep API keys out of the database where you can, in constants in wp-config.php or in environment variables, and limit what each key is allowed to do. If you need an integration the plugin does not cover, our integrations service builds it against the other system's REST API.
How werun.Toolkit updates are delivered
When a plugin registers an update source, WordPress lists the available update on the Plugins screen and through WP-CLI. Both give you a chance to stop before you apply it. Use that chance.
Versioning and changelog format
Read the version number against the entries, not instead of them. A release with a small version bump and a Changed entry in settings deserves a second look. A release with a large bump and only Fixed entries is often lower risk than the number suggests.
A changelog is a contract with the people who run your site: every entry should say what changed and what it can break.
werun.dev
Where to read release notes
Read the changelog before you press Update, never after. The product page describes the plugin as it stands today, and the changelog of each release records how it got there. If you manage client sites, copy the relevant entries into your own change log so the reason for each update is on record.
How to upgrade the werun.Toolkit WordPress plugin safely
The procedure below is not specific to us. It is the shape we use for plugin updates on sites under maintenance, and it fits in an afternoon.
Back up files and database
Take a full backup and confirm it restores.
Read the changelog
Look for Changed, Deprecated, Removed and Security entries.
Update on staging
Use a copy that matches production versions and data.
Run smoke tests
Test forms, login and, on a store, a full test order.
Update production and watch
Pick a quiet window and read the logs for the first hour.
Before you update
Do the preparation once and the update itself becomes boring. Work through this list before you touch anything.
- Full backup taken and a restore tested
- Staging runs the same PHP and WordPress versions as production
- Changelog read for breaking changes and deprecated hooks
- Previous plugin folder copied somewhere safe for rollback
- Maintenance window chosen for high-traffic stores
These commands export the database and keep a copy of the current plugin folder. The slug is an example, so confirm yours with wp plugin list.
PLUGIN=werun-toolkit # example slug, confirm with: wp plugin list
wp db export "pre-update-$(date +%F).sql"
cp -r "wp-content/plugins/$PLUGIN" "../$PLUGIN-previous"
wp plugin list --update=availableUpdate on staging first
Staging must match production: same WordPress, PHP and WooCommerce versions, and a recent copy of the data. Update there, then run smoke tests on the flows that make money or collect leads. Check the PHP error log and the browser console as well as the screen.
When staging is clean, update production in a low-traffic window and keep the logs open.
PLUGIN=werun-toolkit # example slug, confirm with: wp plugin list
wp plugin update "$PLUGIN" --dry-run
wp plugin update "$PLUGIN"
wp plugin get "$PLUGIN" --field=versionRoll back if something breaks
Decide the rollback trigger before you start: a failed checkout, a fatal error or a form that stops submitting. If it fires, restore the plugin folder you saved. If the release changed stored data, restore the database dump too, because an older version may not read newer data.
PLUGIN=werun-toolkit # example slug, confirm with: wp plugin list
wp plugin deactivate "$PLUGIN"
rm -rf "wp-content/plugins/$PLUGIN"
cp -r "../$PLUGIN-previous" "wp-content/plugins/$PLUGIN"
wp plugin activate "$PLUGIN"What is coming next for the plugin
We share roadmap items once the product team has confirmed them, and we label them planned, not committed. This post lists none, because a date in a blog post turns into a promise nobody can update.
What we do want is technical feedback. If you need a module, an integration or a hook that is missing, tell us. Requests that go beyond a module become custom plugin work, which we cover in custom WordPress plugin development.
Where to start with werun.Toolkit
Start with the werun.Toolkit product page for the current description of the plugin, then read the changelog of the release you plan to install. Run the staging procedure above before anything reaches production.
If you want the plugin integrated, extended or maintained as part of a wider stack, see our WordPress platform service. For a custom module or a plugin built to measure, contact the team with the problem you need solved.
Frequently asked questions
What is the werun.Toolkit WordPress plugin?
It is a modular WordPress plugin built and maintained by werun.dev for teams that run WordPress and WooCommerce sites. Its current description is on the werun.Toolkit product page, and each release ships its own changelog.
Is werun.Toolkit compatible with WooCommerce?
Compatibility is stated per release as a tested version range, so check the WooCommerce version listed in the release you plan to install. Whatever it says, test a full order on staging, because compatibility also depends on your payment gateway, theme and other plugins.
How do I update a WordPress plugin safely without breaking my site?
Back up files and database, read the changelog, then update a staging copy that matches production. Test your key flows, update production in a quiet window and keep a copy of the previous plugin version ready for rollback.
Can I turn off the werun.Toolkit modules I do not use?
Per-module settings and their defaults are documented in the plugin's settings and release notes for the version you run, so check there first and test any change on staging. The aim is the smallest set of enabled code that covers your use cases.
