An original workshop page has a short introduction above a booking panel and detailed arrival instructions below it. Staff should edit both text regions while the booking panel stays outside the editors. Saving whichever editor was last focused would lose one part of the intended update.
Mount two editors on the intended regions
Retain the page layout and mark only the text regions:
<div id="workshop-intro" class="workshop-copy">
<p>Bring a sketchbook to the morning session.</p>
</div>
<aside class="booking-panel">Booking controls belong here.</aside>
<div id="workshop-arrival" class="workshop-copy">
<p>Use the entrance beside the bicycle rack.</p>
</div>
In an application where TinyMCE is already loaded with its existing license configuration:
await tinymce.init({
selector: '#workshop-intro, #workshop-arrival',
inline: true,
menubar: false,
toolbar: 'undo redo | bold italic'
});
The matching elements produce separate instances. Do not assume that Undo in the arrival instructions also reverses an introduction edit. If the two regions must behave as one document with a shared Undo history, that is a different editor architecture to evaluate before choosing this arrangement.
Use block elements such as div for these regions. Do not keep the old textarea merely because the classic setup used one. Also avoid selecting the whole workshop container: that would include the booking panel in the editable area.
Move content styling into the page
An old classic-mode content_css rule can style the iframe while leaving the actual workshop page unchanged. For inline editing, load the page's styles normally and scope the copy rules:
.workshop-copy {
font: 1rem/1.6 system-ui, sans-serif;
max-width: 46rem;
}
.workshop-copy p {
margin-block: 0 1rem;
}
Inspect generic host selectors too. A broad div rule that seemed harmless outside a classic iframe can now affect editable content. Conversely, a copy-specific rule should not change booking controls. The TinyMCE content CSS guide explains which document owns a rule in each mode.
Check plugin compatibility before carrying the old configuration across. TinyMCE's current inline instructions state that Comments requires the sidebar and classic mode. An inline migration needs a deliberate decision about that feature, rather than a CSS workaround for a missing sidebar.
Capture both regions for one workshop record
After initialization, the record's existing Save handler can collect a snapshot:
function captureWorkshopCopy() {
const intro = tinymce.get('workshop-intro');
const arrival = tinymce.get('workshop-arrival');
if (!intro || !arrival) {
throw new Error('Workshop editors are not ready.');
}
return {
introductionHtml: intro.getContent(),
arrivalHtml: arrival.getContent()
};
}
Send that object through the application's normal authorized save route, associated with the workshop's real record ID. The function only captures content; it does not save it. If the application needs both fields committed together, implement that as a single record update in the persistence layer.
Avoid tinymce.activeEditor for this snapshot. Its identity follows focus, while this operation needs two named fields regardless of the current cursor. Also keep navigation blocked or explicitly handle unsaved changes while a save is in flight; destroying an editor does not complete a storage request.
Review the combined change as a visitor
In a development workshop record, change the introduction to request a pencil and the arrival text to identify reception. Save both, leave, and reopen that same record. Both edits should remain, and the booking controls should be unchanged.
Then review the visitor page at a narrow width with authoring controls absent. The introduction belongs above booking and the arrival instruction below it. Keeping those two fields attached to the right workshop matters more than whether the floating toolbar looked correct during the edit.