AEM 6.5 experience fragment wcmmode

[NitroHazeDev]

Hi ,

I was playing around with experience fragments and noted that if a component even core component with a check on wcmmode.edit is done in sightly , and is included on XF, it does not pick up the mode in preview or disabled mode(view as published) within XF if the component is included within a building block. 

This impacts the webpage when wcmmode disabled when XF is included with a building block. 

eg, I want a component to have a message if authoring mode or wcmmode is edit and in preview or disabled mode the component should not show the message on an XF and when XF is included on webpage and if the components are part of building block within the XF

1.  if the component is added within the building block , the same behavior is noted and, if you check with wcmmodes.isTouchAuthoring , it works only on wcmmode disabled and NOT preview .. 

Observed this behavior OOTB core components , should !wcmmode.disabled be used ? 

[Sady_Rifat]

Hello @NitroHazeDev ,
The wcmmode for Experience Fragment on a page differs from its editing mode.
There is a similar thread that describes why it behaves like that and how can you get the expected solution: https://experienceleaguecommunities.adobe.com/t5/adobe-experience-manager/when-putting-a-custom-comp... 

[NitroHazeDev]

Hi @Sady_Rifat  thank you for the response .. I apologize firstly that I missed details and mistyped the question .. confusing the observations .. updated the original question .. the link as I see the answer is in relation to author or pub ? And not modes ,  .. also if sightly does not wonder if backend will via models with approach listed  .. I managed to find the option above using istouchauthoring, that works for view as published but not preview .. not sure if recommended .. gonna test today for !criteria but since it occurs OOTB , wondering any way vs models ? 

[Sady_Rifat]

Hello @NitroHazeDev ,

The answer is related to the author's instance. The Slightly code doesn't detect the wcmmode edit because the XF is rendered from a different path on the page. When you want to use wcmmode edit it's always like/behaves view as publish mode.
The Solution is linked to a Model class since according to the best practice every associate component will have a model class.

Again since slightly depends on page mode,  you cannot rely on this, you need to find the actual instance by Java.

[NitroHazeDev]

thanks @Sady_Rifat  but unable to understand .. my bad .. so here we have no way to identify the mode for components in an XF via sightly but do we have a way via Java and will it result in the same as via sightly ? This code is runmode which wouldn’t work but I know there is an api on wcmmode .. do we know it would work ? I could try it out if you haven’t and update ..

[Sady_Rifat]

Hello @NitroHazeDev ,

See this chart, where the same component is on a page. Once it drops the page directly by parsys, another one comes from XF. This result is from the Slightly.

Now, you can question why it happened. The answer is by XF the component is already rendered and comes to the page. Using slightly code you will get a wrong output.

So, in my solution, I suggest using the Sling Model class. Then why will Java work?
Java sends the output based on the server instance, not in frontend page mode.

I hope it will make a clear visibility for your confusion. If not, please don't hesitate to ask.

[NitroHazeDev]

Thanks @Sady_Rifat  .. but the ask is in page mode vs server instance .. as the authors would prefer testing for disabled or preview mode. Also, I see that wcmmode works for edit on XF where message is displayed on edit mode  but issue is when it is within a building block that is when it does not pick up mode. 

[Sady_Rifat]

Exactly that's the case,

When you edit an experience fragment you basically edit a page. (ex: experience fragment page template). On that page, wcmmode behaves as a regular pattern. And you get your desired value.
Note: Here I am talking about (/aem/experience-fragments.html/content/experience-fragments/aem-project-demo/us/en/site/header/master) 

Now come to the sites (/sites.html/content/aem-project-demo/us/en)

In this page template, you dropped an XF component and referenced the XF variation link.
Now what happens, the XF component renders the variation and shows you as a publish mode. Because it's already rendered and referenced from another source.
That is why in the author mode all wcmmode properties give publish value.

Maybe you already noticed that, in the XF section you cannot edit any component, the full section is disabled.

[NitroHazeDev]

I think there’s a confusion and pardon me if I have not stated it clearly @Sady_Rifat .. the modes are picked incorrectly when the component is within building block  and if not within building block I see it works fine .. no corner case noticed so far 

[Sady_Rifat]

@NitroHazeDev Yes you are right.
Actually, from our development perspective, it seems incorrect but according to AEM architecture/concept, this is expected.

[NitroHazeDev]

Thanks @Sady_Rifat , raised an adobe ticket to get them to give us a verdict on it, will update

[kautuk_sahni]

@NitroHazeDev Did you find the suggestions from Sady helpful? Please let us know if more information is required. Otherwise, please mark the answer as correct for posterity. If you have found out solution yourself, please share it with the community.

[NitroHazeDev]

@Sady_Rifat  the adobe engineers came back saying they have a ticket raised for it to resolve after internal discussions  

SITES-16835.