
Show HN: WP Detective – Show what theme and plugins a WordPress site is using - codeaken
http://wpdetective.io/
======
tyingq
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?

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

For example:

[http://wpdetective.io/wordpress.org](http://wpdetective.io/wordpress.org)

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

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

~~~
tyingq
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.

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

[http://www.wpthemedetector.com/](http://www.wpthemedetector.com/)

[http://scanwp.net/](http://scanwp.net/)

[http://whatwpthemeisthat.com/](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](http://wpdetective.io/www.pmindia.gov.in)

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

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

1\.
[https://github.com/wpscanteam/wpscan](https://github.com/wpscanteam/wpscan)

------
fjallstrom
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/](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%...](http://wppluginchecker.earthpeople.se/?wordpress-
site=https%3A%2F%2Fwww.berghs.se%2F)

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.

~~~
codeaken
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](http://wpdetective.io/www.berghs.se)

------
arkadiyt
Looks like a web UI around wpscan?

edit: apparently custom code

~~~
joshmn
Would be my first guess as well.

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

------
vmasto
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?

~~~
codeaken
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.

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

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

~~~
codeaken
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.

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

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

Still great.

~~~
codeaken
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.

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

------
NicoJuicy
It only detects client side scripts. Nicely done! Tested it on my own shop

~~~
codeaken
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!

~~~
notgood
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).

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

~~~
notgood
Everything is illegal if you are oppressive enough.

