Repository navigation
Release v1.0.0 - #551
Release v1.0.0#551
Conversation
… spacing
The renderers did not implement WordPress's block-gap system for flow
containers, so consecutive paragraph blocks (and any flow-layout
children) rendered flush with zero spacing. Adds the canonical
`:where(.is-layout-flow) > * + * { margin-block-start:
var(--wp--style--block-gap, 24px) }` rule (and the constrained
equivalent) to all three renderers so theme.json `styles.spacing.blockGap`
is honored on the front end.
- Blade: extends the existing `<style data-ve-layout-baseline>` inline
block in `<x-ve-blocks-styles />`
- React/Vue: new `<LayoutBaseline />` component sharing a single
`LAYOUT_BASELINE_CSS` source-of-truth string for byte-identical output
- Per-block `--wp--style--block-gap` overrides emitted by
ThemeJsonTokensCompiler cascade into the new rule via the
`var(--wp--style--block-gap, …)` reference
Closes #539
…k-gap fix: emit is-layout-flow block-gap rule for paragraph spacing
Widen the illuminate/support constraint from >=5.3 to ^11.0|^12.0|^13.0 so Laravel 13 (PHP 8.3+) resolves alongside the existing L11/L12 support. The PHP floor stays at ^8.2 for users on L11/L12; L13's own php constraint enforces 8.3+ transitively. Closes #538
- Clarify CHANGELOG wording — the constraint change drops the effectively-unsupported L5.3-10 range as well as adding L13. - Align the visual-editor-renderer-blade subpackage's illuminate/* constraints with the root package (^11.0|^12.0|^13.0).
…el-13-support enhancement: add Laravel 13 support
- Guard `saveEditedEntityRecord` when `getEditedEntityRecord` returns null so the payload spread no longer trips strict `EntityRecord` typing. - Drop the misused `useSelect<ReturnShape>` generic in `useEntityProp` — `useSelect`'s type parameter is the MapSelect callback, not the return shape — and type the `select` callback so it no longer falls back to `any`. - In the companion test file, widen two `vi.fn` fetcher mocks to match `typeof fetch`, and split the tuple destructure from the type cast on two `useEntityBlockEditor` renderHook calls (the previous `as readonly Array<...>` applied to the tuple, not the blocks array, and used an invalid `readonly Array<>` modifier). Closes #542
…e-data-shim-errors fix(#542): resolve tsc --noEmit errors in core-data-shim
The post-title block edit was a readonly placeholder, so focusing it and
typing did nothing — the canvas displayed the loaded title (via
`useEntityRecord`) but offered no setter path. Replaces the placeholder
with a hybrid edit:
1. Stamped `_resolvedTitle` attribute → readonly (unchanged).
2. `artisanpack/postPreview` query-loop context → readonly preview
(unchanged).
3. Live entity in scope (`postType` + `postId`, no `queryId`) →
editable `PlainText` wired through the core-data shim's
`useEntityProp('postType', postType, 'title', postId)`. Typing
stages an `editEntityRecord` edit, the canvas re-renders via
`useSelect`'s subscription, and `editor-app`'s `stagedEntityEdits`
watch re-arms the metadata-save debounce on the same cycle as
sidebar edits.
4. No entity in scope → placeholder label (unchanged).
Adds a single-mounted-Probe regression test for `useEntityProp` to
confirm the shim's setter does re-render the consumer, and updates the
live-entity test suite with a PlainText mock + a typing test that
asserts both the visible re-render and the staged
`getEntityRecordEdits` payload.
Closes #546
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Inline comment explaining the editable-vs-placeholder branch on `titleText !== '' || editedTitle !== undefined`. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
…t-updating-on-type fix: make artisanpack/post-title editable inline against the live entity
Gutenberg's `TypographyPanel.getMergedFontSizes` concatenates `[...custom, ...theme, ...default]` from `__experimentalFeatures.typography.fontSizes`. Our defaults shipped under `custom:` while `useThemedEditorSettings` adds the host theme under `theme:` — slug overlaps (e.g. `small`, `large` from cms-framework's `default-base.php`) stacked into duplicate React keys in `FontSizePickerSelect`. Move `DEFAULT_FONT_SIZES` / `DEFAULT_FONT_FAMILIES` to the `theme` origin (mirroring the palette / spacingSizes pattern) so the themed hook's `theme:` override replaces them cleanly. Add defensive slug dedupe (first-wins) to every theme-extract helper as defense in depth against malformed upstream payloads. Closes #547
…-duplicate-keys fix: dedupe font-size presets to silence FontSizePicker key warnings (#547)
…graph-block-gap-fix fix: add paragraph block-gap fix to changelog
- Bump package.json version 1.0.0-beta1 -> 1.0.0 - Sync package-lock.json - Convert CHANGELOG [Unreleased] -> [1.0.0] 2026-06-08, add the post-title / FontSizePicker / core-data-shim fixes that landed since beta1 - Normalize stale @SInCE 1.1.0 / 2.0.0 tags to @SInCE 1.0.0 across the V1 surface that actually shipped in 1.0.0 (site editor, form block, comments, renderer-blade) Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
✅ Files skipped from review due to trivial changes (1)
🚧 Files skipped from review as they are similar to previous changes (2)
📝 WalkthroughWalkthroughRelease 1.0.0: package version and changelog updated, Composer constraints widened for Laravel 13, layout-baseline CSS added to Blade/React/Vue with tests, PostTitle replaced by live-editing component using useEntityProp and corresponding shim/test fixes, theme preset deduplication added, and many ChangesRelease Versioning and Documentation
Cross-Renderer Layout Baseline CSS
Post Title Live Inline Editing & Core-Data Shim
Typography Deduplication and Editor Settings
Docblock/JSDoc
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (2)
resources/js/visual-editor/blocks/post-title/edit.tsx (1)
136-143: 💤 Low valueConsider extracting the repeated boolean condition.
The expression
identity !== null && ! inQueryLoopis evaluated four times. Extract it to a named constant for clarity and maintainability:+ const canEditLiveEntity = identity !== null && ! inQueryLoop; const [ editedTitle, setTitle ] = useEntityProp< string | { raw?: string; rendered?: string } >( - identity !== null && ! inQueryLoop ? 'postType' : undefined, - identity !== null && ! inQueryLoop ? identity.postType : undefined, - identity !== null && ! inQueryLoop ? 'title' : undefined, - identity !== null && ! inQueryLoop ? identity.postId : null, + canEditLiveEntity ? 'postType' : undefined, + canEditLiveEntity ? identity.postType : undefined, + canEditLiveEntity ? 'title' : undefined, + canEditLiveEntity ? identity.postId : null, );🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@resources/js/visual-editor/blocks/post-title/edit.tsx` around lines 136 - 143, Extract the repeated condition `identity !== null && ! inQueryLoop` into a well-named boolean constant (e.g., hasIdentityAndNotInQueryLoop) and use that constant for all four arguments passed to useEntityProp (the call that returns editedTitle and setTitle), replacing the repeated expression; update the call sites referencing identity.postType and identity.postId to guard with that constant to preserve the existing behavior when it's false.packages/visual-editor-renderer-vue/src/LayoutBaseline.ts (1)
27-35: ⚡ Quick winPrefer text content over
innerHTMLprop.Setting
innerHTMLas a prop works in Vue 3, but for a<style>tag, passing the CSS as the third argument (children) toh()is more idiomatic and avoids direct DOM property manipulation.♻️ Proposed refactor to use text content
return (): VNode => h( 'style', { 'data-ve-layout-baseline': '', - innerHTML: LAYOUT_BASELINE_CSS, }, - [] + LAYOUT_BASELINE_CSS );🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/visual-editor-renderer-vue/src/LayoutBaseline.ts` around lines 27 - 35, The current render function in LayoutBaseline (the returned arrow that calls h('style', { 'data-ve-layout-baseline': '', innerHTML: LAYOUT_BASELINE_CSS }, [])) uses innerHTML; replace this by passing LAYOUT_BASELINE_CSS as the third argument (children) to h() and remove the innerHTML prop so the <style> content is provided as text children instead (keep the 'data-ve-layout-baseline' attribute intact) — update the VNode creation in the LayoutBaseline return to h('style', { 'data-ve-layout-baseline': '' }, LAYOUT_BASELINE_CSS).
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@CHANGELOG.md`:
- Around line 41-43: The changelog entry currently attributes the core-data shim
TypeScript fix to the wrong PR number (`#543`); update the text in CHANGELOG.md
where the paragraph "- **`tsc --noEmit` errors in the core-data shim.** ..."
references `#543` and replace that reference with the correct issue/PR number
`#542` so the entry correctly maps the core-data shim TS fixes to PR `#542`.
In `@resources/js/visual-editor/blocks/post-title/edit.tsx`:
- Line 176: The PlainText usage in edit.tsx sets the internal prop
__experimentalVersion={2}; remove this prop from the PlainText element (symbol:
PlainText in this file) if the block behaves correctly without it, otherwise add
a clear justification comment above the PlainText explaining why the
experimental flag is required and pin/document the compatible
`@wordpress/block-editor` version in package.json/CHANGELOG so future updates are
explicit; ensure any tests/manual checks verify the block still renders and
edits correctly after removing or documenting the flag.
- Line 172: The PlainText component is being passed an unsupported prop tagName
(via TagName as never); remove the tagName prop from PlainText in the PostTitle
edit component and either: 1) replace PlainText with RichText (e.g., use
RichText for the editable title and pass tagName={TagName}) if you need editable
heading levels, or 2) keep PlainText and render the semantic heading element
using TagName as the wrapper/output (wrap PlainText with the selected TagName or
render the value inside <TagName> for front-end output). Update references to
TagName, PlainText, and RichText in the edit component so no cast (as never) is
required and no unsupported prop is passed.
---
Nitpick comments:
In `@packages/visual-editor-renderer-vue/src/LayoutBaseline.ts`:
- Around line 27-35: The current render function in LayoutBaseline (the returned
arrow that calls h('style', { 'data-ve-layout-baseline': '', innerHTML:
LAYOUT_BASELINE_CSS }, [])) uses innerHTML; replace this by passing
LAYOUT_BASELINE_CSS as the third argument (children) to h() and remove the
innerHTML prop so the <style> content is provided as text children instead (keep
the 'data-ve-layout-baseline' attribute intact) — update the VNode creation in
the LayoutBaseline return to h('style', { 'data-ve-layout-baseline': '' },
LAYOUT_BASELINE_CSS).
In `@resources/js/visual-editor/blocks/post-title/edit.tsx`:
- Around line 136-143: Extract the repeated condition `identity !== null && !
inQueryLoop` into a well-named boolean constant (e.g.,
hasIdentityAndNotInQueryLoop) and use that constant for all four arguments
passed to useEntityProp (the call that returns editedTitle and setTitle),
replacing the repeated expression; update the call sites referencing
identity.postType and identity.postId to guard with that constant to preserve
the existing behavior when it's false.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: f63291fb-d48d-4365-9599-6325209aa6f9
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json,!package-lock.json
📒 Files selected for processing (38)
CHANGELOG.mdcomposer.jsonpackage.jsonpackages/visual-editor-renderer-blade/composer.jsonpackages/visual-editor-renderer-blade/resources/views/components/blocks-styles.blade.phppackages/visual-editor-renderer-blade/src/Services/GlobalStylesEmissionResolver.phppackages/visual-editor-renderer-blade/src/Services/NavigationOverlayTracker.phppackages/visual-editor-renderer-blade/src/Services/ThemeJsonTokensCompiler.phppackages/visual-editor-renderer-blade/src/Support/BlockSupports.phppackages/visual-editor-renderer-blade/src/Support/ElementsSupport.phppackages/visual-editor-renderer-blade/tests/Feature/BlocksStylesComponentTest.phppackages/visual-editor-renderer-blade/tests/Unit/BlockSupportsTest.phppackages/visual-editor-renderer-blade/tests/Unit/ElementsSupportTest.phppackages/visual-editor-renderer-blade/tests/Unit/ThemeJsonTokensCompilerTest.phppackages/visual-editor-renderer-react/src/LayoutBaseline.tsxpackages/visual-editor-renderer-react/src/index.tspackages/visual-editor-renderer-react/src/support/layoutBaselineCss.tspackages/visual-editor-renderer-react/tests/LayoutBaseline.test.tsxpackages/visual-editor-renderer-vue/src/LayoutBaseline.tspackages/visual-editor-renderer-vue/src/index.tspackages/visual-editor-renderer-vue/src/support/layoutBaselineCss.tspackages/visual-editor-renderer-vue/tests/LayoutBaseline.test.tsresources/js/visual-editor/__tests__/use-themed-editor-settings.test.tsresources/js/visual-editor/blocks/_shared/__tests__/entity-placeholder-live-entity.test.tsxresources/js/visual-editor/blocks/_shared/__tests__/entity-placeholder-query-preview.test.tsxresources/js/visual-editor/blocks/post-title/edit.tsxresources/js/visual-editor/editor-settings.tsresources/js/visual-editor/site-editor/block-editor-boundary.tsxresources/js/visual-editor/use-themed-editor-settings.tsresources/js/visual-editor/vendor/__tests__/core-data-shim.test.tsxresources/js/visual-editor/vendor/core-data-shim.tssrc/Blocks/Forms/FormBlock.phpsrc/Http/Controllers/SiteEditor/GlobalStylesController.phpsrc/Http/Controllers/SiteEditor/MenuController.phpsrc/Resources/CommentInliner.phpsrc/SiteEditor/MenuItemBlockBridge.phpsrc/SiteEditor/NavigationBlockRefResolver.phpsrc/VisualEditorServiceProvider.php
| return ( | ||
| // eslint-disable-next-line @typescript-eslint/no-explicit-any | ||
| <PlainText | ||
| tagName={ TagName as never } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check PlainText's tagName prop type definition
rg -A5 -B2 'tagName.*:.*string' node_modules/@wordpress/block-editor --type=tsRepository: ArtisanPack-UI/visual-editor
Length of output: 149
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# 1) Inspect the local file around the reported line
FILE="resources/js/visual-editor/blocks/post-title/edit.tsx"
echo "== $FILE =="
nl -ba "$FILE" | sed -n '130,220p'
# 2) Find the exact `as never` usage(s)
rg -n "tagName=\{[^}]*as never\}" resources/js/visual-editor/blocks/post-title/edit.tsx
# 3) Locate where TagName/tagNameForLevel are defined
rg -n "tagNameForLevel|TagName" resources/js/visual-editor/blocks/post-title/edit.tsxRepository: ArtisanPack-UI/visual-editor
Length of output: 193
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Identify the wp/block-editor package version used by this repo
if [ -f package.json ]; then
echo "== package.json =="
cat package.json
fi
# Search for `@wordpress/block-editor` in lockfiles/manifests
rg -n "`@wordpress/block-editor`" package-lock.json yarn.lock pnpm-lock.yaml 2>/dev/null || trueRepository: ArtisanPack-UI/visual-editor
Length of output: 3890
🌐 Web query:
@wordpress/block-editor PlainText tagName prop type PlainTextProps interface
💡 Result:
The @wordpress/block-editor PlainText component does not accept a tagName prop [1][2][3]. Unlike the RichText component, which uses a tagName prop to define the underlying HTML element (defaulting to div) [4], the PlainText component is specifically designed to render an auto-growing textarea element [1][2]. There is no formal PlainTextProps interface exported by the @wordpress/block-editor package [5]. According to WordPress development best practices, if you need to determine the type for the props of this component, you should use React.ComponentProps [5]. For example, you can extract the type as follows: import { PlainText } from '@wordpress/block-editor'; type PlainTextProps = React.ComponentProps; The PlainText component supports the following primary props [1][2]: - value (string, required): The string value of the textarea [1][2]. - onChange (function, required): A callback function triggered when the text value changes [1][2]. - ref (object, optional): A ref forwarded to the underlying TextareaAutosize component [1][2]. - Additional props: You can pass any standard HTML textarea attributes as additional props, which the component will apply to the rendered textarea [1][3].
Citations:
- 1: https://github.com/WordPress/gutenberg/blob/HEAD/packages/block-editor/src/components/plain-text/README.md
- 2: https://github.com/WordPress/gutenberg/blob/trunk/packages/block-editor/README.md
- 3: https://github.com/WordPress/gutenberg/blob/trunk/packages/block-editor/src/components/plain-text/README.md
- 4: https://github.com/WordPress/gutenberg/blob/HEAD/packages/block-editor/src/components/rich-text/README.md
- 5: https://developer.wordpress.org/block-editor/reference-guides/components/
🌐 Web query:
PlainText tagName type "keyof JSX.IntrinsicElements" "@wordpress/block-editor"
💡 Result:
The PlainText component in the @wordpress/block-editor package is an auto-growing textarea used to capture textual content [1][2][3]. It does not have an official tagName property in its public API; it functions as a wrapper around an auto-resizing textarea component [1][2]. Regarding the technical context of your query: 1. JSX.IntrinsicElements: The use of keyof JSX.IntrinsicElements (or more recently, keyof React.JSX.IntrinsicElements) is a common pattern in the WordPress/Gutenberg codebase for defining polymorphic component props (often via an as property) [4]. This allows components to accept any valid HTML tag name as a prop, ensuring type safety when rendering dynamic elements [4]. 2. @wordpress/block-editor: Recent updates to the Gutenberg codebase have migrated JSX type references from the global JSX namespace to React.JSX to maintain compatibility with React 19 standards [4][5]. If you are encountering a type error or requirement involving these terms, it is likely related to defining a custom wrapper or extending existing WordPress components to support polymorphic behavior (using the as pattern) [4]. The PlainText component itself is designed for standard textarea usage and does not expose a tagName prop for external configuration [1][2].
Citations:
- 1: https://github.com/WordPress/gutenberg/blob/HEAD/packages/block-editor/src/components/plain-text/README.md
- 2: https://github.com/WordPress/gutenberg/blob/trunk/packages/block-editor/README.md
- 3: https://developer.wordpress.org/block-editor/reference-guides/packages/packages-block-editor/
- 4: WordPress/gutenberg@5139e57
- 5: Prefix usages of JSX namespaces with React.JSX WordPress/gutenberg#75508
🏁 Script executed:
#!/bin/bash
set -euo pipefail
FILE="resources/js/visual-editor/blocks/post-title/edit.tsx"
echo "== file exists? =="
test -f "$FILE" && echo "yes" || (echo "no"; exit 1)
echo "== $FILE (around 160-190) =="
# cat -n is usually available; avoids nl dependency
cat -n "$FILE" | sed -n '150,200p'
echo "== search: tagNameForLevel / TagName definitions =="
rg -n "tagNameForLevel|type\s+TagName|const\s+TagName|enum\s+TagName|TagName" "$FILE"
echo "== search: PlainText usage around tagName =="
rg -n "PlainText|tagName=\{.*\}" "$FILE"
echo "== search: any other tagName props on PlainText in repo =="
rg -n "PlainText[\s\S]{0,200}tagName=" resources/js/visual-editor -S || trueRepository: ArtisanPack-UI/visual-editor
Length of output: 2759
🏁 Script executed:
#!/bin/bash
set -euo pipefail
FILE="resources/js/visual-editor/blocks/post-title/edit.tsx"
echo "== $FILE (around tagNameForLevel + TagName) =="
cat -n "$FILE" | sed -n '80,160p'
echo "== $FILE (imports for PlainText) =="
rg -n "import\s+\{[^}]*PlainText" "$FILE"Repository: ArtisanPack-UI/visual-editor
Length of output: 3641
🌐 Web query:
@wordpress/block-editor@15.16.0 PlainText tagName prop types
💡 Result:
The PlainText component in @wordpress/block-editor does not support or use a tagName prop [1][2][3][4]. The PlainText component is designed specifically to render an auto-growing textarea [1][2][4]. Because it is hardcoded to use a textarea element, it does not provide a mechanism to change the underlying HTML tag, unlike the RichText component, which does support a tagName prop [5][6]. If you require a component that allows specifying the HTML tag (such as h1, p, or div), you should use the RichText component instead [5][6]. For the PlainText component, the supported props are [1][2][3][4]: - value: string (Required) - onChange: Function (Required) - ref: Object (Optional) - Any other standard textarea attributes (e.g., placeholder, className) are generally passed through to the underlying textarea element [1].
Citations:
- 1: https://github.com/WordPress/gutenberg/blob/HEAD/packages/block-editor/src/components/plain-text/README.md
- 2: https://www.npmjs.com/package/@wordpress/block-editor
- 3: https://github.com/WordPress/gutenberg/blob/trunk/packages/block-editor/README.md
- 4: https://developer.wordpress.org/block-editor/reference-guides/packages/packages-block-editor/
- 5: https://github.com/WordPress/gutenberg/blob/HEAD/packages/block-editor/src/components/rich-text/README.md
- 6: https://www.mintlify.com/WordPress/gutenberg/packages/block-editor
🌐 Web query:
gutenberg PlainText component props tagName
💡 Result:
The WordPress Gutenberg PlainText component does not support a tagName prop [1][2]. The PlainText component is designed specifically to render an auto-growing textarea [1][2], which is a form control element that does not accept a tag name to change its underlying HTML element (unlike the RichText component, which uses a tagName prop to specify the tag, such as 'p' or 'h2', that the editable content should be wrapped in) [3][4]. If you require editable content that supports custom HTML tags, you should use the RichText component instead [3][4]. PlainText is intended for raw text input where a textarea is the appropriate UI element [5][6].
Citations:
- 1: https://github.com/WordPress/gutenberg/blob/trunk/packages/block-editor/src/components/plain-text/README.md
- 2: https://github.com/WordPress/gutenberg/blob/trunk/packages/block-editor/README.md
- 3: https://developer.wordpress.org/block-editor/reference-guides/richtext/
- 4: https://github.com/WordPress/gutenberg/blob/HEAD/packages/block-editor/src/components/rich-text/README.md
- 5: Components: Adding a PlainText component for raw editable content WordPress/gutenberg#4805
- 6: https://www.mintlify.com/WordPress/gutenberg/packages/block-editor
🌐 Web query:
site:github.com WordPress gutenberg packages/block-editor src/components/plain-text tagName
💡 Result:
The PlainText component in the WordPress @wordpress/block-editor package does not support a tagName property [1][2][3]. The PlainText component is specifically designed to render an auto-growing textarea [1][3]. Because it is fundamentally based on a textarea element, it does not provide the ability to change the underlying HTML tag, unlike the RichText component, which does support a tagName property to define the editable element (defaulting to a div) [4][5]. If your requirements necessitate the use of a specific HTML tag (e.g., h1, p, span) for editable content, you should use the RichText component instead [4][6]. If you require simple, non-formatted text input while needing semantic tag control, you may need to configure RichText to disable formatting tools or implement a custom component that meets your specific needs.
Citations:
- 1: https://github.com/WordPress/gutenberg/blob/HEAD/packages/block-editor/src/components/plain-text/README.md
- 2: https://github.com/WordPress/gutenberg/blob/trunk/packages/block-editor/src/components/plain-text/README.md
- 3: https://github.com/WordPress/gutenberg/blob/trunk/packages/block-editor/README.md
- 4: https://github.com/WordPress/gutenberg/blob/HEAD/packages/block-editor/src/components/rich-text/README.md
- 5: https://github.com/WordPress/gutenberg/blob/master/packages/block-editor/src/components/rich-text/README.md
- 6: https://github.com/WordPress/gutenberg/blob/trunk/packages/block-editor/src/components/rich-text/README.md
Remove invalid tagName usage on PlainText (drop as never)
resources/js/visual-editor/blocks/post-title/edit.tsx passes tagName={ TagName as never } to PlainText, but PlainText is a textarea-based component and doesn’t support a tagName prop—so this cast hides a real API mismatch. Use RichText for heading/tag selection (or apply semantic heading output outside PlainText) and stop passing tagName to PlainText.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@resources/js/visual-editor/blocks/post-title/edit.tsx` at line 172, The
PlainText component is being passed an unsupported prop tagName (via TagName as
never); remove the tagName prop from PlainText in the PostTitle edit component
and either: 1) replace PlainText with RichText (e.g., use RichText for the
editable title and pass tagName={TagName}) if you need editable heading levels,
or 2) keep PlainText and render the semantic heading element using TagName as
the wrapper/output (wrap PlainText with the selected TagName or render the value
inside <TagName> for front-end output). Update references to TagName, PlainText,
and RichText in the edit component so no cast (as never) is required and no
unsupported prop is passed.
- CHANGELOG: correct core-data-shim fix reference #543 -> #542 - post-title/edit.tsx: extract repeated `identity !== null && ! inQueryLoop` into `hasLiveEntity` so the four useEntityProp args + the live-entity branch all read off one boolean - post-title/edit.tsx: document why PlainText carries `tagName` + `__experimentalVersion={2}` (runtime-supported by @wordpress/block-editor >= 14; types lag; RichText would allow inline formatting we deliberately want to suppress on titles) - visual-editor-renderer-vue/LayoutBaseline: pass CSS as h() children instead of `innerHTML` prop Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
github-project-automation
Bot
moved this from In Review
to Done
in ArtisanPack UI Overview
1 participant
Release Information
release/1.0mainRelease Summary
First stable V1 release of
artisanpack-ui/visual-editor. Promotes1.0.0-beta1to GA and ships four bug fixes that landed against therelease branch since beta1. The post editor, site editor,
artisanpack/*block fork, and first-classartisanpack-ui/cms-frameworkpairing (introduced across
1.0.0-alpha.1and1.0.0-beta1) are nowconsidered stable.
Changelog
Added
illuminate/supportconstraint expanded to^11.0|^12.0|^13.0. PHP floor unchanged at^8.2(L13 enforces8.3+ transitively).
Fixed
inherit
is-layout-flowblock-gap spacing in the rendered output (fix: emit is-layout-flow block-gap rule for paragraph spacing #540).artisanpack/post-titleeditable inline. Post-title block nowedits the live entity directly (Post editor title block reads correctly but does not update as the user types #546).
deduplicated before being handed to
FontSizePicker(Duplicate React key warnings (small,large) from FontSizePicker when a block is selected #547).tsc --noEmiterrors in the core-data shim. Resolved TypeScripterrors in the core-data shim and its tests (CHANGELOG [Unreleased] missing paragraph block-gap fix (#540) #543).
Changed (release prep)
@since 1.1.0/@since 2.0.0PHPDoc/JSDoc tagsto
@since 1.0.0across the V1 surface that actually shipped in1.0.0 (site editor, form block, comments, renderer-blade package).
Issues and Pull Requests
Issues Fixed:
small,large) from FontSizePicker when a block is selected #547 (FontSizePicker duplicate keys)Breaking Changes
1.0.0-beta1)Anyone upgrading directly from
1.0.0-alpha.1should still consultdocs/migration.md§4 for thecore/*→artisanpack/*block-namespace migration that landed in beta1.Testing Checklist
JS: 1,849 tests (231 files)
through dev app)
Testing notes:
Security audit results (see "Dependency Notes" below) — no blockers
identified. Most npm advisories are transitive through
@wordpress/*upstreams and resolve when those packages publish patched versions.
Documentation Checklist
@sincetags normalized)docs/migration.mdcoversalpha.1 → 1.0.0)
Pre-Release Checklist
package.json,package-lock.json)v1.0.0release/1.0Dependency Notes
Composer:
composer auditreports 13 advisories across 9 packages.All are transitive through dev dependencies (notably
symfony/yamlandrelated Symfony 7.x components pulled in by
orchestra/testbench).None affect the runtime surface of the package. Recommend a follow-up
composer updateagainst Symfony patch releases after this release tag.npm:
npm auditreports 26 advisories (24 moderate, 1 high, 1 critical).The vast majority are transitive through
@wordpress/*packages pinnedat the
1.0.0-alpha.1@wordpress/*table (seedocs/release-notes-inputs-1.0.0.md); they will clear when thoseupstreams publish patched releases. The critical advisory is in a
transitive
wsdependency reachable only through dev tooling.Post-Release Tasks
v1.0.0Notes
Paired version:
artisanpack-ui/cms-framework ^2.0(seedocs/release-notes-inputs-1.0.0.mdfor the pinned@wordpress/*tableand the visual-editor ↔ cms-framework version pair).
🤖 Generated with Claude Code
Release Manager: @jacobmartella
Summary by CodeRabbit
New Features
Bug Fixes
Improvements