Continuing with our line of constant improvements to our site, during the last few days we have added some new plugin detection features to our plugin detector tool.
You won´t see any changes in your user interface, but under the hood our code is now performing in a much more effective way when looking for the plugins used by the site you are interested in.
The most noticeable consequence of these improvements is that in many cases there will be more plugins being detected by our tool.
But we have also refined our scripts to avoid some possible errors, and we have introduced new features for double checking against fake detections as well.
Better plugin detection for custom installations
We noticed that at least 5% of the sites we had analysed so far use a custom WordPress installation, in the sense that the /themes/ or /plugins/ folders can´t be found where they were supposed to be if the standard WordPress folder structure was used.
There are even sites that have the themes and the plugins folders in different subdomains, or one in the main domain and the other in a subdomain. Do you think that is too weird for a WordPress site? Then guess who is using this structure… Yup, Matt Mullenweg uses it for his blog ma.tt! (or at least he was at the time of writing this post).
We knew about this and therefore different search strategies were defined for our theme detector from the beginning, but until now we were not taking advantage of them for the plugin detector scripts. So if you are a recurrent user of our site, you may find that now we detect plugins in more cases than we used to.
Some other new detection features added
Besides the ability to find plugins in more custom situations, we´ve also added some other plugin detection features to our tool, such as:
- We have increased the number of plugins that can be detected outside the /plugins/ folder.
- We have improved the way we look for plugins which are detectable but for which no reference to their main plugin folders can be found in the html code.
- We have also minimized the probabilities for fake plugin detection occurrences. Although this was not the case, I´ll give you an example of what I´m talking about: Let´s say that our scripts were searching for the words “WP Super Cache” in the html code received from the analysed site´s server and the page had some content talking about the WP Super Cache plugin. We could then erroneously derive that this plugin was used by the site, because the script did find that text string in the html code. We used to make use of one condition to avoid this, but now we´ve added a second one. Think about it as a double check against this kind of fake detection.
So if you notice that our plugin detector works better from now on, that will mean that we did a good job and that it was worth it. I hope you all enjoy it!
Latest posts by Luis Alejandre (see all)
- All Top Ten WordPress themes are premium now - 18 December, 2017
- Child Theme Detection Just Got Better - 17 January, 2017
- Child Themes: Enqueuing the parent theme stylesheet instead of using @import - 31 December, 2016