You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The generated xf-web-varation template has an OOTB policy reference of cq:policy="<site>/components/page/policy". This is not considered a valid "selection" option by AEM's template editor, as policies for <site>/components/xfpage must be stored under a policy subpath of that same type (<site>/components/xfpage).
To see this in action
Create a default project from archetype
Go to Template editor
Select the "Web Variation" XF template
Go to edit "Page Policy"
Notice that the editor shows "New Policy" b/c it is unable to choose the linked policy
To save, you must name a new policy, at which point the policy will be created in the correct location
The impact of this appears to mostly just be confusion, as the "invalid" policy link still appears to work. However, having this invalid link does open up the possibility of a customer scenario where at first changes (e.g. new clientlibs) added to the standard page policy meant for pages automatically updates Experience Fragments as well, but then after someone makes an update to the Experience Fragment page policy (triggering a new, separate policy to be created) changes to the standard page policy no longer impact Experience Fragments.
The text was updated successfully, but these errors were encountered:
The generated
xf-web-varation
template has an OOTB policy reference ofcq:policy="<site>/components/page/policy"
. This is not considered a valid "selection" option by AEM's template editor, as policies for<site>/components/xfpage
must be stored under a policy subpath of that same type (<site>/components/xfpage
).To see this in action
The impact of this appears to mostly just be confusion, as the "invalid" policy link still appears to work. However, having this invalid link does open up the possibility of a customer scenario where at first changes (e.g. new clientlibs) added to the standard page policy meant for pages automatically updates Experience Fragments as well, but then after someone makes an update to the Experience Fragment page policy (triggering a new, separate policy to be created) changes to the standard page policy no longer impact Experience Fragments.
The text was updated successfully, but these errors were encountered: