Preserve illustrative inline SVG inline instead of externalizing to a blocked .svg asset (#238)#257
Merged
Merged
Conversation
… blocked .svg asset Issue #238: the PHP transformer externalized illustrative/decorative inline `<svg>` elements (e.g. album/EP cover art) into an `assets/inline-svg-*.svg` file and emitted them as `core/image`. WordPress blocks SVG uploads by default, so that image never renders and the artwork is lost. Fix the SVG-render half generically: `inlineSvgBlockFromElement` now emits a `core/html` block that preserves the inline `<svg>` (renders anywhere, no SVG-upload support required) instead of writing a `.svg` asset. The markup is still safe-sanitized via the existing `safeFallbackHtml` + `isSafeSvgContent` gates, so unsafe/scriptable SVG continues to fall back as before and is never inlined raw. Genuine `<img>`/raster images and icon SVGs (core/icon) are unchanged. Also restore the canonical camelCase casing of SVG attribute names that DOMDocument lowercases (e.g. `viewBox`), since SVG attributes are case-sensitive and a lowercased `viewbox` would be ignored by browsers, breaking scaling. Updates the SVG-specific contract assertions and the four parity fixtures whose safe illustrative SVG legitimately moves from core/image(external) to core/html(inline). Decorative-icon, unsafe-SVG, and core/icon fixtures are unchanged. Closes #238 (SVG-render half; the hero layout-misplacement is a separate layout-fidelity concern tracked independently). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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
1 participant
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.
Summary
Closes #238 (SVG-render half). The hero layout-misplacement is a separate layout-fidelity concern and is intentionally out of scope here; it remains tracked independently.
An inline illustrative
<svg>(e.g. album/EP cover art, viewBox-based, decorative) was externalized by the PHP transformer into anassets/inline-svg-*.svgasset and emitted ascore/image url="assets/inline-svg-*.svg". WordPress blocks SVG uploads by default, so that image never renders and the artwork is lost.Fix (generic, SVG-rendering only)
HtmlTransformer::inlineSvgBlockFromElement()now emits acore/htmlblock that preserves the inline<svg>(renders anywhere, no SVG-upload support needed) instead of writing a.svgasset +core/image.<svg>— no fixture-specific strings.safeFallbackHtml()(strips<script>/<style>,on*=handlers,javascript:URLs,srcdoc) +isSafeSvgContent(). Unsafe/scriptable SVG still falls back via the existing diagnostic path and is never inlined raw.viewBox/role/aria-label/class(they live in the SVG markup).restoreSvgAttributeCasing()so DOMDocument's lowercasing (viewBox→viewbox) is reverted. SVG attribute names are case-sensitive; a lowercasedviewboxis ignored by browsers and would break scaling.materializeInlineSvgAsset()helper.Negative cases preserved
<img>/raster images → stillcore/image(untouched).html_unsafe_inline_svg).core/icon(untouched).Did not touch
Classification/,Style/, orDiagnostics/.Before / after (scratch repro)
Safe inline
<svg class="ep-cover" viewBox="0 0 500 500" role="img" aria-label="...">inside a.hero-artwrapper:core/imagewithurl="assets/inline-svg-….svg",<svg>count in blocks = 0 (lost in WP).core/htmlcontaining the<svg>(viewBox casing intact),<svg>count = N > 0, 0 generated.svgassets.Tests
composer test:canonical✅ (updated the SVG-specific contract assertions: large illustrative SVG, decorative logo-context SVG, and the artifact inline-SVG case now assert inlinecore/html+ no generated asset).composer parity✅ 128 fixtures.composer test✅ (canonical + parity + packaging).Parity fixtures changed (intended behavior change for this fix)
These four carried safe illustrative inline SVG that legitimately moves from
core/image(external.svg) →core/html(inline), so each now asserts inline content +assetscount 0:html-flex-media-text-columnshtml-single-child-flex-svghtml-single-child-flex-svg-addresshtml-product-card-svg-price-gridUnchanged (negative cases):
html-inline-svg-decorative(core/icon),html-inline-svg-unsafe(fallback),html-inline-svg-fallback(core/icon).DO NOT MERGE without review.
🤖 Generated with Claude Code