AEM ClientLib Loading Issue: clientlib Not Loading During New Page Creation

[Ben_Hu]

Hello,

I'm developing a client library named image.editor and including it in the extraClientlibs list for page properties and component.
This client library uses the dialog-loaded event to retrieve image alternative text from DAM assets.

The implementation works correctly when:
1. Editing a component dialog.
2. Editing page properties of an existing page.

However, it fails to load and execute when creating a new page.

I've observed that the clientlib .js file is not loaded during the new page creation process, whereas it loads successfully when editing an existing page.

The extraClientlibs list on the page includes:
cq.common.wcm
core.wcm.components.page.v3.editor
cq.wcm.msm.properties
granite.contexthub.configuration
cq.siteadmin.admin.properties
core.wcm.components.image.v3.editor
image.editor

Is there something I might be missing, or is it generally not recommended to include a custom clientlib like this in the page's extraClientlibs for dialog functionality?

Any suggestions would be greatly appreciated. Thank you!

[giuseppebaglio]

If your dialog JavaScript is needed in dialog for page creation, consider including it in a clientlib category that is always loaded by the page creation dialog in the Siteadmin/admin context, such as cq.gui.siteadmin.admin.pagepreview or another admin-level category, rather than relying solely on page or component extraClientlibs.

[SantoshSai · Accepted solution]

Hi @Ben_Hu,

When you create a new page, AEM opens a Create Page Wizard inside the Sites Console, not in the page editor.
This dialog runs in the SiteAdmin (or Page Wizard) context, not in the page context - so the extraClientlibs defined in the page component (like image.editor) are not yet loaded.

Only after the page is created and opened for editing does AEM load:

cq.common.wcm
core.wcm.components.page.v3.editor
core.wcm.components.image.v3.editor
image.editor

from the page’s component definition.

Move your script to a console clientlib

Instead of attaching via extraClientlibs to a page component, include your clientlib under the console clientlibs used by the page creation wizard.

Example:

/etc.clientlibs/image.editor

Then, in your js.txt, add your logic to listen for dialog events globally:

$(document).on("dialog-loaded", function (e) {
  // logic for alt text population
});

Attach your clientlib via category:

<clientlibCategory>cq.siteadmin.admin.properties</clientlibCategory>

or in your own category that you overlay into the Site Admin console.

OR
Dynamically detect context

If you must keep image.editor under the page component, you can lazy-load it when the dialog opens:

if (Granite.author && !window.imageEditorLoaded) {
    $.getScript("/etc.clientlibs/image.editor.js").done(function() {
        window.imageEditorLoaded = true;
        console.log("image.editor loaded dynamically");
    });
}

This ensures it still executes even if not included by extraClientlibs.

OR

Hook into the page creation wizard

If your logic specifically targets new pages, consider overlaying:

/libs/wcm/core/content/sites/createpagewizard.html

and including your clientlib category there (using a custom clientlib loader in the console).

[ManviSharma]

Hello @Ben_Hu ,

this happens because when you create a new page, AEM loads a lightweight dialog frame that doesn’t include the page’s extraClientlibs. Those are only pulled in once the page actually exists and is opened in the editor.

To fix it, you can move your image.editor clientlib to a more global authoring category (like cq.authoring.dialog), or load it dynamically when the dialog opens. That way, it’ll work both during new page creation and while editing existing pages.

[Ben_Hu]

Yesterday, I tried using /libs/granite/ui/components/coral/foundation/includeclientlibs and replaced the dialog-loaded event with foundation-contentloaded. This change allowed it to work within the “create page” flow without affecting the existing component behavior in the edit page.

Next I’ll try SantoshSai’s approach later on.

Thanks all for responses and explaining the underlying behavior of the “create page” action.