Reliable WordPress detection

One requirement for adding a stack pack is reliably detecting that the stack/library/platform is being used by the page. We want this detection to be as reliable and bulletproof as possible.

Wappalyzer uses a few approaches which seem overkill and not something we can reuse. We’d like something much more lightweight.

Primary question: Can we detect wordpress via via clientside JS running in the page? (Naturally, it has full access to window and the DOM.)

Secondary question: Is there another reliable detect based on the network request metadata? We’d like to avoid parsing the response of any network resources (so no looking for patterns in HTML, JS or CSS files). But considering response headers or paths in urls (like wp-content, etc) is fine.

Could some WordPress experts chime in?

[igrigorik]

Since the whitelisting stuff is not really an option what’s your thought on having a XMLHttpRequest against an endpoint on the CMS side of things that LH could do to determine which system it’s talking to.

How would one protect such an endpoint? As in, exposing such a mechanism would work against the very reason why you were stripping the platform+version information. Further, I don’t think we can or should rely on new endpoints…

Yeah, why not check whether /wp-admin/ does not deliver a 404.

That requires an additional out of band request which, while not impossible, is something we’d like to avoid.

Stepping back, I’ll come back to what I said earlier: if your site is designed to hide all platform information, then the fact that LH is not able to detect it is not a bug, it’s WAI. Despite that, developers that want to see stack specific advice can still get access to it… by, for example, configuring the environment to expose those signals under certain conditions. Alternatively, one could also imagine a UI where you can manually pick which stack pack strings LH shows, even if LH is not able to detect that platform itself.

Does that seem reasonable? 😃

[Shelob9]

wp-content is the default it can be changed by setting a constant in wp-config. wp-includes (effectively) can’t be changed.