Exported ZIP from Page Exporter missing /var folder when using cq:designPath | Community
Skip to main content
G
Glory_EsthefannyRo
April 7, 2025

Exported ZIP from Page Exporter missing /var folder when using cq:designPath

  • April 7, 2025
  • 1 reply
  • 657 views

Hi Adobe Community,

We’re using the default page exporter template in AEM to generate ZIP files. In one of our sites, the page has the cq:designPath property set, and the exported ZIP includes the /etc/designs folder — but does not include the /var folder, which results in missing clientlibs needed to render the page as a static HTML.

Interestingly, in the same instance, another site that doesn’t use the cq:designPath property correctly exports the ZIP including the /var folder.

We’re trying to understand:

  • What’s the expected behavior when cq:designPath is used in a page?
  • How can we ensure that the /var folder is also included in the export when using cq:designPath?
  • Is there a way to explicitly define that in the export template nodes?

Additionally, the official documentation (https://experienceleague.adobe.com/en/docs/experience-manager-65/content/sites/administering/contentmanagement/page-exporter) mentions as a troubleshooting step that /var/contentsync can be deleted and will regenerate. However, we tried this in both a local and DEV environment, and the folder did not regenerate.

Any guidance or additional documentation about each available node in the export template (especially the design and rewrite nodes and their required properties) would be very helpful.

Thanks in advance!

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

1 reply

SantoshSai
Community Advisor
SantoshSaiCommunity Advisor
Community Advisor
April 16, 2025

Hi @glory_esthefannyro,

Here, I have tried to answer your questions:

What’s the expected behavior when cq:designPath is used?

When a page has the cq:designPath property set, AEM assumes the page is using the classic design-based clientlibs from /etc/designs/.... In that case:

  • AEM prioritizes pulling in resources from /etc/designs, including the design-specific clientlibs, CSS, JS, and templates.

  • Because of that, it often skips pulling in modern clientlibs from /var/clientlibs, assuming the design includes what’s needed.

So yes — this behavior is expected, but it's a bit hidden. It’s AEM’s way of saying “you’re using classic design, so I’ll fetch that instead of modern /var/clientlibs”.

How can we ensure /var is included when using cq:designPath?

To include the /var folder in the export ZIP even when cq:designPath is set, you have a couple of options:

Option A: Customize the export template

Overlay the export template under /apps/wcm/template/export and ensure the includePaths property includes /var.

Here’s how:

/apps/wcm/template/export/<your-template>/jcr:content
  - includePaths (String[]) = [/var, /etc/designs, /apps, ...]

You can even be more specific and say /var/clientlibs to only grab that portion.

Option B: Manually add a rewrite or include node

Add a node under your export template to explicitly include the required clientlibs from /var.

Example:

apps/wcm/template/export/<your-template>/jcr:content/rewrite/varClientlibs
  - jcr:primaryType = nt:unstructured
  - pattern = /var/clientlibs(/.*)?
  - replacement = /var/clientlibs$1

This tells the exporter to rewrite/include paths matching /var/clientlibs.

 

Hope that helps!

Regards,
Santosh

Santosh Sai
    G
    Glory_EsthefannyRoAuthor
    April 16, 2025

    Hi @santoshsai , thank you very much for your detailed response.

    We followed your suggestion and created the jcr:content node under our export template at /etc/contentsync/templates/default/jcr:content, including the includePaths property and even a rewrite node for /var/clientlibs. However, unfortunately, it didn’t work as expected — the ZIP file still doesn’t include the /var resources.

    We noticed that the default structure of the template includes nodes like page, design, defaultDesign, and a foundation.clientlibrarymanager.js, but not a jcr:content node by default. Could you please confirm if we're supposed to create it manually, and if so, whether there’s any additional configuration required for AEM to recognize it?

    Thanks in advance for your help!

    SantoshSai
    Community Advisor
    SantoshSaiCommunity Advisor
    Community Advisor
    April 16, 2025

    Hi @glory_esthefannyro,

    You’re right — by default, the export templates under /etc/contentsync/templates/default don't contain a jcr:content node. However, AEM does expect one to exist if you're customizing behavior like includePaths, rewrite, etc.

    Yes, you need to create it manually if you're customizing the export behavior. Here's what you should ensure:

    • The node must be named jcr:content.

    • Its jcr:primaryType should be cq:PageContent (or nt:unstructured depending on usage).

    • Under jcr:content, define properties like includePaths or child nodes like rewrite, excludePaths, etc.

    • Ensure your template is referenced by the page or operation you're exporting.

    Important: If you’re using /etc/contentsync/templates/default, but exporting from a path that references a different template or no template at all, AEM may fall back to its own default logic — and ignore your changes.

    Pro tip: You can debug this by looking at the jcr:content of the page you're exporting and checking the cq:template property — make sure it points to your custom export template path.

    Santosh Sai
    Terms & ConditionsAccessibility statement

    Loading footer...