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.
Hi All,
Any thoughts on this will be helpful.
Views
Replies
Total Likes
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.
Views
Replies
Total Likes
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.
Views
Replies
Total Likes
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.
Views
Replies
Total Likes
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
Views
Replies
Total Likes
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.
Views
Replies
Total Likes
"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.
Views
Replies
Total Likes
Can you check if whether you are facing same issue with another parsys?
<sly data-sly-resource="${'xyz' @ resourceType='foundation/components/iparsys'}"></sly>
Views
Replies
Total Likes
Hi Arun
Checked with 'foundation/components/iparsys', but still the same.
Views
Replies
Total Likes
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?
Views
Replies
Total Likes
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.
Views
Replies
Total Likes
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.
Views
Replies
Total Likes
If you deploy your 6.2 site to 6.4 - what is happening?
Views
Replies
Total Likes
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.
Views
Replies
Total Likes
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.
Views
Replies
Total Likes
Views
Likes
Replies
Views
Likes
Replies
Views
Likes
Replies
Views
Likes
Replies