Refresh documentation and community health files#38
Merged
Conversation
The readme headers that WordPress.org reads were stale: the plugin requires PHP 8.4 and WordPress 6.9, and is tested up to 7.0. Alongside that, fix the 'compose require' typo, the dead Codex link (its content now lives in the HelpHub manage-plugins article), the mixed numbered and bulleted installation lists, and the GitHub Updater reference, since that project is now Git Updater. Fill the empty Tags header, add a CI badge, and extend the copyright to 2026. New Development and FAQ sections document the wp-env setup, the Composer scripts, and the two deliberate oddities consumers ask about: the PHPUnit 9.6 cap (the WordPress core test framework supports nothing newer) and the absent composer.lock (consumers should resolve their own dependencies).
The only release entry was a 1.0.0 placeholder with an unknown date, contradicting the 0.1.0 version used throughout the codebase, and no tags exist yet. Move everything under Unreleased until a first release is actually cut, add the standard Keep a Changelog reference line, fix the compare link which was missing its /compare/ path segment, and use https for the Semantic Versioning link.
Replace the version 1.4 text with the official 2.1 release, which adds enforcement guidelines and broader protected characteristics, and uses https links throughout. The existing contact email is retained.
Both documents were unfinished, with literal '...' placeholders, a garbled sentence, and a 'Checking You Changes' typo. The contributing guide also pointed at a nonexistent develop branch, a 'composer phpcs' script that was never defined, and bare phpunit/infection commands that no longer match how the test suites run. Rewrite both around the real Composer scripts and the wp-env workflow, link the Code of Conduct and the README's Development section, state that issues are for bug reports and feature requests, and replace the Twitter mention with WordPress Slack.
Point reporters at GitHub's private vulnerability reporting, which is enabled on this repository, so security issues are not disclosed through the public issue tracker. Only the latest release is supported.
The two legacy markdown templates were inconsistently named (bug_report.md vs feature-request.md) and applied no labels, so issues arrived untriaged. Replace them with GitHub issue forms that require the essentials up front, including WordPress, PHP and plugin versions for bugs, and label new issues as bug or enhancement automatically. A config.yml disables blank issues and points general questions at the support document.
The [CONTRIBUTING] reference had no link definition, so it rendered as literal bracketed text in every pull request. Make it a real link, and replace the vague code style checklist item with the actual commands contributors are expected to run: composer test and composer cs.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The project's documentation had drifted a long way from the code it describes. The readme headers that WordPress.org reads still claimed support for WordPress 6.6 and PHP 8.2, the contributing guide pointed at a
developbranch and Composer scripts that have never existed, and several files shipped with literal...placeholders left over from the original scaffold.This refresh brings the README headers up to the actual support window (WordPress 6.9–7.0, PHP 8.4), fixes the broken Codex link, the
compose requiretypo and the mixed list markup, renames GitHub Updater to its current Git Updater identity, and adds a CI badge plus new Development and FAQ sections covering the wp-env setup, the Composer scripts, and why PHPUnit stays capped at 9.6 andcomposer.lockis uncommitted. The README passes the WordPress.org readme validator, with the only error being the restricted word "plugin" in the deliberately placeholder name.Around it, the changelog folds its contradictory 1.0.0 placeholder entry into Unreleased (no tags exist yet) and gains the Keep a Changelog reference and a corrected compare link; the Code of Conduct moves from Contributor Covenant 1.4 to the official 2.1 text, keeping the existing contact address; the contributing and support guides are rewritten around the real workflow; a security policy directs reporters to GitHub's private vulnerability reporting; the legacy markdown issue templates become labelled YAML forms with a config that disables blank issues; and the PR template's bare
[CONTRIBUTING]reference becomes a working link with a checklist that names the actual commands.Note: this assumes the Composer script names from #40 (
test:unit,test:integration,cs-fix), so it should merge after that PR.