Ik heb een client gescand' s shop voor plugins en kreeg er drie terug De site draaide zesentwintig Niets was kapot en niets was met opzet verborgen: hun optimalisatie plugin had elk script samengevoegd tot één gecombineerd bestand, en een samengevoegd bestand heeft geen plugin mappen in zijn naam De scan was accuraat over wat de pagina geladen en nutteloos als een inventaris, dat is het onderscheid waar deze gids over gaat.
Het detecteren van plugins van buiten een site is echt nuttig en echt beperkt, en de meeste tools vertellen je alleen de eerste helft. Hier is hoe de detectie werkt, wat elk resultaat wel en niet kan betekenen, en hoe je een shortlist kunt lezen zonder de verkeerde conclusie te trekken. De WordPress Plugin Detector rapporteert beide helften met opzet.
tl;dr: Plugin detectie werkt door het vinden van bestanden geladen van
/wp-content/plugins/<slug>/op een pagina Alles wat geen front-end bestand laadt is onzichtbaar: plugins die alleen voor beheerders zijn, plugins die op andere pagina's vuren en alles waarvan de assets door een cachingplugin zijn samengevoegd tot één gecombineerd bestand Behandel het resultaat als een verdieping, nooit een totaal Een interieurpagina scannen in plaats van de startpagina vindt betrouwbaar meer.
Hoe werkt plugin detectie eigenlijk?
Een plugin die alles wat zichtbaar is doet moet iets laden uit zijn eigen map WordPress serveert plugin bestanden vanaf een vast pad, /wp-content/plugins/<slug>/dus elk stylesheet, script of afbeelding die vanaf daar wordt geladen, noemt de plug-in die eigenaar is van het:
<link rel="stylesheet" href="/wp-content/plugins/contact-form-7/includes/css/styles.css?ver=5.9.3" />
<script src="/wp-content/plugins/woocommerce/assets/js/frontend/cart-fragments.min.js?ver=9.2.3"></script>
Dat is contact-form-7 en woocommerce, vermeld door de pagina in plaats van afgeleid uit hoe het zich gedraagt Een paar plugins kondigen zich nog duidelijker aan: een body class, een REST-naamruimte onder /wp-json/, een metatag, een HTML-opmerking, een cookienaam.
De versie rijdt meestal mee in de query string. ?ver=5.9.3 is wat WordPress toevoegt voor het verbreken van cache, en bij de meeste installaties is dit de plug-in's echte versie. Sites die versiequeryreeksen strippen om cachingredenen, of die een waarde hardcoderen, rapporteren niets of iets ouds.
| Bewijs | toonbeeld | Vertrouwen |
|---|---|---|
| Vermogensweg | /wp-content/plugins/woocommerce/... |
De plugin laadde een bestand op deze pagina |
| Versiequeryreeks | ?ver=9.2.3 |
Meestal de geïnstalleerde versie |
| REST-naamruimte | /wp-json/wc/v3 |
De plugin registreerde API-routes |
| Bodyclass | woocommerce-page |
De plugin is actief op dit paginatype |
Waarom blijven zoveel plugins onzichtbaar?
Vier gewone opstellingen verbergen plug-ins, en geen van hen betekent dat de site iets verkeerd doet.
Plug-ins die alleen door beheerders worden gebruikt, laden niets voor een bezoeker. Back-upplanners, SEO-editors, migratietools, gebruikersrolmanagers, ensceneringshulpprogramma's: ze doen hun werk binnenin wp-admin en voeg niets toe aan de voorkant Een groot deel van elke echte site' s plugin lijst is in deze categorie en is onzichtbaar van buitenaf door het ontwerp.
Plug-ins vuren op de pagina's waar ze voor zijn. Een checkout plugin laadt op de checkout Een formulier plugin laadt waar het formulier is Scannen van een homepage en concluderen dat de site heeft drie plugins is als het lezen van de eerste pagina van een boek en het rapporteren van het aantal woorden.
Optimalisatieplug-ins wissen mapnamen. Dit is de grote Een plugin die elk script en stylesheet samenvoegen tot één bestand onder een cachemap verwijdert de plugin mapnamen van alles wat het samengevoegd heeft, inclusief zijn eigen De code is er allemaal nog Het bewijs is er niet.
Hosts en CDN's herschrijven assetpaden. Sommige beheerde hosts proxy elk statisch bestand via een pad dat niet langer bevat /wp-content/plugins/. Hetzelfde effect, toegepast op de hele site in één keer.
Een leeg resultaat heeft dus minstens vijf betekenissen: er zijn geen plug-ins actief, geen enkele laad front-end assets, een optimizer heeft ze samengevoegd, de host heeft de paden herschreven, of de site is geen WordPress. Een tool die "0 plugins" zonder deze te scheiden, rapporteert het geen bevinding, maar zijn eigen blinde vlek.
Wat betekent een mapnaam zonder echte naam?
Detectie geeft je een slug. Om van die slug een gepubliceerde naam te maken, moet een huidige versie en een aantal installaties overeenkomen met de plug-inmap, en niet elke plug-in zit in één.
Een kale slug zonder overeenkomende invoer betekent bijna altijd een van de volgende drie dingen Het is een premium plugin die buiten WordPress.org wordt verkocht en die de meeste commerciële paginabuilders, formulierplugins en lidmaatschappen beschrijft Het is op maat gemaakt, geschreven voor die ene site door degene die deze heeft gebouwd Of de map is gewoon hernoemd, wat sommige site-eigenaren opzettelijk doen.
Dat is op zichzelf al een handig signaal Een site waarvan de plugin lijst meestal ongeëvenaard is slugs draait commerciële of op maat gemaakte software, en dat vertelt je iets over het budget erachter voordat je iemand een vraag hebt gesteld.
Hoe kom je aan een completer beeld?
Scan meer dan één pagina Dit is de enige gewoonte met de hoogste waarde en kost niets:
- De homepage, voor het site-brede meubilair: analyses, toestemmingsbanners, paginabuilders, schuifregelaars.
- Een blogpost voor plug-ins aan de inhoud: gerelateerde berichten, inhoudsopgave, sociaal delen, reactiesystemen.
- Een product- of prijspagina, voor commercie: de winkelplug-in, betalingsgateways, valutaswitchers.
- Een contactpagina, voor formulieren, kaarten en spambeveiliging.
Neem de unie Zelfs dan is het een verdieping, maar een veel hogere dan welke pagina dan ook geeft.
de /wp-json/ index is ook de moeite waard om te bekijken, wanneer het is ingeschakeld Plug-ins die REST-routes registreren, verschijnen daar per naamruimte, ongeacht wat de voorkant heeft geladen, dus het vangt een deel op van wat asset-paden missen:
curl -s https://example.com/wp-json/ | grep -o '"namespace":"[^"]*"' | sort -u
Is het scannen van iemand's site acceptabel?
Het lezen van een openbare pagina is een gewoon verzoek Het verschijnt in de site' s toegangslog precies zoals een bezoek van een browser, en het logt niet in, verzendt niets of raakt het admin gebied De WordPress beveiligingsdocumentatie houdt zich bezig met wat een geauthenticeerd of indringend verzoek kan doen, niet met wat een pagina vrijwillig aan elke bezoeker publiceert.
Waar het scherper wordt is opzet Een plugin lijst is verkenning als je het als één gebruikt: een verouderde versie van een plugin met een bekende kwetsbaarheid is precies wat een aanvaller zoekt Dat is eerder een reden om je eigen plugins up-to-date te houden dan een reden om te doen alsof de informatie geheim is, aangezien iedereen dezelfde pagina kan lezen Als je een site die je niet bezit controleert, blijf dan bij wat de pagina je vertelt en laat het daar staan.
Waar het resultaat goed voor is
Gebruikt binnen zijn grenzen, een externe plugin scan beantwoordt echte vragen snel Welke paginabuilder gebruikt deze site, dus ik kan citeren voor wijzigingen Is deze shop op WooCommerce of iets gehost Wat is de plugin voor formulieren, dus ik kan het matchen Is deze concurrent die dezelfde SEO stack draait als wij Is mijn eigen staging site per ongeluk een plugin laden Ik heb lokaal uitgeschakeld.
Wat het niet kan doen is een inventaris maken Daarvoor heb je de admin nodig, wp plugin list afgelopen WP-CLI, of iemand die de login heeft.
Als de vraag is wat de pagina weergeeft in plaats van wat erop wordt geladen, dan is dat de vraag WordPress Theme Detector, die het thema leest' eigen style.css voor de naam, versie en ouder En wanneer u degene bent die een plugin publiceert, zal de readme generator schrijft de readme.txt dat bepaalt hoe uw plug-in' de eigen directorylijst luidt.
