WYSIWYG editors are not always initialized on first load

[woutervroege]

Bug Description

WYSIWYG editors are not initialized on first load in dynamic field contexts (for example: repeater subfields, conditional groups, and fields revealed after interaction).
They only appear after saving the post and reloading the edit screen.

Impact

Editors see empty/plain areas instead of rich text editors while editing.
Field UX feels broken/inconsistent in repeaters and conditional logic.
Risk of bad content formatting because users may type into non-initialized fields.

Expected Behavior

Any visible WYSIWYG field should initialize immediately when it is rendered or becomes visible, including:

• initial page render
• newly added repeater rows
• fields/groups shown by conditional logic
• fields injected by async/dynamic rendering

Actual Behavior

Initialization seems to run only once for a subset of fields on load.
Fields created later or hidden-then-shown miss TinyMCE/Quicktags bootstrap until a full save + reload.

[novincode]

Hi @woutervroege , thanks for pointing that out;
This is exactly the same family of dynamic initialization issues. WYSIWYG editors (TinyMCE/Quicktags) are only bootstrapped once on page load, so any field that appears later – in a repeater, conditional group, or other dynamic context – ends up as a plain textarea.

Great catch, and you've described the impact perfectly. The good news is that the upcoming update will fully resolve this alongside #6 and #7. The fix will:

Initialize WYSIWYG editors on-demand when a repeater row is added

Re-initialize them when conditional fields become visible

Ensure proper cleanup when editors are removed (no duplicate instances)

No more save+reload just to get a working rich text editor. 🚀
Thanks again for your meticulous testing and reporting – it's hugely valuable. Keep 'em coming if you spot anything else!

Much appreciated 🙌