72 lines
3.0 KiB
Markdown
72 lines
3.0 KiB
Markdown
# WordPress Public Workspace Conventions
|
|
|
|
This workspace prepares Christ IT WordPress plugins and themes for public distribution. Git is the development source of truth. WordPress.org SVN, public plugin directories, and installed production copies are release targets, not the working source.
|
|
|
|
## Scope
|
|
|
|
- Public plugin source lives under `plugins/<slug>/`.
|
|
- Shared local release and smoke-test tooling lives under `tools/`.
|
|
- Do not remove or replace the matching internal GracePress package until the public package is accepted, published, installed on the target production site, and verified on the public update path.
|
|
|
|
## Version Discipline
|
|
|
|
Every meaningful public plugin change must update, in the same commit:
|
|
|
|
- the plugin header `Version`;
|
|
- any runtime version constant;
|
|
- `readme.txt` `Stable tag`;
|
|
- the plugin `CHANGELOG.md`;
|
|
- the `readme.txt` changelog when the change is public-facing.
|
|
|
|
Use one version number per bounded pass. Do not keep piling unrelated verification fixes into the same version after the pass has been declared complete.
|
|
|
|
## Changelog Discipline
|
|
|
|
The standalone plugin changelog is the durable engineering record. The WordPress.org readme changelog is the public release summary.
|
|
|
|
For migrated GracePress plugins:
|
|
|
|
- keep enough prior internal history to explain origin and compatibility;
|
|
- clearly mark the public fork version;
|
|
- remove or supersede public claims that no longer match the current package;
|
|
- record test-lab evidence in Git when a version is considered a release candidate.
|
|
|
|
## Bounded Verification
|
|
|
|
Use this default verification loop unless the user explicitly asks for more:
|
|
|
|
1. Run PHP syntax checks for touched PHP files.
|
|
2. Run the configured Docker smoke matrix once.
|
|
3. Save smoke results under `tools/testlab/results/`.
|
|
4. Review failures only far enough to identify the next code or test fix.
|
|
5. After a passing matrix, commit and stop.
|
|
|
|
Do not start recursive verification such as verifying the verifier, expanding the matrix, or repeatedly re-running browser checks unless a named release gate fails or the user explicitly asks for a broader pass.
|
|
|
|
## Test Lab
|
|
|
|
The local Docker test lab belongs in `tools/testlab/` so scripts, environment definitions, and result JSON stay tied to Git history.
|
|
|
|
Smoke tests should prove the contract, not exhaustively explore the UI:
|
|
|
|
- plugin activates;
|
|
- supported WordPress/PHP versions boot;
|
|
- expected plugin version is active;
|
|
- required tables are created;
|
|
- supported local Bible texts import;
|
|
- representative REST lookups pass;
|
|
- a browser-facing test page can be seeded for manual review.
|
|
|
|
Manual browser review is a separate, explicitly requested step.
|
|
|
|
## Release Boundary
|
|
|
|
A "build/test/commit and stop" request means:
|
|
|
|
- complete the named edits;
|
|
- run the bounded verification loop once;
|
|
- commit the coherent checkpoint if verification passes;
|
|
- report what passed and stop.
|
|
|
|
Do not publish to WordPress.org, production sites, or public update channels unless the user explicitly asks for that release step.
|