Currently in our project, the 404 error page are customized for diff locale and brands.
The redirect is happening via IIS, where all our URL redirect logic is handled like url shortening etc. No issue here.
Problem statement : Current 404 page redirect logic is handled via model class extending WCMUsePojo where we query aem for 404 page and return the appropriate 404 page content which is html by calling this page as resource and fetching the html content and returning this through a getter method via model class. This rendering of html page content initially was done via jsp page but the problem is coming when it is converted to sightly. With jsp page logic it works fine.
The sample jsp content is :
<%@page session="false" contentType="text/html; charset=utf-8" %><%
%><%@taglib prefix="cq" uri="http://www.day.com/taglibs/cq/1.0" %><%
%><%@include file="/apps/corporate/global.jsp" %><%
%><cq:defineObjects/><%
%><jsp:useBean id="componentBean" scope="page" class="corporate.core.components.page.globalerrorpage.GlobalErrorpageComponentBean" /><%
%><jsp:setProperty name="componentBean" property="slingResponse" value="<%=slingResponse%>" /><%
%><jsp:setProperty name="componentBean" property="slingRequest" value="<%=slingRequest%>" /><%
%><c:if test="${not componentBean.disabledMode}">global errorpage. no content will be shown in author mode</c:if><%
%><c:if test="${componentBean.disabledMode}">${componentBean.errorpageContent}</c:if>
and
Its sightly equivalent is :
<div data-sly-use.componentBean="corporate.core.components.page.GlobalErrorpageComponentBean" data-sly-unwrap>
<sly data-sly-test="${!componentBean.publish}">global errorpage. no content will be shown in author mode
</sly>
<sly data-sly-test="${componentBean.publish}">${componentBean.errorpageContent}
</sly>
</div>
Model class GlobalErrorpageComponentBean:
getErrorpageContent(final String errorpagePath) throws ServletException, IOException {
final SlingRequestProcessor requestProcessor = this.getService(SlingRequestProcessor.class);
final RequestResponseFactory requestResponseFactory = this.getService(RequestResponseFactory.class);
final HttpServletRequest request = requestResponseFactory.createRequest("GET", errorpagePath + ".html");
final ByteArrayOutputStream outByte = new ByteArrayOutputStream();
final HttpServletResponse response = requestResponseFactory.createResponse(outByte);
requestProcessor.processRequest(request, response, this.getResourceResolver());
final String pageContent = new String(outByte.toByteArray(), CharEncoding.UTF_8);
return pageContent;
}
The errorpagePath is found by query which gives appropriate result like "/content/project_global/en_CN/404".
During rendering via sightly, we get the html page content in network tab preview section, but it is not rendering on the page. the page has white screen. The request status in network tab is 404, but the body doesn't load at all. Even the page title is not 404 which is property "htmlTitle" of the 404 error page.
Can anyone help here?
Views
Replies
Total Likes
@MaheshKPati suggest to avoid render HTML dom content via slightly / pojo, rather create a standard HTML 5 as per your requirement and pass slightly/Pojo data to corresponding dom element
I have tried this html change in our GlobalErrorPage body.html, to which IIS redirect user to in 404 cases.
In body.html ,
Also I have referred https://experienceleaguecommunities.adobe.com/t5/adobe-experience-manager/custom-error-handler-not-w...
so i would like to tag @vijayk87714775 and @arunpatidar for there opinion.
Hi @MaheshKPati
I would go for dispatcher to configure all the error pages, (including language/multisite), please check
If you are saying that you are seeing the expected html in network tab as well as correct response code and it is just not rendering on the browser, I think it might be some missing config on IIS side.
Could you try checking the response headers once, especially the Content-Type header ?
.
@MaheshKPati Did you find the suggestions helpful? Please let us know if you require more information. Otherwise, please mark the answer as correct for posterity. If you've discovered a solution yourself, we would appreciate it if you could share it with the community. Thank you!
Views
Replies
Total Likes
I am exploring the areas as suggested, will revert back once found appropriate solution.
Views
Replies
Total Likes
Views
Likes
Replies
Views
Likes
Replies