Cette conversation a été verrouillée en raison de son inactivité. Veuillez créer une nouvelle publication.
Niveau 1
Niveau 2
Se connecter à la communauté
Connectez-vous pour voir tous les badges
Cette conversation a été verrouillée en raison de son inactivité. Veuillez créer une nouvelle publication.
Hi All,
We have a template[not editable templates], wherein iparsys is included in the page component of the template in body.html.
<sly data-sly-resource="${'xyz' @ resourceType='wcm/foundation/components/iparsys'}"></sly>
In 6.4 environment, on creating a page out of this template it appears as seen in screenshots below. When an extra parsys comes up, in author mode it overlaps some other component, thereby hiding that component and creating issues.
In 6.2 environment, on creating a page out of this template the extra parsys doesnt come up.
Did some investigation from the UI perspective,as we were suspecting our component css conflicts with the 6.4 OOTB css. Tried multiple things, but no luck.
Whereever, iparsys is included [i.e, in header, footer] this issue is to be seen in 6.4.
Tried multiple things for quite some time, but no luck.
Any thoughts/pointers on this will be really helpful.
Vues
Réponses
Nombre de J’aime
Hi All,
Any thoughts on this will be helpful.
Vues
Réponses
Nombre de J’aime
In AEM 6.4 - no need to work with IParsys to create header, footer, etc. This was pre AEM 6.4/6.3 way of doing things.
Its much better practice to create footer and header components and then drop them into editable templates and lock them in place in the editable template. This reflects best practice in AEM 6.4.
Vues
Réponses
Nombre de J’aime
THis development use case is also shown in the Weekend Tutorial -- Getting Started with AEM Sites - WKND Tutorial
Strongly recommend that you change to editable templates and footer and header components instead of trying to use IParsys.
Vues
Réponses
Nombre de J’aime
Hi,
As scott mentioned, we are going away from iparsys approach with editable templates, content fragments etc.
However, with this issue did you look at the implementation of iparsys itself ? or inspect the extra parsys element and see where it belongs to.. Let me also see if I can reproduce this issue on my local and get back to you.
Vues
Réponses
Nombre de J’aime
For users of older AEM versions whom are used to using IPARSYS to build out AEM Sites with header and footers - the new way is to use Editable Templates. You can watch the Guided Journey in Experience League to learn more about editable templates and policies.
Also posted on my blog -- Scott's Digital Community: Guided Journey for Experience Manager on Editable Templates
Vues
Réponses
Nombre de J’aime
Hi Lokesh,
Thank you for your reply.
- In our case, we are not using editable templates, content fragments etc.Normal templates[i.e, templates present under /apps] are being used.
- Guess you are referring to looking at the implementation details of OOTB /libs/wcm/foundation/components/iparsys. Haven't checked. Will look at it and see if we get something. In case, you have some findings w.r.t this, please let us know.
- On inspecting the parsys element which is overlapping with the globalnav component, below is seen
<div data-type="Editable" data-path="/content/xyz/jcr:content/globalnav/*" tabindex="0" draggable="false" data-text="Drag components here" title="Inheritance Paragraph System - HTL [Root]" class="cq-Overlay cq-Overlay--component cq-droptarget cq-Overlay--placeholder" style="top: 40px; left: 0px; width: 1583px; height: 46px;"></div>
Not able to locate as to from where it is coming.
Would be really helpful if you can provide pointers/thoughts based on your analysis.
Vues
Réponses
Nombre de J’aime
"we are not using editable templates" - that is too bad as Editable Templates are now considered best practice with AEM 6.4. Using this approach (use of IPARSYS) is not documented nor will it be as its not the approach that product teams want ppl to take with AEM 6.4 development.
Vues
Réponses
Nombre de J’aime
Vues
Réponses
Nombre de J’aime
Hi Arun
Checked with 'foundation/components/iparsys', but still the same.
Vues
Réponses
Nombre de J’aime
Hi, we are facing something similar, did this happen to you using either 6.4.0, 6.4.1 and 6.4.2? Does this happen also using Classic UI?
Vues
Réponses
Nombre de J’aime
Ronny - why not make use of the features 6.4 exposes as opposed to doing things the "old way". Use of editable templates to give an AEM site similar look and feel (headers/footers, etc) is best practice.
Vues
Réponses
Nombre de J’aime
Sure Scott, but the first phase is the upgrade step, before then moving to the latest features.
I am aware that Classic UI is deprecated, but we need to ensure that we can perform the upgrade without affecting current site, or at least to know that by fixing a couple of configurations or lines of code will suffice to get the iparsys working fine.
Vues
Réponses
Nombre de J’aime
If you deploy your 6.2 site to 6.4 - what is happening?
Vues
Réponses
Nombre de J’aime
Reviewing, we are having CSS issues with some components, the dialog is in the DOM but with CSS rules that prevent it to be displayed:
element { position: absolute; z-index: 11000; visibility: visible; left: -10000px; top: 20px; width: 800px; }
I am still researching why some of them have such rules applied.
Vues
Réponses
Nombre de J’aime
Can you check that in your custom code you have not overlayed any OOTB libs files ?
Similar issue was faced where below 2 files were overlayed, post merging both (latest libs file + custom code), parsys issue got resolved.
/libs/wcm/core/components/init/init.jsp
/libs/foundation/global.jsp
It should not be replicable in fresh AEM 6.4 instance, when we dont have any overlayed code.
Vues
Réponses
Nombre de J’aime
Vues
Likes
Réponses