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

[Glory_EsthefannyRo]

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/content...) 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!

---

[SantoshSai]

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

[Glory_EsthefannyRo]

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]

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.

[Glory_EsthefannyRo]

Hi @SantoshSai , thanks again for your support.

I’ve tried the node structure you suggested — including manually creating the jcr:content node with the proper jcr:primaryType, as well as adding both includePaths and rewrite properties. I also double-checked the cq:template property on the page, and it’s correctly pointing to our custom export template.

Unfortunately, the export still doesn’t include the /var folder.

I also reviewed the notes you shared, but so far, none of the configurations seem to trigger the inclusion of /var.

Could there be any additional property — maybe under the design or another node — that needs to be set in order for the /var folder to be generated during export?

Thanks in advance for any further guidance!