Block Editor SDK renderers (Angular & React) drop href/target on dotImage nodes — linked images not clickable on frontend

Problem Statement

After #36361 / PR #36368 shipped in 26.07.13-01, the Block Editor correctly saves href and target as attributes on a dotImage node when an editor links an image. However, neither the @dotcms/angular nor the @dotcms/react SDK's built-in Block Editor renderer reads those attributes when rendering the node on the frontend. The image renders as a plain <figure><img /></figure> with no anchor, so the link — while correctly stored and visible as "linked" inside the CMS editor — never becomes clickable on the live page.

PR #36368's own description confirms the data layer was never the gap: "The dotImage node already supports href/target end-to-end... the break was purely in the UI flow." That PR fixed the UI flow (editor side). This issue is the renderer-side counterpart that was never addressed.

Affected components

• @dotcms/angular — DotImageBlock component (selector dotcms-block-editor-renderer-image), confirmed present through the current published latest (26.8.10-1)
• @dotcms/react — DotCMSImage component at DotCMSBlockEditorRenderer/components/blocks/Image.tsx, confirmed present through the current published latest (26.8.10-1)

Evidence

Angular SDK — DotImageBlock template (verified directly against the published @dotcms/angular@26.8.10-1 package, fesm2022/dotcms-angular.mjs):

<figure [style]="$wrapperStyle()">
    <img [alt]="attrs?.['alt']" [src]="$srcURL()" />
</figure>

Only src, alt, textWrap, textAlign are read from attrs. No href, no target.

React SDK — Image.tsx (verified directly against the published @dotcms/react@26.8.10-1 package, lib/next/components/DotCMSBlockEditorRenderer/components/blocks/Image.esm.js):

const { src, alt, textWrap, textAlign } = node.attrs;
...
return <figure style={wrapperStyle}><img alt={alt} src={src} .../></figure>;

Same gap — href/target never destructured or used.

Customer reproduction (Freshdesk #38732) — actual frontend DOM from the customer's Chrome DevTools:

<dotcms-block-editor-renderer-image>
  <figure>
    <img alt="vuso_logo.png" src="/dA/0c3abd69-299d-4bb1-b367-b76486b59c3c">
  </figure>
</dotcms-block-editor-renderer-image>

Confirms the Angular renderer path is exactly what's hit in production — the component name in the DOM is the literal Angular selector for DotImageBlock.

Steps to Reproduce

1. In the Block Editor, insert an image into a rich text field.
2. Select the image, click the Link toolbar button, set a URL (optionally "open in new tab").
3. Save and publish.
4. Confirm in the editor that the image shows as linked (works correctly since 26.07.13-01).
5. View the published page on the frontend (Angular or React SDK-rendered site).
6. Inspect the DOM around the image — no <a> wrapper is present; the image is not clickable.

Acceptance Criteria

The SDK's built-in dotImage renderer should wrap the <img> in an <a href="..." target="..."> when href is present on the node's attrs, mirroring what dotImage.vtl does server-side for Velocity-rendered pages (confirmed present in dotCMS/src/main/webapp/WEB-INF/velocity/static/storyblock/dotImage.vtl on main, including the #if ($!item.attrs.href != "null") branch — though note that template itself has no target support either, a related but separate gap).

dotCMS Version

26.07.30-01

Severity

Medium - Some functionality impacted

Links

https://dotcms.freshdesk.com/a/tickets/38732

Start with the Angular DotImageBlock component using selector dotcms-block-editor-renderer-image and React's DotCMSBlockEditorRenderer/components/blocks/Image.tsx. Inspect how each renderer reads node.attrs, then reproduce the linked-image steps and inspect the frontend DOM. Done means both SDK renderers wrap the image in an anchor when href is present and preserve target when supplied.