Component Dialog Field Not Persisting Under a Policy-Scoped Container
Your team ships a hero-banner component whose dialog stores a variant field. On the staging publish tier, authors on the /content/brandmaster site report that changing variant and saving the dialog works, but the rendered page always shows the default variant. The component's HTL reads the value via ${properties.variant}. The component is placed inside a layout-container whose policy is inherited from the page template. The same component works correctly on /content/brandmaster/landing. Debug logs show the dialog POST returns 200 and the node under cq:dialog updates. The site uses editable templates, and the page in question was created from a template that was later modified. Authors are on AEM 6.5 with the editable-template authoring UI.
1. Identify the most likely root cause and explain why the dialog save succeeds while rendering does not reflect it.
Read the worked answer
The symptom pattern-dialog POST returns 200, node updates, but rendering shows default-points to the component instance being read from a different resource than the one the author edited, or the HTL resolving properties against a proxy whose variant is absent. The strongest candidate is policy/container inheritance combined with a stale template: the page was created from a template that was later modified, so the layout-container's cq:policy mapping and the component's resource type resolution diverge. When the container's policy is inherited, the effective component resource type may resolve to a supertype whose variant default is set in the component's cq:editConfig or in a sling:resourceSuperType chain, while the authored value lives on the instance node. ${properties.variant} then falls through to the default because the instance node's variant is not on the resolved resource.
Concretely: verify with CRXDE that the instance node under the container actually has variant, and check the container's cq:policy node for a components map that remaps resource types. If the remap exists, the authored property is orphaned. The fix is to reconcile the template (re-save/publish the template so the policy mapping matches the component's resource type) or migrate the instance data, not to change the HTL.
2. What verification steps would you run before changing any code, and in what order?
Read the worked answer
Order matters because each step narrows the hypothesis cheaply before touching code:
- Inspect the instance node in CRXDE at the exact content path the author edited; confirm
variantis present and its value. This rules out a failed save. - Inspect the container's policy node (
cq:policy) and itscomponentschild; check for a resource-type remap that would causepropertiesto resolve elsewhere. - Check
sling:resourceSuperTypeon the component and any supertype; confirm where the defaultvariantis defined. - Hit the page's
.model.jsonor the component's JSON exporter to see which resource the Sling model receives-this confirms resolution at runtime without guessing. - Compare against the working page on
/landing; diff the container policy and the instance node structure. The delta is the bug.
Only after these do you consider an HTL change; the evidence usually shows the data or policy is wrong, not the template.