WordPress plugins

Make the public plugin surface match the release.

Release packages, documentation, download pages, and Devenia plugin pages should point to the same current state.
Editorial illustration of organized plugin, package, and verification cards.

A plugin page is only useful when it matches the real release.

The page, package, and next action should agree.

Devenia’s free WordPress plugin pages should keep public descriptions, download links, repository state, and release assets aligned with the current release.

The plugins are not the only part that needs maintenance. Pages around them must not carry old counts, claims, or links that make a maintained plugin look confusing or stale.

The reader question

Current plugin

Is this the current plugin?

Current scope

Does the page describe what it really does now?

Next inspection

Which release or related add-on should I inspect next?

What the cleanup had to fix

Make release truth, page truth, and stack clarity easy to verify.

This is more than version bumps. A public plugin surface must make release state, plugin purpose, and the next action easy to verify.

Release truth

ZIP files, GitHub releases, staging copies, and version numbers must match.

Page truth

Plugin pages need current descriptions, scope, and release links.

Stack clarity

Group MCP and WordPress add-ons so site owners can see what fits.

Old plugin copy creates quiet risk

Stale public pages can mislead without looking broken.

A page can look polished and still mislead people if it describes an older version, an older feature set, or an older release route.

This is the most misleading kind of plugin-page drift. The page looks fine, but readers decide from facts that are no longer current.

What stale public pages can get wrong

Old download links

They can point visitors to old ZIP files.

Outdated feature scope

They can describe a feature scope that has changed.

Missing ecosystem context

They can understate the maintained add-on ecosystem.

Abandoned impression

They can make a current plugin look abandoned.

Harder installation choices

They can make installation choices harder than they need to be.

What changed

Bring public pages, repositories, release assets, and descriptions back into alignment.

The public pages, repositories, release assets, and plugin descriptions now align.

Release packages

Missing releases were published and staged ZIP files were checked against the public release assets.

Repository hygiene

Readme files, branch tracking, and lagging repository state were normalized so GitHub matched the plugin work.

Plugin pages

Public Devenia plugin pages were updated so descriptions, links, and plugin scope stopped carrying old information.

MCP add-ons

The maintained add-on set is easier to scan because plugin jobs are clearer and release information is current.

Core plugin scope

MCP Expose Abilities and URL Change Lockdown now describe their real current scope more accurately.

Plain, current plugin pages are more useful than polished pages with old facts.

The plugin stack is easier to inspect now

Give site owners a shorter path from overview to release.

A clear public surface makes current Devenia plugin work easier to follow from the overview to individual pages and releases.

What visitors can verify

Main overview descriptions and updated release links for maintained public plugins. Clearer scope on MCP Expose Abilities and URL Change Lockdown.

What maintainers can trust

Release assets should match the staged package. Repository state should reflect what people download. The public plugin surface should stay maintainable as add-ons change.

A better path for checking a Devenia plugin

Start with current public information.

The cleaned pages should make the first inspection path short and predictable.

Start at the Devenia plugins overview.
Open the page for the plugin or add-on you actually need.
Read the current scope before installing it.
Use the linked release surface to verify the current package.
Install only plugins that match the WordPress site’s actual job.
The main plugin overview is the best starting point.

That keeps plugin selection tied to current public information instead of old cached assumptions.

Frequently asked questions

What changed and how should a site choose?

Why update plugin pages after the releases are already fixed?

Because people often make installation decisions from the page they read, not from repository history. The public page has to match the real release state.

Does this mean every WordPress site should install every Devenia plugin?

No. The cleanup makes the plugin surface clearer so each site can choose the plugins and add-ons that match its actual stack.

What is the safest way to check a plugin before using it?

Read the current plugin page, follow the current release link, and confirm that the plugin scope matches the WordPress job you need.

Keep the public surface current

Maintenance is not finished until the page tells the same truth as the release.

A clean release with stale public copy still creates confusion. The goal is for the package, the repository, and the plugin page to point in the same direction.

Keep release assets and public links aligned.
Keep plugin descriptions tied to the current scope.
Group add-ons by the WordPress job they support.
Review the public plugin surface whenever the maintained stack changes.

Review the public plugin surface whenever the maintained stack changes.