fix(edit-content): allow saving code files with warnings in file editor (#36543)

[adrianjm-dotCMS]

Proposed Changes

Fixes #36543 — the file/code editor (binary & file fields, both the new Angular editor and the legacy Dojo web component) silently refused to save code that contained editor warnings.

Root cause

@materia-ui/ngx-monaco-editor registers itself as an NG_VALIDATORS for the content control and reports any marker on the Monaco model as a single monaco form error — with no severity attached. Since the JS/TS language service produces informational diagnostics (e.g. 'x' is declared but its value is never read. for unused vars/params, very common in jQuery-style theme scripts), the form became INVALID and onSubmit() returned early. The template only surfaced errors for the name field, so Save appeared to do nothing with no feedback.

Screen.Recording.2026-07-13.at.2.12.00.PM.mov

Fix

• Saving is now blocked only when the content has a genuine Error-severity marker (real syntax errors). Hints/warnings (unused vars, unreachable code, etc.) no longer block Save.
• When a real syntax error is present, the editor shows a red outline (using PrimeNG's --p-form-field-invalid-border-color invalid token, with a Lara red.400 hex fallback for the legacy Dojo bundle) and a message below it (dot.file.field.error.syntax), which replaces the mime-type hint.
• name validation and any future non-monaco content validators still block as before.

Files

• dot-form-file-editor.component.ts — severity-aware #hasBlockingErrors() + $hasSyntaxError signal driven by the control's statusChanges.
• dot-form-file-editor.component.html — red-outline class binding + error message / mime-type toggle.
• dot-form-file-editor.component.scss — --error modifier.
• Language.properties — new dot.file.field.error.syntax key.
• dot-form-file-editor.component.spec.ts — 7 unit tests covering the severity gate (hint/warning save, error blocks, mixed blocks, recovery, name gate).

Checklist

• Tests (unit)
• Translations (new message key)
• Manual QA on legacy Dojo editor

Notes / follow-up

The same over-eager validator pattern also exists in DotEditContentMonacoEditorControlComponent (JSON / text-area / WYSIWYG-code fields), where it can block saving/publishing the whole contentlet. Out of scope for this PR — worth a separate follow-up.

🤖 Generated with Claude Code

This PR fixes: #36543

[claude]

Claude finished @adrianjm-dotCMS's task in 1m 48s —— View job

---

Code Review

• Read PR diff (.ts, .html, .scss, spec, Language.properties)
• Analyze severity-gate logic and template toggle
• Check test coverage
• Post review

---

Solid, well-documented fix. The core design decision — reading real Monaco markers directly at submit time via #hasErrorSeverityMarker() rather than trusting the presence of the opaque monaco form error — is correct, and the save gate (#hasBlockingErrors()) never depends on the $hasSyntaxError signal being current, so save correctness is decoupled from any UI-refresh timing. Below are non-blocking observations only.

New Issues

• 🟡 Medium: dot-form-file-editor.component.ts:188 — The $hasSyntaxError signal (which drives the red outline + error message) is refreshed only from contentField.statusChanges. The gate logic is sound because onSubmit() re-reads markers fresh, but the visual indicator relies on ngx-monaco-editor re-emitting statusChanges on every marker change. Assumption: when markers change while the control's validity value stays constant (e.g. [Error] → [Error, Warning], both keep the single monaco error so status stays INVALID), the validator still re-runs and re-emits. What to verify: an INVALID→INVALID marker transition — the specs only cover []↔INVALID transitions (which always emit), so this path is untested. If ngx doesn't re-emit on same-status marker changes, the outline could briefly go stale. Worst case is a stale visual, never a wrong save.

• 🟡 Medium: dot-form-file-editor.component.ts:326 (#disableEditor) — During upload the form is disabled, which fires statusChanges with DISABLED; the subscription then re-reads markers and can keep $hasSyntaxError true, leaving the red outline on a disabled editor mid-upload. Cosmetic, but you may want to clear the flag while disabled.

Notes (non-blocking)

• #hasBlockingErrors() inspects only nameField and contentField directly rather than form.invalid. Equivalent today (the group has exactly those two controls), but if a third control is ever added it won't be gated. A brief comment noting this intentional narrowing would help future maintainers.
• Fallback in #hasErrorSeverityMarker() (returns false when monaco/model is unavailable) is safe: the monaco error itself originates from Monaco, so markers can't exist without Monaco being loaded — no path where a real error slips through unblocked.
• Good call flagging the same over-eager validator in DotEditContentMonacoEditorControlComponent as a follow-up rather than expanding scope here.

Test coverage for the severity gate is thorough (hint/warning save, error blocks, mixed blocks, recovery, name gate). Adding one INVALID→INVALID marker-transition case would close the gap noted above.

Nothing here blocks merge.
• issue-36543-file-code-editor-save-blocked-by-warnings

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request