find-plugin

name	find-plugin
description	Identify whether an existing WordPress plugin or WordPress Core already covers required functionality before building a custom solution.

Find an Existing WordPress Plugin

Before building a custom solution, check whether WordPress Core or an existing plugin already provides the required functionality.

Priority order

1. WordPress Core — if native WordPress APIs (blocks, REST API, CPTs, user roles, etc.) can cover the need, use them. No extra dependency required.
2. 3rd-party plugin — if a well-maintained plugin exists, recommend it over writing custom code.
3. Build custom — only if no suitable Core feature or plugin exists.

Step 1 — Check WordPress Core first

Ask yourself:

• Does WordPress already provide this via a built-in API, hook, block, or feature?
• Examples: custom post types, taxonomies, user meta, the REST API, block patterns, template parts, wp_options, transients, the Settings API, the Customizer, etc.

If Core covers the need, explain how to use it and stop here. Do not recommend a plugin or build custom code.

Step 2 — Search for plugins on WordPress.org

If Core does not cover the need, search WordPress.org/plugins for candidate plugins.

Assessment criteria

For each candidate plugin, evaluate:

Signal	What to look for
Active installs	Higher is better. 10,000+ is a meaningful signal of real-world use.
Review count & average rating	Prefer plugins with many reviews and a high average rating (4.5★+). Few reviews on a high-rated plugin are less meaningful.
Review sentiment	Scan recent reviews for recurring complaints (conflicts, broken updates, poor support).
Support forum	Check the "Support" tab on the plugin's WordPress.org page. A large backlog of unresolved threads is a red flag.
Last updated	A plugin not updated in 12+ months that hasn't been tested against the current WordPress version is a risk.
Tested up to	Must say "Tested up to: X.X" where X.X is close to the current WordPress version.
Author reputation	Prioritise plugins from large/reputable vendors: Yoast, Patchstack, Elementor, OllieWP, and others with a strong track record. Prioritise plugins by reputable individual authors such as johnbillion, rmccue, dd32, clorith, and similar well-known contributors.

When a premium plugin is better

If a premium (paid) alternative exists that is clearly superior in quality, maintenance, or support, recommend it over the free option. Explain the trade-off so the user can make an informed decision.

Step 3 — Recommend (or not)

After assessment, one of two outcomes applies:

A — A suitable plugin or Core feature exists

Present your recommendation clearly:

1. State the recommendation — plugin name, WordPress.org slug (or product URL for premium), and a one-sentence reason.

2. Explain the drawbacks — any known limitations, conflicts, performance concerns, or licence considerations.

3. Ask for explicit approval — do not add or install the plugin until the user confirms. Example:

   I recommend installing [Plugin Name] (wordpress-org-slug). Why: [reason]. Drawbacks: [any drawbacks, or "None identified"].

   Shall I add it to composer.json?

B — No good alternative exists

If no Core feature covers the need and no plugin meets the quality bar (poor maintenance, low installs, unresolved support backlog, bad reviews, etc.), a custom solution is the right choice. State this clearly so the user understands the assessment has been done and custom code is the recommended path:

I searched WordPress Core and WordPress.org for an existing solution but did not find one that meets the quality bar. Building a custom solution is the recommended approach here. Reason no existing plugin was suitable: [brief explanation, e.g. "The closest plugin hasn't been updated in two years and has unresolved compatibility issues with the current WordPress version"].

Then proceed directly to the relevant skill (e.g. new-plugin or add-block) to build the custom solution.

Step 4 — Install via Composer (WordPress.org plugins only)

Once the user approves, add the plugin via the wpackagist.org Composer repository.

Composer version format

The version constraint MUST use the ~ prefix and three levels of version numbers:

~1.0.0

Never use ^, *, >=, or a bare version number. Always use ~X.Y.Z.

composer.json snippet

{
  "repositories": [
    {
      "type": "composer",
      "url": "https://wpackagist.org",
      "only": ["wpackagist-plugin/*", "wpackagist-theme/*"]
    }
  ],
  "require": {
    "wpackagist-plugin/<plugin-slug>": "~1.0.0"
  }
}

Replace <plugin-slug> with the exact slug from the plugin's WordPress.org URL (e.g. https://wordpress.org/plugins/query-monitor/ → slug is query-monitor).

Find the correct version

Use the plugin's WordPress.org page or Packagist/wpackagist to identify the current stable version, then pin to ~X.Y.0 (keeping the patch digit at 0 unless a specific patch is required).

After updating composer.json, run:

composer update wpackagist-plugin/<plugin-slug>

Step 5 — Verify

• Confirm the plugin is listed under vendor/ after composer install.
• Activate the plugin in WordPress and verify the required functionality works.
• If the plugin adds hooks or filters, document how the project uses them in the relevant plugin or theme's hooks() method.