@bettercms-ai/convert 0.21.0 → 0.23.0

package/CHANGELOG.md

@@ -1,5 +1,23 @@
 # @bettercms-ai/convert
 
+## 0.23.0
+
+### Minor Changes
+
+- 6c75c11: `bettercms-convert --upgrade-sections --root .` gives a site converted before helper v10 the section style marker, so the visual editor shows section spacing and style handles on its pages. Every element that carries `data-bcms-block` and no `data-bcms-style` gets the marker together with the style it promises. A component that `--componentize` wrote gets `data-bcms-style="" style={bcmsSectionStyle[Text](blockStyle)}` and the `blockStyle` prop, and its registry and `src/lib/bcms-sections.ts` are patched to pass each placement's `block.style`. The result is byte-identical to what a fresh extraction writes today. `data-bcms-block={block.id}` becomes `{...sectionRootAttrs(block)}` when the SDK range guarantees that export (`@bettercms-ai/astro` 0.19, `@bettercms-ai/next` 0.18), and otherwise gets the marker and `block.style` through the helper. The helper is upgraded to the current version, or added with its layout stub. Roots with their own `style` or a spread, roots that receive only a block id, and literal, conditional or unresolvable blocks are left alone. Each one is listed in the receipt with its reason (`OWN_STYLE`, `SPREAD`, `BLOCK_ID_ONLY`, `BLOCK_LITERAL`, `BLOCK_UNRESOLVABLE`, …). A second run writes nothing, and no class, className or existing style token changes. `--dry-run`, `--receipt`, `--strict` and `--overwrite-helper` work as in the other modes.
+
+## 0.22.0
+
+### Minor Changes
+
+- c0afef4: The emitted helper (v11) paints the same section design keys as `blockStyleToCss`: `theme`, `bg`/`bgCustom`, `bgImage` (http(s) or root-relative only), `corner`, `shadow`, `fullHeight`, `opacity`, `borderTop`/`borderBottom` and the px padding sliders. A converted section root's `data-bcms-style` promise, that its inline style is `blockStyleToCss(block.style)`, holds again for sections styled in the visual editor. Helpers at v10 and older are recognised and upgraded. The content column (`contentWidth`) is still not drawn on converted roots.
+
+### Patch Changes
+
+- Updated dependencies [c0afef4]
+- Updated dependencies [5c6db8e]
+  - @bettercms-ai/types@1.30.0
+
 ## 0.21.0
 
 ### Minor Changes

package/README.md

@@ -601,6 +601,45 @@ the now-unused `bcms`/snapshot imports P2 added, and a page whose registered cal
 `<Sections>` keeps the imports of the components it used to call. They are harmless at build time
 and removing them would mean editing statements no section asked about.
 
+### Section spacing handles on a site converted before helper v10 (`--upgrade-sections`)
+
+The visual editor shows a page's section spacing and style handles only when EVERY root the build
+stamps with `data-bcms-block` also carries `data-bcms-style` — the site's promise that the root's
+inline style is `blockStyleToCss(block.style)`. Conversions before 0.21 (helper v6–v9, componentize
+v2 sections, hand-written roots) stamp the block and not the marker, so those pages never get
+handles. `get_next_steps` says so (`upgrade-section-roots`) when the release finds such roots.
+
+```bash
+npx @bettercms-ai/convert@latest --upgrade-sections --root . --dry-run   # read the plan
+npx @bettercms-ai/convert@latest --upgrade-sections --root .             # then push and release
+```
+
+Each root with `data-bcms-block` and no `data-bcms-style` gets the marker together with the style:
+
+- a component `--componentize` wrote (`data-bcms-block={blockId}`): `data-bcms-style=""
+  style={bcmsSectionStyle[Text](blockStyle)}`, the `blockStyle` prop, and the registry and
+  `src/lib/bcms-sections.ts` patched to pass `block.style` down — byte-identical to what a fresh
+  extraction writes today;
+- `data-bcms-block={block.id}` where the SDK has `sectionRootAttrs` (`@bettercms-ai/astro` >= 0.19,
+  `@bettercms-ai/next` >= 0.18, read off the LOWEST version the range admits):
+  `{...sectionRootAttrs(block)}`;
+- the same root on an older SDK: `data-bcms-style="" style={bcmsSectionStyle[Text](block.style)}`
+  through the helper, which is upgraded (or added, with its `bcms-content/layout.json` stub).
+
+Left alone, and listed as `skipped` with a reason: `OWN_STYLE` (the root sets its own `style`),
+`SPREAD` (a `{...rest}` that may carry one), `BLOCK_ID_ONLY` (only an id reaches the root —
+`data-bcms-block={Astro.props.bcmsBlock}`; pass the block or its style down), `BLOCK_LITERAL`,
+`BLOCK_UNRESOLVABLE` (a conditional or a call), `NOT_AN_ELEMENT`, `NAME_TAKEN`,
+`REGISTRY_UNRECOGNISED`, `DIALECT_UNSUPPORTED` (html, vue, svelte), `PARSE_ERROR`. A helper this
+package did not write is `HELPER_CONFLICT` (exit 1) only when a root needs it; `--overwrite-helper`
+replaces it.
+
+The receipt (`--receipt <file>`) is `{ helpers, registry, roots: { upgraded, alreadyMarked,
+skipped } }`, each root as `{ file, line, tag, block, form | reason + message }`. No class,
+className or existing style token changes (`--verify-styles` stays clean), and a second run writes
+nothing and counts every root it marked as `alreadyMarked`. `--strict` exits 2 while any root is
+skipped.
+
 ## Forms
 
 The third mode, and the shortest. The release-time derive lane reads every `<form>` in the built