feat: register heading tags as server-side block elements#173
Merged
Conversation
ep_headings2 already registers h1-h4 + code as block elements in the editor (aceRegisterBlockElements). It did NOT register them on the server-side content collector (ccRegisterBlockElements), so any HTML import path treated those tags as inline -- and adjacent <h1>/<h2>/<code> blocks merged into a single pad line. Fix: re-export the new ccRegisterBlockElements function from ep_plugin_helpers' lineAttribute factory (added in ether/ep_plugin_helpers#14) and wire it up via ep.json. This treats h1-h4 + code as block elements on the import side too, matching their editor behavior. Bumps the ep_plugin_helpers minimum to ^0.5.2 (the version with the new export). Test added covers the regression: a pad with adjacent <h1> and <h2> (no separator) survives a setHTML/getHTML round-trip with each heading on its own line and no merged 'AlphaBeta' content. Refs ether/etherpad#7568 -- this is the missing piece for the DOCX/HTML round-trip story landing in core.
ⓘ You've reached your Qodo monthly free-tier limit. Reviews pause until next month — upgrade your plan to continue now, or link your paid account if you already have one. |
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.
Wires the new server-side
ccRegisterBlockElementshook (added inether/ep_plugin_helpers#14) so the importer treatsh1–h4andcodeas block elements, matching whataceRegisterBlockElementsalready does on the editor side.Why
Etherpad core has two independent block-element registries: an editor-side one driven by
aceRegisterBlockElementsand a server-side one driven byccRegisterBlockElements. ep_headings2 only registered the editor side, so contentcollector treated<h1>/<h2>/<code>as inline on the import path and merged adjacent ones into a single pad line. This bit native DOCX import inether/etherpad#7568: mammoth produces<h1>A</h1><h2>B</h2><p>C</p>, the importer mergedAandBinto one line, and the round-trip lost the structure.What
static/js/shared.js: re-export the newccRegisterBlockElementsfromlineAttribute.ep.json: wire it as a server-side hook.package.json: bumpep_plugin_helpersminimum to^0.5.2(the version with the new export).static/tests/backend/specs/exportHTML.ts: regression test asserting that an adjacent-headings pad (<h1>Alpha</h1><h2>Beta</h2>) survives a setHTML / getHTML round-trip with each heading on its own line and no merged "AlphaBeta" content.CI runs against etherpad core's content collector with this plugin installed, so the new test exercises the full server-side path.
Refs
ether/etherpad#7568.