Repository navigation
PublishRank 2.9.69
PublishRank 2.9.69 — review corrections and release validation
Purpose
This maintenance release follows the automated WordPress.org review of 2.9.68. It focuses on the reported translation, escaping, placeholder-order, and distribution-package findings. It does not change the plugin’s feature set or replace a live WordPress installation test.
Corrections
- Added translator notes for dynamic values throughout the affected admin, SEO, sitemap, and indexing messages. Replaced the conditional Search Console translation call with two literal gettext strings.
- Ordered the multiple substitutions in the weekly audit subject, integrity warning, and sitemap-audit messages, and clarified each placeholder’s meaning.
- Escaped the Search Console connection label, schema labels, verification-form action URLs, verification token attributes, author names, and generated status-pill markup at their output contexts. Sanitized the WordPress nonce-field HTML in the image-optimizer form; the front-end provenance markup remains a fixed, internally escaped HTML fragment.
- Added
tools/build_plugin_zip.py. It derives the package version from the plugin header and creates onepublishrank/top-level directory while omitting dotfiles,.git,.github, test fixtures, Composer development files, tools,vendor/, and olddist/archives. Documentation and runtime assets remain in the package. - Removed the unused
brain/context ^3.0development requirement (no project reference uses it) and configured the PHPCS standards installer explicitly. The repository’s standalone PHP checks are not PHPUnit tests; Composer now exposes the actual smoke test ascomposer smokerather than pointing at a missing PHPUnit configuration file.
Validation performed
- PHP parser lint over production and test PHP sources, plus the plugin bootstrap and uninstall script.
- WordPress-Core internationalization and output-escaping sniffs over production PHP: 0 errors and 0 warnings after the fixes.
- Targeted standalone checks passed for smoke, site verification, sitemap audit, sitemap limits/sharding, JSON-LD escaping, and several other feature modules.
- The 2.9.69 release ZIP contains 222 files in a single
publishrank/root. Archive checks confirmed the absence of hidden files,.git,.github, tests, tools, Composer metadata, and the developmentvendor/tree. Bundled frontend libraries and their licenses remain included.
Known gaps — not represented as passing checks
The repository has historical regression scripts whose assertions no longer describe the current 2.9.68/2.9.69 source. Running every tests/*.php script currently fails in these seven files:
tests/analytics.php— expects the Search Console analytics page and implementation to be removed, a 30-day cap, and old help copy; the current plugin has a Search Console page and its own current reporting behavior.tests/dashboard_redirects.php— pins version 2.9.48 and previous dashboard artwork/copy.tests/dashboard_schema_sitemap_fixes.php— asserts previous welcome-heading styling and revoked schema-panel behavior.tests/liveblog_schema.php— contains a legacy schema-value expectation that differs from the current schema allow-list.tests/llms_txt.php— asserts retired source-attribution controls and opt-in behavior.tests/release_2_9_45.php— hard-codes an old release version.tests/schema_editor_coverage.php— expects retired schema options and old dashboard editor links.
These failures predate the present security/translation corrections; their stale assertions should be reviewed and refreshed in a separate test-maintenance pass. Test files are excluded from the installable release archive, but remain in the source repository. Consequently this release does not claim that the entire historical test directory passes.
The broad repository command composer phpcs is also still non-clean: it reports 8,191 errors and 2,013 warnings across 134 files under the full WordPress-Core/WordPress-Extra ruleset. The scanner-focused i18n and output-escaping checks above are clean; full-project coding-standard remediation remains open. A before-patch full-ruleset baseline was not captured, so this report does not attribute those aggregate findings to particular commits.
No clean WordPress staging site or browser session was available for end-to-end interaction testing. The earlier reports about editor buttons and card movement therefore still require a manual installation check on the supported WordPress/editor/theme/plugin combinations. Static source checks cannot prove that every screen button works in a live dashboard.