DEV Community: Muhammad Zeeshan Sardar

The Obvious Way to Detect WordPress Plugins Counts WooCommerce Six Times

Muhammad Zeeshan Sardar — Wed, 30 Sep 2026 13:00:00 +0000

TL;DR: Asset paths, script handles and REST namespaces all reveal WordPress plugins from outside, and each one produces false positives if you trust it on its own. Deny core handles, map handle families to their parent plugin, require corroboration, and never trust a ?ver= that matches the core version.

Point a naive plugin detector at a WooCommerce store and it will tell you the site runs wc, wc-admin, wc-analytics, wc-telemetry, wccom-site and wc-admin-email. Six plugins. It is one plugin, WooCommerce, and the real woocommerce slug may not appear in the list at all.

The same detector will report wp-block-editor and wp-site-health as plugins. Both are WordPress core.

I build WordPress plugins, and I recently built a free scanner that reads a public site and lists the plugins it runs, with the maintenance facts WordPress.org publishes about each one. The use case is quoting: before a client hands over a login, you want to know whether you are walking into twelve current plugins or four that have not shipped a release since 2022.

Getting that list right turned out to be the whole job. Detection from outside is mostly an exercise in not believing your own evidence too quickly. Here are the three signals that work, the trap in each one, and the rules that keep the list honest.

Signal 1: asset paths (the one to trust most)

Plugins live in /wp-content/plugins/<slug>/, and when a plugin loads a stylesheet, script or image on a page, that path shows up in the HTML.

const PLUGIN_PATH = /\/wp-content\/plugins\/([a-z0-9-]+)\//gi;

function slugsFromPaths(html: string): Set<string> {
  const slugs = new Set<string>();
  for (const match of html.matchAll(PLUGIN_PATH)) {
    slugs.add(match[1].toLowerCase());
  }
  return slugs;
}

When a slug appears in an asset path, the plugin is installed and active on that page. That is about as strong as outside evidence gets, and the directory name matches the WordPress.org slug for anything installed from the directory.

The trap: absence proves nothing. Three things hide plugins from this signal:

Optimisation and caching plugins that combine every stylesheet and script into one bundle served from their own cache folder. The individual plugin paths disappear from the HTML.
Plugins with no front-end assets. Anything that works entirely in wp-admin or on the server leaves no trace in the page.
Security plugins that rewrite or hide plugin paths on purpose.

So a short list from this signal is evidence of what is visible, not evidence of a small install. That distinction has to reach the person reading the report, or they will draw the wrong conclusion.

Signal 2: script and style handles (useful, and full of traps)

When WordPress prints an enqueued script or stylesheet, it adds an ID built from the handle the code registered:

<link rel="stylesheet" id="contact-form-7-css" href="...">
<script id="wc-add-to-cart-js" src="..."></script>

Strip the -js or -css suffix and you have the handle. This signal matters because it survives some of the situations that hide asset paths, including assets served from a CDN under a different URL structure.

const HANDLE_ID = /<(?:script|link)\b[^>]*\bid=["']([a-z0-9_-]+)-(js|css)["']/gi;

function handlesFromIds(html: string): Set<string> {
  const handles = new Set<string>();
  for (const match of html.matchAll(HANDLE_ID)) {
    handles.add(match[1].toLowerCase());
  }
  return handles;
}

The regex requires the closing quote straight after -js, which quietly skips inline companions such as wc-add-to-cart-js-extra and -js-after. Those belong to a handle you have already counted.

This is where the six WooCommerce rows come from. A handle is not a slug. It is whatever string the developer chose, and three kinds of handle break the naive approach. (Core packages also start with wp-, so a blanket "anything beginning with wp-" rule would throw away real plugins such as wp-mail-smtp. The deny list has to be explicit.)

Core handles. WordPress registers dozens of its own scripts: wp-block-editor, wp-polyfill, jquery-core, wp-emoji-release, wp-block-library, global-styles, classic-theme-styles and more. None of them is a plugin. You need an explicit deny list, and it needs a comment saying where it came from, because it will need extending every few releases.

Handle families. One plugin often registers many handles under a shared prefix. WooCommerce uses wc-* and wccom-*. Yoast uses yoast-* and wpseo-*, and its directory slug is wordpress-seo, which no handle contains. You need a maintained map from prefix to parent slug, and you emit one row for the parent.

Theme handles. Themes enqueue assets too. A theme stylesheet with the ID acme-siteheader-css produces the handle acme-siteheader, which looks exactly like a plugin that does not exist.

The rule that fixes all three is corroboration. A slug derived only from a handle is accepted when it resolves in the WordPress.org directory, or when the same slug also appears as a real asset path on the site. Anything else is dropped silently.

// Core script and style handles. Extend this as WordPress adds packages.
const CORE_HANDLES = new Set([
  'jquery', 'jquery-core', 'jquery-migrate', 'wp-polyfill', 'wp-emoji-release',
  'wp-block-library', 'wp-block-editor', 'wp-site-health', 'global-styles',
  'classic-theme-styles', 'admin-bar', 'regenerator-runtime', 'lodash', 'moment',
]);

// Prefix to parent slug. Order matters: more specific prefixes first.
const HANDLE_FAMILIES: Array<[string, string]> = [
  ['wccom-', 'woocommerce'],
  ['wc-', 'woocommerce'],
  ['wpseo-', 'wordpress-seo'],
  ['yoast-', 'wordpress-seo'],
  ['elementor-', 'elementor'],
];

function familyParent(handle: string): string | null {
  if (handle === 'wc') return 'woocommerce';
  const match = HANDLE_FAMILIES.find(([prefix]) => handle.startsWith(prefix));
  return match ? match[1] : null;
}

function acceptHandle(
  handle: string,
  pathSlugs: Set<string>,
  directorySlugs: Set<string>,
): string | null {
  if (CORE_HANDLES.has(handle)) return null;

  const parent = familyParent(handle) ?? handle;
  if (pathSlugs.has(parent) || directorySlugs.has(parent)) return parent;

  return null;
}

Dropping silently is the important part. The tempting alternative is to show unmatched handles as "not in directory". That turns a theme stylesheet into a finding, and a WordPress developer will spot it in the first ten seconds and stop trusting everything else on the page.

Signal 3: REST API namespaces

Most WordPress sites expose an index at /wp-json/, and its namespaces array lists the route prefixes every active plugin has registered:

{
  "namespaces": ["oembed/1.0", "wc/v3", "yoast/v1", "contact-form-7/v1", "wp/v2"]
}

This catches plugins that load nothing on the front end but still register routes, which fills part of the gap Signal 1 leaves.

The trap: namespaces are not slugs either. wp/v2 and oembed/1.0 are core. yoast/v1 belongs to wordpress-seo. wc/v3 belongs to woocommerce. The same family map from Signal 2 does most of the work here, and the same corroboration rule applies.

It is also the weakest of the three signals. A namespace proves the plugin registered routes. It does not prove the plugin does anything visible, and some sites disable or restrict the REST index. When you report a plugin, record which signal found it (path, handle, namespace, or several), so you can tell later how much weight each row deserves.

Getting the installed version

Knowing a plugin is installed is half of it. Knowing the site runs 4.2 while the current release is 6.1 is the part that matters for a quote.

The best source is the plugin's own readme.txt, fetched from /wp-content/plugins/<slug>/readme.txt, which carries a Stable tag line. Many sites block direct requests to plugin folders, and larger ones block them almost always.

The fallback is the ver query string on asset URLs:

function versionFromAsset(
  src: string,
  pageUrl: string,
  coreVersion: string | null,
): string | null {
  const ver = new URL(src, pageUrl).searchParams.get('ver');
  if (!ver) return null;
  if (coreVersion && ver === coreVersion) return null;
  return ver;
}

The core version check exists because of how wp_register_script behaves. When a plugin registers an asset without passing its own version, WordPress appends the core version instead. Read that at face value and you will report that a plugin is on version 6.8, when 6.8 is simply the WordPress version.

Two more rules make this usable:

Label it. A version from a readme is confirmed. A version from ?ver= is inferred, because it is a cache-busting parameter and a site can put anything in it. The report should say which is which.
Find the core version from core assets, such as the ver on files under /wp-includes/. The generator meta tag is often removed, so it cannot be the only source.

What the directory can tell you, and what it cannot

Once you have a clean list of slugs, the WordPress.org plugin API gives you the maintenance facts for each one: when it last shipped a release, which WordPress version its author last tested against, and whether the directory still lists it.

What it does not give you is vulnerability data. I made a deliberate decision not to guess at it. Good vulnerability data for WordPress plugins sits behind commercial APIs, and a free tool that fakes it has two options. It can guess from version numbers, which flags plugins that are fine. Or it can flag a few famous cases and stay quiet on the rest, which implies everything unflagged has been checked. Both are worse than saying clearly that no security check was run.

The same principle applies to the score. If a site loads 11 plugins and 8 of them are premium plugins sold outside the directory, there is no public release history to judge those 8 on. A score built on the remaining 3 should say so, rather than printing "Healthy" next to it.

The standard I hold a scanner to

Fewer, truer findings beat a longer list. Every rule above removes rows rather than adding them: the deny list, the family map, the corroboration check and the core version check. Each one exists because a plausible-looking false positive costs more trust than a missing row.

If you want to see the result on a real site, the scanner is free and needs no signup: WordPress Plugin Checker. It marks which installed versions are inferred rather than confirmed, and states plainly what it could not see. If you only care about one plugin, the plugin maintenance check covers widely installed plugins one at a time.

If you build plugins yourself, I wrote about what maintaining one actually involves, including why "tested up to" goes stale on its own.

I would like to hear from anyone who has built detection like this. Which handle families or namespaces have caught you out? The family map only gets better with more eyes on it.

Export Installed WordPress Plugins & Themes to CSV (Developer-Friendly Method)

Muhammad Zeeshan Sardar — Mon, 09 Mar 2026 23:08:21 +0000

If you manage WordPress websites, you've probably encountered this problem.

You open a project and need to quickly answer questions like:

What plugins are installed on this site?
Which theme is active?
How can I export this list for documentation or auditing?

Surprisingly, WordPress does not provide a built-in way to export installed plugins and themes.

For developers and agencies managing multiple projects, this can become frustrating.

So I built a small tool to solve this problem.

In this article, I’ll show you how to export installed WordPress plugins and themes in seconds.

If you just want the quick solution:

Install Site Extensions Snapshot
Go to Tools → Site Extensions Snapshot
Click Export to CSV You will instantly download a list of all installed plugins and themes.

Plugin link:
https://wordpress.org/plugins/site-extensions-snapshot/

Why Developers Need a Plugin Snapshot

In real-world development, having a snapshot of installed extensions is extremely useful.

Here are a few common scenarios.

Client Documentation
When handing over a project, you may need to document all plugins and themes used in the website.

Website Audits
Security or performance audits often require reviewing installed plugins.

Troubleshooting
Plugin conflicts are common in WordPress. Having a full list helps identify potential issues faster.

Migration Preparation
Before migrating a website, it's helpful to know exactly which extensions are installed.

The Problem with WordPress

WordPress lets you view plugins inside the dashboard, but it doesn't allow you to:

Export the plugin list
Download the plugin inventory
Share it with a team

Most developers end up:

Manually copying plugin names
Taking screenshots
Writing custom scripts

This wastes time.

The Solution: Site Extensions Snapshot

To make this easier, I built a small WordPress plugin called:

Site Extensions Snapshot

It allows developers to export installed plugins and themes into a CSV file with one click.

Plugin page:
https://wordpress.org/plugins/site-extensions-snapshot/

What the Plugin Does

Once installed, the plugin allows you to:

✔ Export installed plugins to CSV
✔ Export installed themes to CSV
✔ Create a quick snapshot of the site environment
✔ Use the exported list for documentation or audits

It's a lightweight utility tool designed to save developers time.

How to Use the Plugin

Step 1 — Install the Plugin

Go to your WordPress dashboard:
Plugins → Add New
Search for:
Site Extensions Snapshot
Install and activate it.

Step 2 — Export Installed Plugins & Themes
After activating the plugin:

Go to Tools
Click Site Extensions Snapshot
Click Export to CSV That's it.

The plugin will download a CSV file containing all installed plugins and themes.
You can now use this file for:

Documentation
Website audits
Migration planning
Team collaboration

Who This Plugin Is For

This tool is useful for:

WordPress developers
Freelancers
Agencies
Website auditors
DevOps teams managing WordPress environments

If you work with multiple WordPress projects, this tool can simplify documentation and save time.

Why I Built This Plugin

While working on WordPress projects, I often needed a quick list of installed plugins and themes for documentation or troubleshooting.

Since there wasn't an easy way to export that information, I decided to build a small tool that solves this problem.

Try It Out

If you'd like to try the plugin, you can install it from the WordPress plugin directory.

https://wordpress.org/plugins/site-extensions-snapshot/

If you try it, I’d love to hear feedback or suggestions from the developer community.

Sometimes the simplest tools solve real developer problems.

If you regularly manage WordPress websites, having a quick way to export installed plugins and themes can make documentation and audits much easier.