Hi @Ali @sandra
I am creating custom fields in the Course context using the Code field type.
Initially, everything works as expected. However, after adding a second custom field of type Code, the field becomes uneditable in the UI.
Interestingly, the behavior appears inconsistent—depending on the heading/group the field is placed under, it may become editable again. This suggests there may be an issue with how Code-type fields are handled or rendered in certain contexts.
This appears to be a bug. Please see the attached screenshots for reference.
I would appreciate it if you could investigate this issue.
Thanks.
Hi @Ali @sandra
Did you find what could be causing this?
I appreciate the support.
Thanks
I was able to trace this issue to the CodeEditor.template.php file.
Root cause:
Each Code-type custom field outputs a <script> block that defines a global setupEditor() function and then calls it. When multiple Code fields are present on the same page, this function is redefined multiple times, causing conflicts. As a result, only one Ace editor instance initializes correctly, and the others fall back to static (non-editable) content.
Additional issue:
Each script initializes Ace using a hardcoded element ID, rather than supporting multiple instances dynamically.
Fix:
I removed the shared global setupEditor() function and replaced it with a self-contained initialization block (IIFE) per field. Each instance now:
-
Initializes its own Ace editor using its unique ID
-
Syncs content to the hidden textarea correctly
-
Avoids duplicate initialization
-
Cleans up safely on HTMX page swaps
This allows multiple Code-type custom fields to coexist and remain editable across different groupings and layouts.
Result:
-
All Code fields render as editable editors
-
No conflicts between instances
-
Works reliably with dynamic form rendering
Happy to share the patched template if helpful.
