WordPress Plugin Update Impact & Support Regression Intelligence

Analyze one or more WordPress.org plugin slugs or URLs and receive one structured report per canonical plugin. The Actor resolves the latest public release, compares bounded feedback before and after that release, and identifies regression, compatibility, recurring-bug, improvement, rating, sentiment, and evidence signals.

What it collects

• Public Plugin Information API metadata and a conservative plugin-page fallback for the release boundary.
• Public WordPress.org reviews.
• Public support topics and bounded replies.

Reviews and support are optional and isolated: if one source fails, the report keeps the other source and marks coverage, errors, confidence, and limitations explicitly. If release metadata cannot be resolved unambiguously, the plugin receives a failed report rather than a fabricated comparison.

Input

The canonical default is sample-input.json:

{
  "plugins": ["contact-form-7"],
  "windowDaysBefore": 30,
  "windowDaysAfter": 30,
  "maxReviews": 30,
  "maxSupportTopics": 30,
  "includeReviews": true,
  "includeSupport": true
}

plugins accepts one to five slugs or full WordPress.org plugin URLs. Inputs are normalized and deduplicated in first-occurrence order. Windows are UTC half-open ranges: the exact release timestamp belongs to the after window. Collection is bounded to 200 reviews, 200 support topics, 10 replies per topic, and 100 support topic-detail requests per plugin (30 by default).

Output

Each Dataset record is identified by pluginSlug and contains latestRelease, comparisonWindows, sourceCoverage, unavailable-or-valued ratingDelta and sentimentDelta, four finding arrays, bounded representative evidence, confidence, limitations, errors, and generatedAt. Findings only reference evidence in the same record. The analysis is observational and does not claim that a release caused an issue.

Runtime and privacy

The default path requires no login, API key, proxy, or external LLM key. Requests use bounded timeouts, retries, backoff, response-size limits, pagination, and a descriptive user agent. Output excludes raw HTML, credentials, cookies, full profiles, and unbounded text. Reports are written incrementally in stable input order, and RUN_STATS is stored in the default key-value store.

Local checks

npm ci --offline
npm test
npm run build
npm run lint
npm run format:check
npm run validate:schema
apify run --purge --input-file sample-input.json

The deterministic suite uses sanitized fixtures and local transports. The canonical local and Cloud smoke checks have been run against public WordPress.org; optional-source failures remain isolated in the report. The deployed Actor uses the platform-valid identifier wordpress-plugin-update-impact-support-regression while retaining this full product title in the documentation. Publication and pricing changes are not automatic.

Shared analysis foundation

The Actor reuses the vendored @project/feedback-analysis-core exports validateNormalizedFeedback, aggregateFeedback, clusterFeedback, compareFeedbackWindows, createClusterId, and normalizeConfidence. WordPress-specific code is limited to source adapters, taxonomy, deterministic sentiment, release windows, orchestration, and output projection. See docs/phase-1-report.md, docs/phase-2-report.md, docs/phase-3-report.md, and docs/phase-4-report.md.

Measured deterministic checks and deferred live measurements are tracked in BENCHMARK_NOTES.md.