Dear all,
Recently we upgraded our AEM servers from 6.1SP1 to 6.2, and we have a component to build a multiple form container, it is normally on 6.1, however after we upgrade the instance to 6.2, the page always crashed in editor mode.
I have analyzed and found the reason is following marked with bold font. If I replace it with data-sly-resource="${page}", several of the pages could be displayed in edit mode.
For example,
Below is the page displayed in editor mode in 6.1
Start of page 1
<Several components and content>
End of page 1
Start of page 2
<Several components and content>
End of page 2
Start of page 3
<Several components and content>
End of page 3
But in version 6.2, after I replace the source with data-sly-resource="${page}",which means, there is no overriding of the resourceType. the page is displayed as following, it is not
Start of page 1
End of page 1
Start of page 2
<Several components and content>
End of page 2
Start of page 3
<Several components and content>
End of page 3
But if I revert the source code to original as following, the page will be loaded and then crashed.
So could any one help me on this issue or give suggestion on it? is there any change in 6.2 comparing to 6.1? looks like something wrong in javascript loading/running.
<sly data-sly-use.container="container.js">
<form id="form${container.id}" method="POST" action="${properties.url}" data-thankyou="${properties.thankyouUrl}" data-analytics="${properties.analyticsEventName}">
<sly data-sly-list.page="${container.pages}">
<div data-sly-test.isEdit="${wcmmode.edit}">Start of page ${page}</div>
<div class="${isEdit || page=='1' ? 'active': ''} form-page" data-sly-resource="${ @path=page, resourceType='foundation/components/parsys'}"></div>
<div data-sly-test="${isEdit}">End of page ${page}</div>
</sly>
</form>
<sly data-sly-use.libs="${'/libs/granite/sightly/templates/clientlib.html'}">
<sly data-sly-call="${libs.js @ categories='multipage-form'}"></sly>
</sly>
<script type="text/javascript">
$(function(){
if($.fn.multiPageForm!=='undefined') {
$('#form${container.id @ context = "styleString"}').multiPageForm({
nextPageClass: 'next',
prevPageClass: 'prev',
submitPageClass: 'submit'
});
}
});
</script>
<sly data-sly-use.template="${'/apps/aia/widgets/templates/reload-page.html'}">
<sly data-sly-call="${template.reload @ isTouchAuthoring=container.isTouchAuthoring}"></sly>
</sly>
</sly>
Thanks in advance
Cheers.
Solved! Go to Solution.
Views
Replies
Total Likes
It seems the issue only happened when we nested put particular components together, like we have one component "grid-control-2" and another one "grid-control-3" which are used for controlling page layout to generate two / three grids in one container / section and it was truly built in accordance with Grid System of BootStrap, but when we put the g-c-3 into g-c-2, the page is crashed in 6.2, that never happened in 6.1.
I've posted this issue to Adobe help support as well, will keep update.
Cheers,
Views
Replies
Total Likes
Try packaging this component into a package and then install on a fresh 6.2 instance. I do not think there is a problem with the component. Something looks wrong with the environment.
Views
Replies
Total Likes
Can you share this with us to reproduce the issue ?
~kautuk
Views
Replies
Total Likes
It seems the issue only happened when we nested put particular components together, like we have one component "grid-control-2" and another one "grid-control-3" which are used for controlling page layout to generate two / three grids in one container / section and it was truly built in accordance with Grid System of BootStrap, but when we put the g-c-3 into g-c-2, the page is crashed in 6.2, that never happened in 6.1.
I've posted this issue to Adobe help support as well, will keep update.
Cheers,
Views
Replies
Total Likes
An update for this issue, as collaborated with daycare support, finally they find the root cause and problem is due to heavy computation of the Cell Search Path (CSP).
So they provided us an hot-fix for this particular issue, and it is solved now.
Views
Replies
Total Likes
An update for this issue, as collaborated with daycare support, finally they find the root cause and problem is due to heavy computation of the Cell Search Path (CSP).
So they provided us an hot-fix for this particular issue, and it is solved now.
Views
Replies
Total Likes
Views
Likes
Replies
Views
Likes
Replies