Expand my Community achievements bar.

Dive into Adobe Summit 2024! Explore curated list of AEM sessions & labs, register, connect with experts, ask questions, engage, and share insights. Don't miss the excitement.
SOLVED

HTML rendering of XDP forms not working after patching AEM to 6.5.14

Avatar

Level 2

Has anyone having issues with rendering XDP forms as HTML after installing the latest SP14?

We are using on-prem AEM Forms on JEE and after patching our lower env. instances we have this problem: XDP forms are not loading (spinning loading loop circle) or showing 404 errors in different browsers (FF, Chrome, EDGE).

NikP_0-1666105010245.png

No errors are recorded in the logs but we see some WARNs in the CRX error.log like this:

 

18.10.2022 09:55:37.609 *WARN* [10.253.34.177 [1666104937581] GET /lc/aem/formdetails.html/content/dam/formsanddocuments/HSPH_AF_10304/1.0/Forms/AF10304.xdp HTTP/1.1] com.adobe.acs.commons.util.BufferedServletResponse Prevent committing the response, it will be committed deferred, i.e. once this buffered response is closed

 

18.10.2022 09:55:40.745 *WARN* [RequestProcessor-2] com.adobe.document.XMLFormService ALC-XTG-032-033: [192] Bad value: '$template.#subform.#edge' of the 'usehref' attribute of 'edge' element ''. Default will be used instead.

 

We do have an open case on this with Adobe Support but haven't yet got any solution for this issue.

 

Any help from this community will be highly appreciated.

 

Thanks

 

 

1 Accepted Solution

Avatar

Correct answer by
Level 2

Thanks to everyone that replied to my question in the post above.

 

Here is what we believe is the root cause for this issue in our environment.

There is some type of incompatibility or regression issue between the last SP14 packages and ACS AEM Commons version 4.7.2. This is the version we have on our Authors and Publishers. Once the ACS Commons packages are removed from CRX all is working and the XDPs are again rendering as HTML.

 

Regards

Nik

View solution in original post

11 Replies

Avatar

Employee Advisor

is it happening for all the xdp's?

Avatar

Level 2

Yes, this is what I'm told by the form developers testing the instances after the patching.

Avatar

Employee Advisor

@Nik-P can you upload the xdp to the forms and documents page and try to preview it as HTML

 

http://localhost:8080/lc/aem/forms.html/content/dam/formsanddocuments

 

this will narrow down if something is broken at HTML WS or rendering profile.

 

check the browser console and network logs as well

Avatar

Level 2

Hi @Mayank_Gandhi ,

We've tried uploading a new xdp via Forms and Documents. It still does not render. It shows the loading graphic spinning eternally. We have also tested with the default profile vs our own rendering profile and still XDP would not load/render.

Checking the browser debugging console and NW logs doesn't reveals something obviously wrong or maybe i don't have the expertise to interpret. 

It does show some 'Unaught SyntaxError: "" literal not terminated before end of script' if that is providing any hint(s):

NikP_0-1666113281690.png

 

Avatar

Employee Advisor

@Nik-P Let me put 14 on my instance and test. Is it with all the xdp?

Avatar

Level 2

It does happens with all of the XDPs...

FYI I was able to “trick” the AEM and to load and render a XDP form if I manually edit the URL and add this ‘?type=xdp’ at the end after the 'jcr:content' like in this example:

http://devaem:8080/lc/content/dam/formsanddocuments/.../Forms/FormName.xdp/jcr:content?type=xdp

Avatar

Employee Advisor

@Nik-P 

Basis the information provided, please ensure that the correct AEMFD package is installed. You can check the OS and version here[0]. You can reinstall the forms package to ensure no package (especially *-forms-* package) is left uninstalled.

 

Next, try to preview the form as HTML in designer once. I hope you're testing the form with the default profile URL below- http://server:port/content/xfaforms/profiles/default.html?contentRoot=crx:///path/to/template/direct......

 

Do these XDPs have large records, or is data added at runtime? If you haven't tested, please render the form without data.

 

Lastly, to narrow down the issue- whether it's client or server side, you can disable JS on the browser side and try to render the form.

 

Is the form shared over the ticket? If so, please DM the ticket#

 

[0] - https://experienceleague.adobe.com/docs/experience-manager-release-information/aem-release-updates/f... 

Avatar

Level 2

Hi @Pulkit_Jain_ 

Thanks for your reply and for trying to help with this issue.

It is affecting all XDP forms in our case and we have not attached any forms to the ticket (Case ID: E-000744597).

Case Title: XDP forms problem with render as HTML format

We have installed the following packages in the order as listed here:

JEE patch 6.5.0-0053

OSGI service pack 6.5.14

OSGI Forms package 6.0.772

OSGI Compat package 2.0.46

 

I just tried to render XDP form on Chrome with JS disabled and the result is this message: 'This application requires javascript.'

 

 

Avatar

Correct answer by
Level 2

Thanks to everyone that replied to my question in the post above.

 

Here is what we believe is the root cause for this issue in our environment.

There is some type of incompatibility or regression issue between the last SP14 packages and ACS AEM Commons version 4.7.2. This is the version we have on our Authors and Publishers. Once the ACS Commons packages are removed from CRX all is working and the XDPs are again rendering as HTML.

 

Regards

Nik

Avatar

Level 2

To be more precise there is no need to completely uninstall and remove the ACS AEM Commons 4.7.2 packages.

The cause of the issue was narrowed down to conflict with the AEM Environment Indicator settings for the Browser Title (which is part of the ACS AEM Commons).

The simple fix in our environment(s) was to remove the AEM Environment Indicator settings for the Browser Title in the OSGi Web Console. Once this was done everything works again and the XDP forms are rendering as HTML again.

Here is the screenshot for everyone's reference:

NikP_0-1666799411036.png