fix(playground): self-track stable release + restore main-tracking demo - #76
Conversation
Follow-up to #75, which switched the blueprints off git:directory but left two issues: - blueprint-stable.json was pinned to /releases/download/v1.3.0/, so it needed a manual bump every release. Point it at /releases/latest/download/ instead (through the CORS proxy) so it always tracks the newest release with no edit. - blueprint-hosted.json — the "main / bleeding-edge" demo — was pointed at the latest *release*, so it no longer tracked main and duplicated the stable demo. Restore git:directory ref=main (the correct main-tracker for this no-build plugin), making the two demos genuinely distinct again. Also fixes the now-stale README/playground-README text (still described git:directory + a release-tag ref bump) and drops the dead blueprint ref-bump from bin/prep-release.sh (blueprint-stable no longer has a "ref" to bump). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4fad9b8578
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| "pluginData": { | ||
| "resource": "url", | ||
| "url": "https://wordpress-playground-cors-proxy.net/?https://github.com/dknauss/Maestro/releases/latest/download/maestro-menu-editor.zip" | ||
| "resource": "git:directory", |
There was a problem hiding this comment.
This restores the git:directory install path for the public Development build link even though the immediately preceding fix commit (2f8fa9d) removed this exact approach because the live browser Playground fails it with Fw.createHash is not a function. In that browser context, clicking the “main” demo will stop at plugin installation before Maestro or the test users are available; if main tracking is required, it needs a browser-compatible ZIP/artifact URL rather than reverting to git:directory.
Useful? React with 👍 / 👎.
1 participant
Follow-up to #75 (which superseded #73, now closed). #75 correctly moved the blueprints off
git:directory, but left two problems this PR fixes.1. Stable demo wasn't self-tracking
blueprint-stable.jsonwas pinned to/releases/download/v1.3.0/…, so it needs a manual bump every release. Switched to/releases/latest/download/maestro-menu-editor.zip(via the CORS proxy) — that path always resolves to the newest release asset, so the stable demo tracks the current release with zero per-release edits.2. The "main" demo no longer tracked main
#75 pointed
blueprint-hosted.json— the badge/docs call it "Development build (main)… tracks themainbranch (bleeding edge)" — at/releases/latest/download/too, i.e. the latest release. So it stopped trackingmainand became a duplicate of the stable demo.Restored it to
git:directoryref=main. Maestro is a no-build plugin (runs from committed source), sogit:directory@mainis the correct, legitimate way to trackmain— and it makes the two demos genuinely distinct again:blueprint-stable.json/releases/latest/download/(CORS proxy)blueprint-hosted.jsongit:directory@mainblueprint.json(local)3. Doc + script cleanup
README.md/playground/README.mdstill describedgit:directoryfor the stable demo and a "release-tagrefbump" rule — both stale. Rewritten to match reality.bin/prep-release.shdropped the dead blueprintrefbump (stable no longer has a"ref"; nothing to bump now that it self-tracks).Verification
bin/prep-release.shpassesbash -n, no danglingBLUEPRINT_STABLErefs.…/releases/latest/download/maestro-menu-editor.zipreturns 200.🤖 Generated with Claude Code