gracepress/wordpress-public-workspace
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update public WordPress workspace working changes

Browse Source 
- GRACEPRESS-PUBLIC-PLUGIN-STANDARDS.md
- PUBLIC-PLUGIN-WORKFLOW.md
- WORDPRESS-ORG-REQUIREMENTS.md
- WORDPRESS-PUBLIC-CONVENTIONS.md
- design/dark-mode-admin-v1.1.0-spec.md
- plugins/bible-reference-tooltips/CHANGELOG.md
- plugins/bible-reference-tooltips/bible-reference-tooltips.php
- plugins/bible-reference-tooltips/readme.txt
This commit is contained in:
Jason Eugene Garrison
2026-10-02 15:57:02 -05:00
parent f2bc638509
commit 331edafb60
11 changed files with 2069 additions and 1110 deletions
Download Patch File Download Diff File Expand all files Collapse all files
PUBLIC-PLUGIN-WORKFLOW.md
+120
View File
@@ -0,0 +1,120 @@
# GracePress WordPress Public Plugin Workflow
This is the reusable path for converting an internal GracePress plugin into an independent public WordPress.org plugin. The current pilot is Dark Mode by GracePress.
## Gate 0: Establish the standards
Inputs:
- WORDPRESS-ORG-REQUIREMENTS.md
- GRACEPRESS-PUBLIC-PLUGIN-STANDARDS.md
- Current official WordPress.org documentation
Actions:
1. Reconcile the requirements against current official sources.
2. Review GracePress visual, theological, ownership, and release conventions.
3. Mark items REQUIRED, REVIEW GATE, QUALITY GATE, or CONDITIONAL.
4. Obtain agreement on any disputed convention before changing plugin code.
Output: approved reusable checklists.
## Phase 1: Baseline the independent plugin
1. Inventory source files, hooks, settings, assets, external requests, data storage, and release metadata.
2. Install the exact current ZIP in the isolated Tailnet-only WordPress lab.
3. Capture the current admin page, front-end behavior, settings model, and known limitations.
4. Create a checklist status report with Pass, Fail, Not Applicable, and Not Yet Tested states.
Output: a factual baseline, not a redesign.
## Phase 2: Competitor and user-value research
1. Select a small comparison set, beginning with Vampire Dark Mode and two or three maintained alternatives.
2. Use current public descriptions, screenshots, documentation, and hands-on installs where licensing and the lab allow.
3. Build a feature matrix covering setup, scheduling, system preference, controls, exclusions, media handling, accessibility, performance, compatibility, and admin UX.
4. Classify ideas as Adopt, Adapt, Reject, or Investigate.
5. Do not copy proprietary code, text, art, or distinctive trade dress.
Output: prioritized feature brief with rationale and estimated complexity.
## Phase 3: Admin UI information architecture
1. Map settings into user goals rather than implementation order.
2. Design the hero, status summary, primary settings, appearance preview, placement controls, advanced exclusions, help, diagnostics, and GracePress footer.
3. Define desktop, narrow-screen, keyboard, focus, reduced-motion, saved-state, and error-state behavior.
4. Review the proposed structure before implementation.
Output: approved UI specification.
## Phase 4: Bounded implementation
1. Identify exact files to change.
2. Create timestamped rollback copies.
3. Implement the approved UI and prioritized low-risk features in coherent versions.
4. Keep public code independent of the internal plugin and preserve intentional migration compatibility.
5. Update versions and both changelogs with each bounded release candidate.
Output: one coherent candidate version.
## Phase 5: Security and known-bug review
1. Perform static review against WP-18 through WP-35 and the Dark Mode additions.
2. Search current vulnerability databases and official issue sources for the plugins dependencies and relevant patterns.
3. Exercise malicious and malformed settings, capability boundaries, nonces, escaping, selector/custom-CSS handling, and front-end persistence.
4. Classify findings by severity and repair High/Critical findings before any release decision.
5. Record residual risks and non-applicable vulnerability classes.
Output: security and bug report plus repaired candidate.
## Phase 6: WordPress.org compliance pass
1. Run Plugin Check against the exact candidate.
2. Run the official readme validator.
3. Run PHP syntax and WordPress Coding Standards checks.
4. Reconcile headers, versions, stable tag, text domain, privacy, assets, package contents, and source availability.
5. Complete every REQUIRED and REVIEW GATE item or document why submission must stop.
Output: WordPress.org readiness report.
## Phase 7: Test-lab acceptance
1. Install the exact built ZIP on a clean lab site.
2. Exercise install, activation, configuration, normal use, upgrade, deactivation, reactivation, and uninstall.
3. Test declared minimum and current WordPress/PHP combinations.
4. Test representative themes, editor modes, mobile widths, keyboard navigation, reduced motion, system preference, schedule boundaries, and media exclusions.
5. Run with WP_DEBUG and SCRIPT_DEBUG and capture bounded evidence once.
Output: signed-off release-candidate evidence.
## Phase 8: Listing and release materials
1. Finalize readme copy, FAQ, privacy statement, screenshots, icons, banners, and support route.
2. Confirm every claim against the tested package.
3. Build once through scripts/build and inspect the exact ZIP and dist metadata.
4. Update the private catalog only when explicitly requested.
Output: submission-ready ZIP and WordPress.org assets.
## Phase 9: Explicit release decision
Separate approvals are required for:
1. Shipping to the GracePress public-package catalog.
2. Submitting the ZIP for WordPress.org review.
3. Responding to reviewer changes and resubmitting.
4. Publishing to WordPress.org SVN after approval.
5. Replacing or retiring the internal Dark Mode plugin on any production site.
Output: an auditable release with no accidental production migration.
## Immediate Dark Mode sequence
1. Review and approve the two checklists.
2. Baseline the installed 1.0.0 candidate and capture its existing admin UI.
3. Research Vampire Dark Mode and selected alternatives.
4. Produce the feature matrix and proposed admin UI structure.
5. Obtain UI/feature approval.
6. Implement one bounded candidate.
7. Run security, compliance, and lab gates.
8. Stop for the explicit ship/submission decision.