The best editor upgrade is the one that removes fear from content work.
We added a Tiptap React editor to our ecommerce PageBuilder because raw HTML blocks had become too expensive to edit. They worked, but only for people who were comfortable reading markup. A merchant should be able to add a headline, image, button, columns, tabs, or an Instagram embed without breaking product-page layout or shipping unsafe HTML.
The work landed on the `codex/htmlblock-wysiwyg-editor` branch in the ecom theme. The first implementation commit, `08692e2e`, added the HTML block WYSIWYG editor. Later commits polished interactions, moved labels into the translation system, hardened media handling, and deduped media-library images by ID.
Tiptap was a good fit because it did not force us into a closed CMS shape. We kept the existing PageBuilder HTML contract and used Tiptap as the editing engine.
What we built
The visible feature is simple: PageBuilder HTML blocks now have a real editor instead of a raw HTML textarea.
The implementation is more useful than that sentence sounds. The editor supports:
That last point mattered. This was not a greenfield editor. The ecommerce frontend already had Bootstrap-style content, legacy CMS snippets, PageBuilder zones, PrestaShop media paths, and SEO rules. We needed a WYSIWYG layer that could edit content without flattening the site’s existing HTML model.
Why Tiptap felt simple
Tiptap’s React setup is small: `useEditor`, `EditorContent`, and an extension array. StarterKit gives the base editing primitives, then you add the pieces your product needs.
In our case, the dependency set stayed understandable:
That was enough to build the editor surface and then layer our own ecommerce blocks on top. We used `StarterKit.configure()` for the standard editor behavior, disabled the default link handling where we needed our own rules, then configured Link and Highlight explicitly.
The simple part was not that Tiptap solved every ecommerce problem. It did not. The simple part was the extension model. We could describe our own content nodes directly: button, image, legacy image, Instagram embed, columns, tabs, spacer, table, font size, list style, and text alignment.
That maps cleanly to a PageBuilder. A button is not just styled text. An image is not just an `img` tag. A tab component has labels, panels, IDs, active state, and accessible roles. Tiptap let us model those things as editor content instead of trying to infer them from a textarea after the fact.
The HTML roundtrip was the important part
A lot of WYSIWYG migrations fail because the editor wants one format and the site renders another.
We did not want that. The frontend already renders HTML blocks across product pages, content pages, homepage sections, checkout-adjacent slots, and other PageBuilder zones. The editor needed to load existing HTML, let an admin change it, and save HTML that the public storefront could render safely.
Tiptap gave us the conversion tools for that. For tab panels, we use `generateJSON()` to turn existing HTML into editor content and `generateHTML()` to turn panel content back into HTML. That keeps the edit surface structured while preserving the site’s public HTML output.
This matters for SEO too. A CTA remains an anchor. A heading remains a heading. An image remains a semantic figure with alt text and caption. Tabs keep crawlable panel content. We did not bury ecommerce copy inside a client-only widget that search engines or assistive technology have to guess through.
The editor is simple for merchants, strict for code
The admin UI hides most of the complexity.
Editors see toolbar buttons, dialogs, layout cards, image fields, and a media picker. They can select text and use a floating BubbleMenu for formatting. They can choose a two-column or three-column layout without remembering Bootstrap classes. They can add tabs and preview the first panel before saving.
The code stays strict underneath:
That split is why I like this implementation. The UI feels forgiving, but the saved output is controlled.
Security was not optional
Rich text editors are dangerous when the save path trusts whatever the browser sends back.
We added a dedicated rich-text sanitizer around public rendering. It uses DOMPurify with an explicit allowlist of tags and attributes. It strips scriptable and executable markup before content reaches React raw HTML sinks. It also normalizes Instagram embed data and removes blocked URL protocols from URL-valued attributes.
The render tests cover the cases that matter for an ecommerce page builder:
That is the difference between “we added a WYSIWYG editor” and “we can let people use it in production.”
The branch history tells the real story
The first commit was large: 18 files changed, 6,282 insertions, 187 deletions. It added Tiptap dependencies to both storefront apps, a 3,000-line editor component, more than 1,100 lines of editor SCSS, render tests, admin controls, layout handling, and the sanitizer path.
Then came polish. `d092141d` improved the HTML block editor and navigation interactions. `320591ec` added translation coverage in English, Swedish, and French, removed a media-picker hook, hardened editor behavior, and made tabs more flexible. `2c7928b9` deduped media-library images by ID.
That is the real pattern with editor work. The first version proves the editor can exist. The follow-up commits make it usable.
Where Tiptap helped most
Tiptap helped in three places.
First, it made the editor core boring. We did not need to invent selections, commands, undo/redo, keyboard behavior, or floating menus. The React integration and StarterKit gave us a stable base.
Second, it let us model ecommerce-specific blocks without hiding them in brittle string manipulation. Custom nodes and commands gave buttons, images, columns, tabs, and embeds a real shape.
Third, it let us keep our rendering contract. We could store and render HTML because the public storefront already depends on HTML blocks, while still using structured editor content internally where it makes sense.
That combination is rare. Many editors are easy until you need custom output. Many custom editors are flexible until you need a normal writing experience. Tiptap sits in the useful middle.
The tradeoff
Tiptap does not remove product decisions.
You still have to decide what content types are allowed, what HTML survives, how images are selected, how links are validated, how pasted content behaves, how translations work, how the public render path sanitizes content, and how much freedom merchants should have.
For a blog editor, Tiptap can be quick. For an ecommerce PageBuilder, most of the work lives around Tiptap: legacy compatibility, render tests, media workflows, accessibility, SEO, translations, and guardrails.
That is fine. A good headless editor should give you primitives, not pretend your business rules do not exist.
My takeaway
I would use Tiptap again for this kind of work.
The implementation gave us a practical Tiptap React editor without throwing away the existing PageBuilder system. Merchants get a safer editing surface. Developers keep predictable HTML. SEO-critical content stays crawlable. The storefront does not depend on a fragile client-only rendering trick.
That is the standard I want for ecommerce admin tools: simple on the surface, strict in the output, and boring enough to trust after the first launch.
