Use the item description's markdown editor for the email templates too #131

New Issue

2026-08-22T13:13:02-05:00

bermudalamb commented

2026-08-22 13:13:02 -05:00

Two places in the admin edit markdown, and they do not look or behave alike.

The item description uses MDEditor from @uiw/react-md-editor: a toolbar with bold, italic, headings, links and lists, and a live preview pane. The email template bodies, added in #92 and rearranged into tabs in #119, are a bare Input.TextArea with a monospace font. An admin who has learned one gets nothing from it when they reach the other, and the email bodies are the place where markdown is least familiar and most consequential, since a mistake there goes to customers rather than onto a product page.

Swap the textarea for MDEditor, matching the item form: the same toolbar, the same data-color-mode wrapper so it follows the admin's dark mode, and the same CSS imports.

What should not be copied across

MDEditor is used on the item form with preview="live", which renders its own preview beside the editor. The email editor must not take that, and this is the one part worth deciding rather than copying.

The preview #119 added is rendered by the server, on purpose. It substitutes sample values for the placeholders, appends the consent footer the two favorite templates carry, and runs through the same markdown-it configured with html: false that the mailer uses. MDEditor's built-in preview does none of that: it would show a literal {{resetUrl}}, no footer, and a different renderer's idea of the output. Two previews side by side, one of them wrong about the thing being edited, is worse than the textarea being replaced at all.

So: MDEditor with preview="edit" on the left, and the existing server-rendered email preview kept on the right. The result is still a split view, and the right-hand side is the actual email rather than an approximation of it.

Care needed

The end-to-end tests locate the body by getByLabel('<template> body'). Input.TextArea carries that aria-label directly; MDEditor needs it passed through textareaProps, or every email template test loses its handle on the field.

Verification

The existing email template tests keep passing without being rewritten, which is the check that the accessible label survived the swap. Beyond that: the toolbar renders, the editor follows dark mode as the item form does, and the server-rendered preview still shows substituted placeholders and the consent footer where it belongs.

Depends on

#119, which introduces the editor component this changes.

Two places in the admin edit markdown, and they do not look or behave alike. The item description uses `MDEditor` from `@uiw/react-md-editor`: a toolbar with bold, italic, headings, links and lists, and a live preview pane. The email template bodies, added in #92 and rearranged into tabs in #119, are a bare `Input.TextArea` with a monospace font. An admin who has learned one gets nothing from it when they reach the other, and the email bodies are the place where markdown is least familiar and most consequential, since a mistake there goes to customers rather than onto a product page. Swap the textarea for `MDEditor`, matching the item form: the same toolbar, the same `data-color-mode` wrapper so it follows the admin's dark mode, and the same CSS imports. ## What should not be copied across `MDEditor` is used on the item form with `preview="live"`, which renders its own preview beside the editor. The email editor must not take that, and this is the one part worth deciding rather than copying. The preview #119 added is rendered by the server, on purpose. It substitutes sample values for the placeholders, appends the consent footer the two favorite templates carry, and runs through the same markdown-it configured with `html: false` that the mailer uses. `MDEditor`'s built-in preview does none of that: it would show a literal `{{resetUrl}}`, no footer, and a different renderer's idea of the output. Two previews side by side, one of them wrong about the thing being edited, is worse than the textarea being replaced at all. So: `MDEditor` with `preview="edit"` on the left, and the existing server-rendered email preview kept on the right. The result is still a split view, and the right-hand side is the actual email rather than an approximation of it. ## Care needed The end-to-end tests locate the body by `getByLabel('<template> body')`. `Input.TextArea` carries that `aria-label` directly; `MDEditor` needs it passed through `textareaProps`, or every email template test loses its handle on the field. ## Verification The existing email template tests keep passing without being rewritten, which is the check that the accessible label survived the swap. Beyond that: the toolbar renders, the editor follows dark mode as the item form does, and the server-rendered preview still shows substituted placeholders and the consent footer where it belongs. ## Depends on #119, which introduces the editor component this changes.

bermudalamb added this to the Make the password-reset email editable from Admin project 2026-08-23 07:17:44 -05:00

bermudalamb self-assigned this 2026-08-23 07:17:53 -05:00

bermudalamb referenced this issue from a commit

2026-08-23 07:18:57 -05:00

feat(admin): use the item description's markdown editor for email templates (#131)

bermudalamb referenced a pull request that will close this issue

2026-08-23 07:19:30 -05:00

feat(admin): use the item description's markdown editor for email templates (#131) #133

bermudalamb moved this to In Progress in Make the password-reset email editable from Admin on 2026-08-23 07:19:48 -05:00

bermudalamb added reference feature/131-md-editor-for-emails

2026-08-23 07:20:22 -05:00

bermudalamb closed this issue