New Edit Content shows every Site's Site Key as "System Host"

Problem Statement

When the Host content type is opened in the new Angular Edit Content experience, the Site Key field renders the literal value System Host for every site, regardless of the site's real hostName. The site's correct name still displays everywhere else (breadcrumb, site selector, Site Browser title), so the wrong value is visible only inside the editor — and inside the JSON that editor serves.

Reproduced on a stock demo.dotcms.com instance after switching the Host content type to the new editor, so this is not environment- or data-specific. Browser: Chrome, macOS.

Observed

View as JSON on the default Site returns two keys that are contractually required to be equal, holding different values:

"host":         "SYSTEM_HOST",
"folder":       "SYSTEM_FOLDER",
"hostName":     "System Host",   // wrong: the name of the PARENT host reference
"hostname":     "default",       // correct
"title":        "default",       // correct
"isDefault":    true,
"isSystemHost": false

Why these two keys must match

Host.getMap() defines hostname as a straight copy of hostName, and has said so since the initial trunk import (e8ef584ec9, 2012-03-22):

@JsonIgnore
public Map<String, Object> getMap() {
    Map<String, Object> hostMap = super.getMap();
    // Legacy property referenced as 'hostname' while really is 'hostName'
    hostMap.put("hostname", hostMap.get("hostName"));
    hostMap.put("type", "host");
    return hostMap;
}

dotCMS/src/main/java/com/dotmarketing/beans/Host.java:154

Note the @JsonIgnore. Jackson skips this method, so the modern JSON/REST path the new editor sits on never runs the line that keeps the two in sync. The 2012 alias was harmless for thirteen years because every consumer went through getMap(). This is the first consumer to bypass it and populate hostName independently.

Suspected root cause (needs confirmation)

Every Host contentlet lives on the System Host by definition (host: "SYSTEM_HOST"). The symptom is exactly what you would see if the editor resolved the contentlet's parent host reference to a display name and bound that to the hostName field, instead of reading the field's own stored value. That would explain why it reproduces on every site in every instance.

The specific frontend binding has not been located. This is a theory that fits the evidence, not a traced line.

Open question — does saving throw?

HostAPIImpl.java:473 rejects any save where the incoming hostName differs from the stored one unless forceExecution: true is passed:

throw new IllegalArgumentException("Updating the hostName is a Dangerous Execution, "
    + "to achieve this 'forceExecution': true property needs to be sent.");

This has not been tested. Two possible outcomes, both worth establishing early because they change the severity of this issue:

• It throws — the new editor cannot save a Host at all, even when the user changed only an unrelated field.
• It saves — worse. hostName is silently overwritten with System Host on a real site, which then fires UpdateContainersPathsJob and UpdatePageTemplatePathJob (HostAPIImpl.java:486-496), rewriting //hostname/path references across every container and page-template binding on that site. Severity should be raised to Critical.

Please test on demo, not on a customer instance.

Steps to Reproduce

1. Switch the Host content type to the new Edit Content experience
2. Go to Site Manager → Sites and open any site (the default site on demo is sufficient)
3. Observe the Site Key field reads System Host
4. Click View as JSON and compare hostName against hostname and title

Expected: Site Key shows the site's own hostName (e.g. demo.dotcms.com).
Actual: Site Key shows System Host for every site.

Acceptance Criteria

• The Site Key field in the new Edit Content editor shows the site's own hostName
• hostName and the legacy hostname alias hold the same value in the editor's JSON payload
• Saving a Host from the new editor without changing the Site Key does not trip the forceExecution guard at HostAPIImpl.java:473
• Verified against the System Host itself, the default site, and a non-default site
• The outcome of the save test above is recorded on this issue, and severity raised to Critical if the save succeeds

dotCMS Version

• Reproduced on demo.dotcms.com (current)
• Originally observed on Evergreen 26.08.19-04 (dotCMS Cloud)
• Code references verified against origin/main @ d69f054143 (2026-09-16)

Severity

High - Major functionality broken

The Host content type cannot be edited reliably in the new editor: the Site Key field does not reflect stored state, and the save path is unverified. See the open question above — this becomes Critical if the save succeeds and rewrites hostName.

Links

• Freshdesk ticket #39459
• Slack: #t1-t2-support thread

Notes

The 2012 hostName / hostname duplication is not the defect to fix here. Removing that alias is a separate and riskier cleanup — fourteen years of Java, Velocity templates and integrations may read lowercase hostname. The fix belongs in the editor's field resolution.

Found while investigating FD #39459. It was not the cause of that ticket, but it cost investigation time by presenting as data corruption on a customer's production Site.

Reproduce the issue on demo.dotcms.com and inspect the Host editor's View as JSON output. Read dotCMS/src/main/java/com/dotmarketing/beans/Host.java:154 and HostAPIImpl.java:473-496 while tracing the new Angular editor's field resolution. Done means the Site Key and both hostname values are correct, saves pass without the forceExecution guard, and the specified host types are verified.