Neat. Many questions. I assume you have some database of path matches for the theme/plugin js/CSS files or similar?

How extensive is the database? Just free themes/plugins from one source, or popular themes from several sources? Paid ones too?

Any namespace clashes where you have to dig deeper to tell which theme or plugin it is?

Were you able to fully automate the creation and updating of the signature database?

We actually don't have a signature database, not needed.

WordPress have a predictable path structure and we use that to extract theme and plugin slugs (textual ids). For some plugins that don't import JS or StyleSheets we look for other signatures.

Once we have the slugs, we do a lookup in the official WordPress theme/plugin repository and get all the info we need (plugin descriptions, icon, author etc)

Looks like it might be using some pattern matching that could be tightened up a bit.

For example:

http://wpdetective.io/wordpress.org

That trips it up a bit with false positives, finding plugins that aren't plugins.

When pattern matching goes wrong... Good find, we will fix this, thanks! :)

It has the look of using regex against raw page html.

I would guess you'd have better luck parsing the html and extracting the href attributes of any <link> tags, src attributes of <script> tags, etc. Then pattern matching only against that.

There are a few other websites which do a similar job with similar issues.

http://www.wpthemedetector.com/

http://scanwp.net/

http://whatwpthemeisthat.com/

All these websites scan and output similar unknown plugins, as it sharing the same database or same method to detect plugins and themes.

http://wpdetective.io/www.pmindia.gov.in

do you know off hand if any of these are open source?

So... wpscan[1] with a web frontend?

1. https://github.com/wpscanteam/wpscan

hm it doesn't seem to pick up the wp installation if the WP_CONTENT_DIR is changed. should be an easy fix, se below.

this site is very much wordpress: https://www.berghs.se/ but wpdetective won't detect wordpress at all. it has a custom WP_CONTENT_DIR.

here's a similar but less polished version my team created some years ago: http://wppluginchecker.earthpeople.se/?wordpress-site=https%...

it tries a few common variables for WP_CONTENT_DIR, and runs completely in the browser, should you want to take a peek on how we detect WP.

Tjena! Thanks for the bug report. We already detect a non-default WP_CONTENT_DIR (berghs is using assets instead of wp-content). But in this case it was our WordPress detection code that failed.

It has been fixed now: http://wpdetective.io/www.berghs.se

Looks like a web UI around wpscan?

edit: apparently custom code

Would be my first guess as well.

Edit: looks like it's not. All the more neat.

Nope, this is custom code

Interesting.

I'd be interested in the maintenance strategies you have in place (if any).

I assume that for plugins who don't output styles or scripts you use other methods, maybe some HTML output etc, so you've probably hard coded a lot of stuff for some popular plugins.

How have you set your tests and how do you plan on knowing when a certain plugin stops emitting the signature you're checking for? Most probably an E2E test with a local theme containing everything, care to share tech specifics ok this part?

We can only identify user fronting plugins that make themselves known through signatures or js/image/css imports. We do this in an automated fashion by exploiting the predictable folder structure of WordPress. So no maintenance needed here.

There are some very popular plugins (Yoast SEO, Jetpack, W3 Total Cache) that don't import additional files. For these we have hardcoded patterns (under a 100). We do not have anything in place for checking if these patterns break.

We could automate creating a WordPress installation, installing the plugin we want to check, trigger a wp detective scan and then checking the results. But I am note sure it is worth the engineering effort.

If a wordpress is installed in a subfolder example.com/wp/ it only searches in example.com and doesn't detect any wp install.

Very nice. I suppose it works by checking for js/css embeds and extracting names from the path?

Thanks!

You assume correct, that is one of the methods we are using.

We also look for signatures in the code that certain plugins output. For example Yoast SEO usually adds a HTML comment at the end of the page identifying itself.

It doesn't seem to work if the wordpress endpoint isn't at the root of a domain…

It didn't detect revolution slider on my site, which is like one of the most popular plugins.

Still great.

It usually detects it but we cannot show its icon, real name and description (only the plugin slug).

We collect this information from the WordPress plugin repository but it only contains free plugins. Paid plugins are not listed in a central place where we query their metadata.

That seems to be a limitation based on what the OP noted:

"we do a lookup in the official WordPress theme/plugin repository"

So many popular themes and plugins, especially paid ones, won't show up...because they aren't in that repo.

This is super useful for freelancers and people working with wordpress themes.

Yes that is correct. We could attempt to detect all plugins by pinging known files but that would involve indexing all available free plugins and doing around 40,000 HTTP request on the site you want to check ;) Glad you like it!

Not really, indexing the top 100 most popular plugins would be enough, and you don't have to ping all files of each one, a single file for each one would be enough (so 100 request).

I would still question the legality of that. It's akin to running a port scan on the top x number of ports.

Everything is illegal if you are oppressive enough.