search

johnmichel / Library-Detector-for-Chrome

🔍 Extension that detects which JavaScript libraries are running on a page
https://chrome.google.com/webstore/detail/cgaocdmhkmfnkdkbnckgmpopcbpaaejo
MIT License
658 stars 112 forks source link

Wordpress detection fails #203

Open connorjclark opened 1 year ago

connorjclark commented 1 year ago

For wordpress.com, which I assume it built using wordpress... this library fails to detect it.

cc @housseindjirdeh @westonruter

westonruter commented 1 year ago

Which URL on wordpress.com? On https://wordpress.com/?

connorjclark commented 1 year ago

Yeah, the home page... but only w/ mobile emulation enabled in devtools.

westonruter commented 1 year ago

On desktop, if not logged-in to WordPress.com, I see:

<meta name="generator" content="WordPress.com">

I see the same when emulating as Chrome Android Mobile.

(When I'm logged into WordPress.com I'm redirected to the admin backend of a site I manage there.)

When I look at an actual blog hosted on WordPress.com, like vintageportland.wordpress.com, I see the same generator tag. I'm actually a bit surprised that "WordPress.com" is the generator rather than the normal "WordPress". Nevertheless, both would seem to work fine according to the current library detection logic:

https://github.com/johnmichel/Library-Detector-for-Chrome/blob/3135bb24072af715f45c8c54232c7a96d11b7b09/library/libraries.js#L1674-L1676

When I run that logic in DevTools, it is resulting with a version being "WordPress.com".

So that would seem to be working correctly?

connorjclark commented 1 year ago
image

Perhaps there is an A/B test? For me, on desktop hasWPIncludes is true (the other is false); but under mobile emulation hasWPIncludes is false. There is no wlwmanifest file for the mobile load (<link rel="wlwmanifest" type="application/wlwmanifest+xml" href="//s1.wp.com/wp-includes/wlwmanifest.xml">)

westonruter commented 1 year ago

Oh, I passed over those parts of the test:

https://github.com/johnmichel/Library-Detector-for-Chrome/blob/3135bb24072af715f45c8c54232c7a96d11b7b09/library/libraries.js#L1669-L1672

I'm somewhat surprised those conditions are part of the test. Someone can turn off the WordPress API, and thus hasAPILinkElem would be false. Similarly, a theme doesn't necessarily include any scripts or stylesheets that load from wp-includes (especially if an optimization plugin is processing them).

Also, it turns out that the wlwmanifest.xml link is deprecated as of 6.3.0 (the next stable release) and will be removed from WordPress core. So it is expected that this wouldn't show up in the future:

<link rel="wlwmanifest" type="application/wlwmanifest+xml" href="https://example.com/wp-includes/wlwmanifest.xml">

So the link[href*="wp-includes"] selector will increasingly become unreliable for WordPress detection going forward. WordPress.com usually runs bleeding edge WordPress (pre-stable), which is perhaps why it is not showing up there now.

I suggest that the hasAPILinkElem and hasWPIncludes conditions be removed.

westonruter commented 1 year ago

It looks like originally when the test was introduced (2ab612aac3772b926908d7eb612d271ff8b7a386), it was checking for the meta[name="generator"] tag or the page having a script/link that mentions wp-includes. This was then changed in a8a627667670e40016af987af6bc5bbfe27e5a69 to make it a both/and condition. See https://github.com/johnmichel/Library-Detector-for-Chrome/pull/131#pullrequestreview-210916940.

Pull request in question: #131