The versioned clientlib models is loaded in all the pages , except one page (in footer)

[chaitanyaAlwala]

1837

AEM Version 6.5.5(SP5) No Dispatcher: Java : jdk 11: ACS Commons : 4.3.0

We Use Versioned clientlibs in our project ,we called a clientlib js files with versioned clientlibs from a footer component(Structure component - loads in all pages) we use static templates . The versioned clientlib models is loaded in all the pages , except one . the latest code from footer is rendered in that page as well , still the JS call is normal one.

Note: All the other JS and CSS from other clientlibs are loaded with version(As expected) The changes are reflected , except this one All the Pages with same STATIC Template are loading as expected.

expected : clientlib-angularAem.77fa5c32a9ebef23326baa9397bb8aa1.js Actual : clientlib-angularAem.js

[joerghoh]

How is this JS library at this specific location loaded? What's the markup you use to load it?

[chaitanyaAlwala]

@joerghoh Sir Please find the actual component code and the page source :

footer.html component

<app-footer></app-footer>
<!-- importing js files mentioned in 'js.txt' file of clientlib-angularAem -->
<sly data-sly-use.clientlib="/libs/granite/sightly/templates/clientlib.html" />
<sly data-sly-call="${clientlib.js @ categories='clientlib-angularAem'}"></sly>

this is how footer is included in template(static )

            <sly data-sly-resource="${'footer' @ resourceType='XXX-aem-project/components/structure/footer'}"></sly>
        </div>
    </div>

</body>
</html>

in page : view source :

<app-footer></app-footer>
<!-- importing js files mentioned in 'js.txt' file of clientlib-angularAem -->
<script type="text/javascript" src="/etc/designs/XXX-aem-project/clientlib-angularAem.js"></script>
        </div>
</div>

in page : view source : Working as expected :

<app-footer></app-footer>
<!-- importing js files mentioned in 'js.txt' file of clientlib-angularAem -->
<script type="text/javascript" src="/etc/designs/XXX-aem-project/clientlibangularAem.77fa5c32a9ebef23326baa9397bb8aa1.js"></script>
        </div>
    </div>

[justinedelson]

In general, what I have seen in the past is when the rewriter "stops" processing elements at some point in the HTML (and the reference to "footer" suggests that this is towards the end of the HTML document), it is because there is some HTML that is so malformed that the HTML parser used by the rewriter just gives up. Last I looked, the rewriter doesn't log anything when this occurs, but if you take the generated HTML and put it into an HTML validator (e.g. https://validator.w3.org/) it indicates where the problem lies. In this case, however, it might be simpler to identify the components which are specific to the non-rewritten page and look at those individually to see what kind of malformed HTML is being produced.

[chaitanyaAlwala]

In general, what I have seen in the past is when the rewriter "stops" processing elements at some point in the HTML (and the reference to "footer" suggests that this is towards the end of the HTML document), it is because there is some HTML that is so malformed that the HTML parser used by the rewriter just gives up. Last I looked, the rewriter doesn't log anything when this occurs, but if you take the generated HTML and put it into an HTML validator (e.g. https://validator.w3.org/) it indicates where the problem lies. In this case, however, it might be simpler to identify the components which are specific to the non-rewritten page and look at those individually to see what kind of malformed HTML is being produced.

Sir @justinedelson I have checked the generated HTML , the page with issue has 30 errors , and other pages which are fine has around 15 errors , is there any specific number of errors the HTML parser will tolerate?

[justinedelson]

is there any specific number of errors the HTML parser will tolerate?

@chaitanyaAlwala it has been several years since I ran into this type of problem, but my memory is that it is not about the number of errors, but rather the type of error, i.e. the parser just can't handle certain kinds of errors.

[chaitanyaAlwala]

is there any specific number of errors the HTML parser will tolerate?

@chaitanyaAlwala it has been several years since I ran into this type of problem, but my memory is that it is not about the number of errors, but rather the type of error, i.e. the parser just can't handle certain kinds of errors.

Sir @justinedelson Thanks , it worked after correcting few HTML errors. Sir @joerghoh Thanks