Expand my Community achievements bar.

Don’t miss the AEM Skill Exchange in SF on Nov 14—hear from industry leaders, learn best practices, and enhance your AEM strategy with practical tips.
SOLVED

ContextHub problem with 6.4 Service Pack 4

Avatar

Level 2

Hello,

We have just installed Service Pack 4 in our servers and ContextHub is now failing to show Ui Modes.

We are getting this error in the Chrome console, while trying to edit a Segment (Audience):

Uncaught TypeError: window.injectContextHubUI is not a function

The segmentation is not working at all within our pages, and the segmentation toolbar is also not being displayed while previewing content.

Anyone knows a solution for this?

(Edited: by the way, I am migrating from 6.4 SP3)

1 Accepted Solution

Avatar

Correct answer by
Level 2

Hi guys,

I finally found the cause and a solution for the problem.

I don't know why, but the guys here (programmers) have used the keyword "let" in some Javascript code ("let" was introduced in ECMAScript 6).

It was working fine before SP4, but a simple change in our code to "var", making the code complaint with old Javascript versions, solved the problem.

The code was in a custom implementation of a Store, inside the following JS file:

/apps/myproject/components/contexthub/stores/mycustomstore/store.mycustomstore.js

View solution in original post

8 Replies

Avatar

Employee

You need to make sure that ContentHub  was included to a Page Component: Setup ContextHub

Also, you can try to recompile clientlibs: How to force a recompilation of all Sling scripts jsps, java, and sightly in AEM 6.4

Avatar

Level 4

As part of 6.4.4.0 release notes [0], there was an update to Jquery library. you might want to check if there isn't a conflict in jquery libraries.

Note from release notes:

Migrate contexthub to jquery 3. NPR-28397: Hotfix for GRANITE-19902

[0]

AEM 6.4 Service Pack Release Notes

Avatar

Level 2

Hi Guys, I am still not able to use ContextHub with AEM 6.4 SP4.

I have tried to load various clientlibs, including the following:

- granite.query

- granite.utils

- cq.jquery

- cq.wcm.foundation

- cq.wcm.foundation-main

It works correctly under no-SP, SP1, SP2 and SP3.

Avatar

Employee

Hello,

I do not see any issue with the editing of Audiences or loading of we-retail contexthub in 6.4 Sp4.

However, there is another issue with the /etc/cloudsettings.styles.css/libs/settings/cloudsettings/legacy/contexthub request throwing 500 intermittently which is resolved in Sp6 (NPR-29946).

Is there any error in the logs?

Regards,

Vishu

Avatar

Level 2

Hi dhaliwal,

You are right, the We.Retail uses the default ContextHub Path and Segments Path.

If I change my project to use the default ones (like in We Retail) then the segmentation toolbar displays correctly while editing Audience (Segments) and also while authoring my Pages.

But in our case, we are using custom Ui Modes. We need to change those paths in page/audience configuration.

Avatar

Level 2

Looking up in the error logs, the only thing that I could see is this error:

==> error.log <==

25.09.2019 15:28:24.189 *WARN* [0:0:0:0:0:0:0:1 [1569436104123] GET /editor.html/conf/myproject/settings/wcm/segments/novo.html HTTP/1.1] org.apache.sling.caconfig.resource.impl.def.DefaultConfigurationResourceResolvingStrategy Ignoring reference to /conf/myproject/settings from /conf/myproject/settings - Probably misconfigured as it ends with '/settings'

I don't know if it relates to the Contexthub problem.

Avatar

Correct answer by
Level 2

Hi guys,

I finally found the cause and a solution for the problem.

I don't know why, but the guys here (programmers) have used the keyword "let" in some Javascript code ("let" was introduced in ECMAScript 6).

It was working fine before SP4, but a simple change in our code to "var", making the code complaint with old Javascript versions, solved the problem.

The code was in a custom implementation of a Store, inside the following JS file:

/apps/myproject/components/contexthub/stores/mycustomstore/store.mycustomstore.js

Avatar

Level 1

Our application is relying heavily on ECMAscript 6 but we believe this is not the common error that triggers this javascript error. To solve it, we loaded the following clientlib in our component customerheaderlib.html