docs: add versioned plugin advisories for issue 1396 - #3387
Merged
Merged
Conversation
Contributor
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository: lightspeedwp/.github/.coderabbit.yml Review profile: CHILL Plan: Advanced Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
📝 WalkthroughWalkthroughThe change adds a plugin register and versioned advisories. They define plugin statuses, native replacement guidance, Gravity Forms usage rules, plugin retention guidance, and hosting-stack advisories. ChangesPlugin approval and advisories
Priority: ➖ Normal Estimated code review effort: 2 (Simple) | ~10 minutes Change: Other Merge Risk: 🔵 Low · up to This PR adds guidance documents only. Before or shortly after merging, tighten four areas:
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Contributor
📋 Changelog Quality Validation
Status✅ Validation PASSED - No new failures introduced by this PR. No action required. |
Contributor
PR Template RoutingBranch Type: This PR was automatically routed based on the branch naming strategy. |
Contributor
|
This pull request does not currently match the merge queue conditions, so it cannot be queued from here. The box comes back if it matches again. |
Contributor
Author
|
Heads-up: this PR body does not include the sections from its routed template (docs/ → pr_feature.md). Missing: |
krugazul
requested changes
Sep 21, 2026
krugazul
left a comment
krugazul
left a comment
Contributor
There was a problem hiding this comment.
@eleshar we will no longer be using the starter plugin and theme. We are generating our plugins and themes from the following 2 tools.
https://github.com/lightspeedwp/block-plugin-scaffold
https://github.com/lightspeedwp/block-theme-scaffold
github-actions
Bot
added
priority:normal
status:needs-review
meta:needs-changelog
and removed
priority:important
area:documentation
type:documentation
labels
Contributor
|
No description provided. |
Contributor
Author
Correction: I was wrong about this PR being 2,587 commits behindIn a triage note I reported this branch as "2,587 commits behind, cheapest path is a fresh branch off develop". That was wrong on the number that matters, and it pointed at the wrong remedy. Measured properly: I had quoted the second figure as if it were the first. 2,587 is branch-only ancestry — noise from a long-lived branch whose merge base is No fresh branch and no rebase is needed. I tested it in a throwaway worktree and aborted without pushing: And none of this PR's content is superseded — the two documents it adds do not exist on
So the real delta is 3 files and it still stands. Proposal: a plain Say the word and I will do that. Not opening anything new, and not pushing until you confirm. |
…ries-1396 Brings the branch 7 commits up to date. `git merge` reported no conflicts and none of this PR's content needed adjusting: the two documents it adds, docs/PLUGIN_ADVISORIES.md and docs/PLUGIN_REGISTER.md, still do not exist on develop. One defect the merge itself introduced and this commit fixes: the CHANGELOG.md frontmatter was concatenated, leaving six keys defined twice -- once from each side. YAML resolves duplicates last-wins, so this branch's `last_updated: "2026-09-25"` was being silently discarded in favour of develop's `'2026-09-15'`, which is the backward move the review flagged. The duplicated double-quoted set is dropped, develop's single-quoted block is kept to minimise divergence, and the date is set to 2026-09-27, when this change lands. Verified after the fix: no duplicate keys remain in the frontmatter, and `npm run validate:changelog` passes.
Contributor
Author
The 4 CodeRabbit findings from 2026-09-24 are all already fixed
1. "Do not claim
2. "Implement the promised rate limit in the newsletter sample" (CWE-770) — addressed. The sample has a real throttle: 3. "Define 4. "Make the payment-gateway entry an explicit allowlist" (Major) — addressed.
So: 4 valid findings, 4 already addressed, 0 to apply, 0 to dismiss. There are no open review threads to reply to or resolve — CodeRabbit auto-resolved them when those commits landed. The One defect the merge itself introduced, fixed in
|
Contributor
Author
|
@CodeRabbit full review |
Contributor
|
15 of 18 tasks
This was referenced Sep 27, 2026
Merged
eleshar
added a commit
that referenced
this pull request
Sep 27, 2026
Merged as a commit rather than a rebase, and the branch was fetched immediately beforehand because the automation on it has force-pushed before. This clears the only remaining failure, the rule that requires same-repository pull requests to be current with develop, which was failing because develop had moved on #3387, #3525 and #3605. One conflict, in agents/document-reviewer-agent/AGENT.md, and it is a content-against-footer collision rather than a semantic disagreement: this branch appends a Qodo PR-Agent integration section at the end of the file, while develop appends the standard footer at the same place. Resolved as a union, with the Qodo section kept and develop's footer placed after it, because the footer policy matches the "Have questions?" line only at end of file. The resolved file has exactly one footer line. Verified after the merge: this branch's three qodo-pr-agent suites pass 117/117; audit-specs.sh reports sequential numbering 001 to 019 with no gaps and 19/19 naming compliance; the resolved file carries a single footer; semgrep ran 38 rules over it with 0 findings. CHANGELOG.md merged as a union, going from 408 entries on each side to 409, and the changelog validator reports the same ten failures develop already carries. Seven files repo-wide contain conflict-marker text; all seven are untouched by this merge and already present on develop. CodeRabbit could not review this merge. The organisation quota reads 0 of 3 and resets 2026-10-01, and a full-branch review exceeds the 150-file limit at 1886 files because of the develop merge. The verification above was used in its place.
eleshar
pushed a commit
that referenced
this pull request
Sep 29, 2026
The changelog entry and the pull request body both stated that the Section 1 advisories table had a two-column header while its rows carried four, so CommonMark dropped the Status and Notes columns. That defect is not present in the content merged by #3387. docs/PLUGIN_ADVISORIES.md parses cell by cell as four header cells, four delimiter cells and thirteen four-cell rows, with the header and delimiter counts equal, so no column is ever dropped. The only change this pull request makes to that table is relabelling Caveat as Notes plus re-padding to the compact form used elsewhere in the file. The changelog entry is rewritten to describe what actually changed, and keeps the three real behaviour changes: the newsletter form surviving a failed request, a blocked address being distinguished from a server fault, and atomic rate-limit counting. FEEDBACK_RESPONSE.md records the withdrawn claim as item 17 with the evidence, and the summary no longer asserts that nothing was rejected. No shipped behaviour moves. The change is documentation only, and no test asserted the false claim, so none needed updating; the table shape was verified directly instead.
eleshar
added a commit
that referenced
this pull request
Sep 29, 2026
…te and renumber residue (#3604) * Correct the spec 018 self-references and the advisories table header Two defects in the content that reached develop, found by auditing the merged tree rather than the pull request descriptions. The 016 to 018 renumber moved the directory, updated CATALOG.md and rewrote the path references, but left six self-references still naming 016. A grep for "016-claude-cloud-environment" could not find these because they never carried the slug: - tasks.md frontmatter: "Task list for 016 Standardised Claude Code Cloud Environment" - tasks.md T039: run /speckit-analyze "for 016" - spec.md: "How should spec 016 handle this?" - spec.md: "A workflow runs the 016 Jest suites" - spec.md: "contract tests and the spec 016 documentation" - data-model.md: the branch-cleanup rule marked "New (016)" FR-016 and the "16/16 questions" counts in plan.md are requirement and count references, not spec numbers, and are deliberately untouched. The Section 1 table in docs/PLUGIN_ADVISORIES.md was also malformed. Its header and separator declared two columns while all thirteen body rows carry four, so under CommonMark the extra cells are dropped and the status and notes columns never rendered. That silently hid exactly the content three of the four CodeRabbit findings were about, including the filemtime freshness caveat. The second header cell held a link to block-plugin-scaffold, which is a value rather than a column name, and the generator repositories are already tabulated above the table. The header is now Plugin, Native replacement, Status, Notes, with a matching four-column separator. Verified: the spec docs suite passes 37/37, and audit-specs.sh reports "Sequential numbering verified: 001 to 018 with no gaps" with 18/18 naming compliance. semgrep ran 38 rules over 11 files with 0 findings. CodeRabbit review of these changes: 0 findings. * Address the review findings on the merged advisory and spec content A full CodeRabbit pass over the two merge commits reported four issues, and fixing them surfaced four more on the fixes themselves. All are real. The newsletter example destroyed the form on failure. Its error branch said "Please try again later" while replacing the form with a paragraph, so the address was gone and retry was impossible. The form is now replaced only when the request succeeds; on failure the message goes into an in-place alert region so the address survives. A rejected fetch is caught too, and reports through the same region rather than throwing past it. The rate limiter counted with a get_transient()/set_transient() read-modify-write. Two concurrent submissions could read the same count, both write count + 1, and the limit was silently bypassed, which is the same weakness as the denial of service finding that was previously closed against this sample. Counting now happens in a single atomic statement and the compared value is carried out of that statement by LAST_INSERT_ID(), so it is this request's own count. Three further corrections: a failed counter read now refuses instead of reporting spare capacity, which would have failed open; the comparison is strictly greater than the maximum, so max of 3 permits three requests rather than two; and the docblock describes both behaviours. FR-020 gated auto-deletion on the age of the branch's tip commit. A branch created moments ago can carry an old tip commit, so a fresh working branch was eligible for deletion inside a day of being created. The gate now uses a branch-age signal such as a first-observed timestamp. The categorisation contract's Condition and Configuration rows, the R6 decision record, the data model's cleanup rule, and the two acceptance scenarios were carrying the same tip-commit basis and are aligned, and the research note records why the original basis was rejected. The branch-cleanup contract also deleted a remote branch with a bare `git push origin --delete` after re-checking it, leaving a window in which a push landing between the check and the delete would be discarded. The checked tip OID is now recorded and passed as an explicit --force-with-lease expectation, and the report-only skip is unchanged. The FR-020 test asserted the old "at least 24 hours old" wording, so it is updated to the corrected phrasing and extended with two assertions that pin the branch-age rule, which the previous test did not cover. Verified: the spec docs suite passes 37/37; audit-specs.sh reports sequential numbering 001 to 018 with no gaps and 18/18 naming compliance; semgrep ran 38 rules over 11 files with 0 findings. CodeRabbit review of the merged diff and of each fix: 10 findings, all addressed above. * Record the corrected branch-age basis and add a changelog entry Two adjustments before this branch is proposed for merge. Spec 009's deletion-candidates.schema.json contracts age_days as "Days since last commit", and the shipped audit derives it from lastCommitDate, so the tip-commit basis behind FR-020 is a deliberate 009 decision rather than an oversight introduced here. That makes the corrected gate an amendment to 009's contract for auto-approved agent branches, not a clarification, and it needs state 009 does not yet keep. Both the FR-020 requirement and the branch-cleanup contract's Configuration row now say so explicitly: the stricter gate is scoped to auto-approved agent branches, the branch-age signal's storage mechanism is recorded as an open decision, and the 009 relationship is named rather than quietly redefined. No behaviour is claimed as settled that is not. Also adds the changelog entry this work needs under Unreleased > Fixed, kept inside the 250-character entry limit the validator enforces, and re-checked against it: 145 entries with 10 failures, the same 10 develop already carries, so nothing new is introduced. * Address three CodeRabbit findings from the pull request review These came from the pull request review rather than the local uncommitted pass, which is why the previous report called the branch clean while the review state still had them open. All three were real. FR-020 required a branch-age signal that nothing provides. Spec 018's data model states there is no persistent storage, and spec 009 supplies only age_days from last_commit_date, so the 24-hour auto-delete gate had no usable signal and the requirement was unsatisfiable as written. The auto-approved deletion is now explicitly deferred: until the storage and retention mechanism for a branch-age signal is decided and built, no claude/* branch qualifies for automatic deletion and every candidate follows spec 009's categorisation and draft-PR approval. Deferring is the safe direction, because spec 009's tip-commit basis would otherwise let a branch created moments ago be deleted inside a day of being created. FR-020, the contract's Configuration row and auto-delete step, the R6 decision record and Acceptance Scenario 5 all now say so. Acceptance Scenario 5 required "more than 24 hours" where FR-020 says "at least", so a branch observed for exactly 24 hours satisfied the requirement and failed the scenario. That inconsistency was introduced when the scenario was rewritten to use the branch-age basis. The scenario now matches FR-020. The newsletter handler gave one message for every failure, including the 429 the route returns when the rate limit is hit. Telling someone to check an address that is already valid, while they are blocked, only invites a retry that will be refused again. The handler now separates a rate-limited address, a rejected address, and a provider-side failure. Two test lookups followed the contract's auto-delete row, which is now labelled deferred rather than new, so they were updated to match. Verified: the spec docs suite passes 37/37; audit-specs.sh reports sequential numbering 001 to 018 with no gaps and 18/18 naming compliance; the changelog validator reports the same failure count as develop, with the entry reworded to 250 characters to describe the deferral accurately; semgrep ran 119 rules over 12 files with 0 findings. CodeRabbit review of these changes: 2 further findings raised and addressed, final pass clean. * Track AI review feedback and correct the lifecycle diagram Two gaps found by reviewing the pull request through Linear's diff review platform rather than only through GitHub's review-thread API. A bot comment thread and an outside-diff CodeRabbit finding were both invisible to a reviewThreads query, so the earlier report of a clean pass was based on the wrong surface. The lifecycle diagram in data-model.md still read "tip >=24 h old" on the edge from an empty remote branch to deleted, which contradicted FR-020, the contract and the acceptance scenarios in the same specification. The edge now states the branch-age basis and that auto-approved deletion is deferred, without naming a storage mechanism. The cleanup rule above it was also still written as live behaviour, so it now records the same deferral. FEEDBACK_RESPONSE.md held the record from #3500, which merged on 2026-09-26, so the validation for this pull request was reading someone else's response. It now records all fifteen items with a status each: fourteen addressed and one deferred, the branch-age decision. Three entries needed correcting once written. They described specification changes as though they were shipped fixes. The shipped categoriser still derives age from lastCommitDate at scripts/cleanup-branches.js:317 and the shipped delete at :342 is unchanged; what changed is the specification text, and automatic deletion is deferred so neither path is reached. Entries 1, 2 and 13 now say so explicitly rather than implying the implementation was fixed. The pull request body gains Refs #1396. The repository's validation requires a Resolves, Closes, Fixes or Refs issue reference; Refs satisfies it without closing anything, which matters because this pull request deliberately closes none of the three issues it relates to. Verified by calling the validator directly: passed true with no outstanding issues. The file is a single shared path at the repository root, so a second pull request needing a response overwrites the first. That is recorded in the file itself; a per-pull-request path would remove the collision. Verified: the spec docs suite passes 37/37; audit-specs.sh reports sequential numbering 001 to 018 with no gaps and 18/18 naming compliance; semgrep ran 38 rules over 11 files with 0 findings; CodeRabbit review of these changes raised one finding, the specification-versus-implementation framing above, which is addressed, and the final pass is clean. * Bound the rate-limit table and correct the deferred lifecycle edge Two findings from the CodeRabbit full review that completed against the previous head, neither of which was visible before because the review had not run. The lifecycle edge still read "no open PR, observed >=24 h" as the condition for reaching spec 009 categorisation. That is wrong while auto-approved deletion is deferred: the 24-hour threshold belongs to the deferred auto-approval rule, and every empty branch reaches 009 categorisation regardless of age. Removing the threshold from the transition is the correction; the rule above it keeps it. The rate-limit table grew by a row per distinct address indefinitely. The counter reset an expired row in place, so rows were never removed, and the per-IP limit only slowed the growth rather than bounding it: every new address created a fresh key. An unauthenticated caller could therefore grow the table without limit, which is CWE-400. Expired rows are now deleted before each insert, so the table holds at most one window of counters; the in-place reset branch is gone now that the purge handles expiry; and the table carries an index on window_started so the purge is indexed rather than a full scan. The expiry comparison is inclusive, so a row whose window closes exactly now is purged. FEEDBACK_RESPONSE.md gains both items, taking the total to sixteen addressed and one deferred. Verified: the spec docs suite passes 37/37; the ai-feedback validator returns passed true with no outstanding issues when called directly; semgrep ran 38 rules over 12 files with 0 findings. CodeRabbit review of these changes raised the inclusive-boundary point, which is addressed, and the final pass is clean. * Keep the rate-limit purge indexed and fail closed on a purge error Two findings from a CodeRabbit review scoped to the previous commit, which is what finally produced a completed review at this head: the pull request bot was rate limited, and the full-branch review exceeded the 150-file limit because an auto-merge of develop brought 1894 files into the branch. The purge compared window_started + HOUR_IN_SECONDS <= now, which adds an interval to the indexed column and so cannot use the window_started index added for it -- the whole table would be scanned on every request. The cutoff is now computed as now - HOUR_IN_SECONDS and compared directly against window_started, preserving the same boundary while letting the index serve it as a range scan. The purge result was also unchecked, so a failed delete fell through to the upsert and the table would start growing again behind a counter that still worked. A false return now refuses, matching the fail-closed path already used when the counter itself cannot be read, because an unbounded table is the worse failure. Verified: the spec docs suite passes 37/37; semgrep ran 38 rules over the changed file with 0 findings; the ai-feedback validator returns passed true with no outstanding issues. CodeRabbit could not re-review this commit. The organisation quota is exhausted and resets 2026-10-01, so there is no completed review against this head. The preceding commit was reviewed by a completed scoped review, and these two changes address exactly what it raised. * fix(advisories): do not spend the shared IP budget on a refused request The newsletter rate-limit example wrote the per-IP counter before checking the per-address counter, so a visitor behind a shared NAT address could drain the IP budget that everyone behind it shares by resubmitting an address already blocked for them. The address refusal returned true with the IP increment already committed and no refund. Charge the address counter first and wrap both writes in one transaction, so a refused request spends no budget at all. The transaction is what makes the discard atomic: no concurrent request observes a charge for a request that was refused. A commit that cannot be confirmed now refuses rather than letting the counters drift. The purge moves out of the bump function and runs before the transaction opens, so a refused request cannot roll the cleanup back, and a failed purge still fails closed on its own. The counter table is now declared ENGINE=InnoDB: only InnoDB honours ROLLBACK, so on MyISAM the statements would succeed and the rollback would be a no-op, reproducing exactly the behaviour this change removes. The advisory states the trade-off this makes: a refused request is charged to neither counter, so the per-IP limit no longer throttles a caller who keeps resubmitting a blocked address. Those requests are answered 429 before the provider is called, and the prose points operators needing volume-based throttling at the reverse proxy or WAF. tests/js/plugin-advisories-newsletter.test.js reads the PHP out of the document rather than keeping a copy, so it cannot drift, and executes it against a stub $wpdb that models LAST_INSERT_ID and START TRANSACTION / ROLLBACK. Verified non-vacuous: 12 of its 13 tests fail against the previous version of the advisory. The ordering assertions run without PHP, so the regression cannot pass unnoticed on a runner without it. Also align spec 018 research.md R6 with the deferral already stated in spec.md FR-020 and contracts/branch-cleanup.md. R6 still described categorisation as returning DELETE with autoApproved true and the scheduled workflow as gaining a deletion step, in the voice of work already done, which contradicted "Age" in the same section. It also carried an orphaned line fragment, "within a day of its session starting.", left behind when the surrounding sentence was rewritten. * fix(advisories): check every transaction-control result, and two spec gaps A review of the rate-limit change against its own head found a real hole: the "a refused request spends no budget" guarantee rested on two unchecked results. START TRANSACTION was issued without reading its return, so if it failed the two counter writes ran in autocommit, committed immediately, and the ROLLBACK reached afterwards could not undo them, charging the refusal this change exists to prevent. ROLLBACK's own result was discarded too, so a failed discard was silent. Both are now checked: a transaction that cannot be opened charges nothing, and a rollback that fails still refuses but records the fault instead of swallowing it. The guarantee is now only as strong as the weakest of the three results, which is what it claims to be. Adds stub scenarios for both faults, and relaxes the structural assertion to match the guarded form. error_log() is a PHP built-in and cannot be shimmed, so the harness carries stderr through instead of shimming it. Against the version this fixes, 3 of the 15 tests fail. Separately, review of spec 018 surfaced two gaps in the same auto-deletion rule, both of which would delete a branch that holds real work once the deferred signal exists: - "Merged to a base branch" cannot stand in for "is a platform placeholder". Spec 009 FR-002 counts a branch as merged once its tip appears in a base branch's merge-base history, which is equally true of a claude/* branch whose work was later merged upstream. FR-021 requires such a branch to follow normal categorisation, so the condition is now a separate branch-origin check, recorded in the contract as a second open decision alongside the branch-age signal's storage. - A branch-origin check identifies how a branch was *created*, so a placeholder that later received commits would still satisfy it. FR-020 now states the no-own-commits test explicitly, which scenario 6 already promised, and the contract requires it to be re-checked immediately before deletion. Three spec assertions updated to the new wording and the coverage widened, with one case asserting the old wording is gone. Against the pre-fix spec, 3 of the 39 fail. Also corrects FEEDBACK_RESPONSE.md, which said #3524's only remaining work was a develop merge that has already landed. #3524 is open and unmerged; the merge was not the only thing outstanding. * fix(advisories, spec 018): four review findings on the merged head Review of the branch against its own head raised four findings. All four verified against current code before acting; the three spec ones were real, and so was the message one. - Counter-storage failures returned 429, telling a visitor they had submitted too often when the database was at fault. They now return 500, so a real fault is distinguishable from a real rate limit in the logs. - The 429 message blamed the address field. The limiter checks a per-address and a shared per-IP counter and the response does not say which fired, so a shared NAT could exhaust the IP limit while the address was still under its own. The message is now neutral. - The contract promised every deferred candidate receives draft-PR approval, but spec 009's unchanged naming rule routes an invalid `claude/*` name, or one carrying its own commits, to DISCUSS, and nothing routes DISCUSS to draft-PR approval. FR-020, research.md, data-model.md and the contract now all describe the fallback as KEEP, DISCUSS, or a draft-PR-approved DELETE. - The deletion step re-checked "merged and no open PR", but merge status is no longer an eligibility condition, and a placeholder that received a commit after the audit would have been deleted with that work still on it. The re-check is now placeholder origin, no commits of its own, and no open PR, all against the tip the delete acts on, since that is what the lease binds. Full suite 297 suites, 6164 tests, 0 failures. Verified non-vacuous: against the pre-review spec files 8 of the contract assertions fail, and the neutral message and deletion-step assertions fail against their earlier wording. * fix(rate-limit): charge both counters in one statement and align the spec The counter write is now a single multi-row upsert, so a dropped connection cannot replay one key's increment outside the transaction where a later ROLLBACK cannot undo it. A read of the resulting counts is a second statement, so the connection handle is compared before the counts are believed: a replaced handle yields a storage fault, which the caller answers 503, rather than a request allowed but never charged. The upsert resets an expired window's count instead of incrementing it, so a key the purge has not reached stops being blocked after its window ends, and carries the new value out through LAST_INSERT_ID on both branches. The single-key builder gains the same reset so copying it is safe. The spec records the deferral consistently: FR-020's workflow clause and SC-002 no longer promise automatic deletion that is deferred, the audit/deletion edge case names the placeholder re-check and the tip lease the contract requires, and the deferral's two blockers, its consequences and the items it makes safe to land are stated once consistently. * fix(docs): withdraw the advisories table-header claim as unfounded The changelog entry and the pull request body both stated that the Section 1 advisories table had a two-column header while its rows carried four, so CommonMark dropped the Status and Notes columns. That defect is not present in the content merged by #3387. docs/PLUGIN_ADVISORIES.md parses cell by cell as four header cells, four delimiter cells and thirteen four-cell rows, with the header and delimiter counts equal, so no column is ever dropped. The only change this pull request makes to that table is relabelling Caveat as Notes plus re-padding to the compact form used elsewhere in the file. The changelog entry is rewritten to describe what actually changed, and keeps the three real behaviour changes: the newsletter form surviving a failed request, a blocked address being distinguished from a server fault, and atomic rate-limit counting. FEEDBACK_RESPONSE.md records the withdrawn claim as item 17 with the evidence, and the summary no longer asserts that nothing was rejected. No shipped behaviour moves. The change is documentation only, and no test asserted the false claim, so none needed updating; the table shape was verified directly instead. --------- Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com> Co-authored-by: Chris <support@lightspeedwp.agency>
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
3 participants
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.
Documentation Pull Request
Linked issues
Relates to #1396
Implementation tracking: block-plugin-scaffold#37 and block-theme-scaffold#9
What changed
docs/PLUGIN_ADVISORIES.mdto use the currentblock-plugin-scaffoldandblock-theme-scaffoldgenerators as the only implementation sources.developbranches; available entries link to shipped code and planned entries link to generator tracking issues.filemtime()proves content freshness.Honesty notes
availablemeans verified in WordPress core or the current generatordevelop;plannedmeans the linked generator issue still owns implementation.Acceptance criteria mapping
<dialog>reference implementations; Section 3 gives reasons for retained plugins; Section 4 gives hosting-stack reasons.Audience & placement
docs/in this repository.Preview / Screenshots
Not applicable: Markdown documents only; they render in GitHub’s file view.
Notes
developbefore applying the documentation fix.git diff --check, and Semgrep (0findings) passed.0critical errors; its existing repository warnings remain outside this PR.Changelog
Added
Summary by CodeRabbit