WordPress.org Ops — Plugin Intel, Core Version, PHP & Salts

Pick the job

WordPress.org Ops is the Tools.town cluster for directory and core APIs — not Gutenberg, not Freemius, not scanning someone else’s site. Every tool on this page reads from public WordPress.org endpoints: the plugin information API, the serve-happy PHP check, the core version-check feed, or the daily download stats endpoint. Nothing here reaches into your database, wp-admin, or file system.

SiteTools (Gutenberg / plugin product) lives on tools.town/wordpress. File modes after a migration: Chmod Calculator and Fix WordPress file permissions.

How the cluster is built

Every lookup goes through a server-side proxy so your browser is never blocked by WordPress.org CORS headers. The proxy caches responses using the Cloudflare Cache API:

• Plugin info — 12 hours. The directory rarely changes mid-day; an aggressive TTL would serve stale data on the day of a release, so 12 hours is the balance.
• Download stats — 6 hours. The daily series updates once a day on wp.org, so sub-day staleness is fine.
• Core version-check and serve-happy — 24 hours. WordPress.org releases are announced in advance; a day-old cache is accurate enough.
• Salts — never cached. Each click hits https://api.wordpress.org/secret-key/1.1/salt/ live because reusing a cached salt set would defeat the security purpose.

IP rate limiting is applied in the proxy: roughly 30 lookups per hour per IP to stay a responsible neighbour of api.wordpress.org. If you need more headroom, use a key via the Tools.town API.

What we refuse to invent

WordPress.org data is both abundant and easy to misread. Here is what this cluster never does:

• Active installs are buckets, not counts. WordPress.org publishes 10,000+, 1+ million, 5+ million — not a live subscriber count. We display exactly that bucket. We never print “+4.8% active installs” because that number does not exist in any public endpoint.
• Downloads are not installs. The 7-day and 30-day charts count zip downloads from the update server. A single site running auto-updates counts once per release. A new installation counts once. Neither tells you how many sites have the plugin active right now.
• Version zips are not a dated changelog. The versions map maps version strings to zip URLs. There are no dates on those entries. We list the files; we do not invent timestamps.
• “Potentially abandoned” is a label, not a verdict. An old listing plus a small install bucket earns that label. A plugin with a million installs that has not been touched in 18 months gets “low activity” — because an author with a million users is unlikely to have genuinely abandoned their work. Neither label is a security assessment.
• We do not scan URLs you give us. The only URL we accept is a WordPress.org directory slug or a wordpress.org/plugins/{slug}/ link. We do not hit /wp-json on arbitrary domains.

The five plugin jobs

1. Lookup and score

The Plugin Analyzer is the entry point for everything. Paste a slug or a directory URL, read the result, then switch between Overview, Health, Activity, Zips, Changelog, and Downloads tabs without a second request — all tabs share one cached payload fetched on submit.

The Overview tab shows the basic listing facts: author name, required WordPress, required PHP, tested-up-to, support thread counts, and the active install bucket. The Health tab renders the Tools.town 100-point score with its five component slices. The Activity tab shows the abandoned/activity label with the reasoning (last-updated date and install bucket). The Zips tab lists every entry in the versions map. The Changelog tab strips HTML from the directory changelog field. The Downloads tab renders a 30-day daily sparkline.

2. Bulk compare

The Comparison tool accepts two or three slugs. It fetches them in parallel and lines them up on health score, last updated, install bucket, tested-up-to, and active install bucket. Use it before a SEO plugin migration, a forms plugin switch, or any moment when you have narrowed to two candidates and want the directory facts side by side in one view. Scroll down to compare changelogs and download trends with one click per plugin.

3. Slug discovery

When you only have a marketing name, the Slug Finder searches the directory by keyword and returns a table of matches sorted by active installs. Copy the slug, then run the Analyzer. The Author Analyzer does the same for a developer profile — list everything a particular author has shipped, sorted by any column. Useful for agency due-diligence before buying a product whose author also has four abandoned plugins.

4. Zip and download ops

The Download URL tool returns the current zip URL and the full versioned zip list from the versions map. Useful in CI pipelines that mirror plugins to an internal repository, or in staging provisioning scripts that need a direct download link for a specific version.

The Download Stats tool shows the 30-day daily series with a 7-day vs prior-7-day comparison. Use it for post-launch monitoring (is the plugin being picked up?), for making the case that a plugin is still active even if the listing date looks old, or for basic competitive research across a few slugs.

5. Core, PHP, and salts

These three tools work at the WordPress installation level, not the plugin level:

• Core version-check — current WordPress.org offer with PHP and MySQL minimums, plus a verdict on whether any version you type is current or behind.
• PHP version checker — WordPress.org serve-happy for your hosting PHP version. Returns is_acceptable, is_supported, is_secure, and the recommended/minimum PHP versions.
• Salt generator — live AUTH_KEY and seven friends, never cached, formatted as define() constants, ready to paste into wp-config.php.

WordPress.org data vs what you really want to know

This table is worth reading once, because it is the source of most confusion when people first use these tools:

What we refuse to build

A few things that seem natural here but are explicitly out of scope:

• Plugin detector — “scan my site and tell me what plugins it runs” — requires hitting /wp-json or reading HTML fingerprints. We do not build site scanners.
• Auto-nightly directory crawl — too expensive and a poor neighbour to api.wordpress.org at the scale we would need.
• Plugin vulnerability feed — this requires a CVE mapping table we do not maintain. Use WPScan, Wordfence Intel, or Patchstack for that.
• Fake trend lines — “+3.2% growth in active installs this week” — that data does not exist in any public WordPress.org endpoint.

Start with a use-case

• Vet a plugin before install
• See if a plugin looks abandoned
• Compare two plugins before switching
• Check PHP before a core update
• Rotate wp-config salts after a hack
• Find a plugin slug for WP-CLI

Guides: how the analyzer works, health score, PHP checker, salts.