Can't load libs/cq/ui/rte.js in publisher

[federicos727792]

Hi, this is a follow up of my comment in http://help-forums.adobe.com/content/adobeforums/en/experience-manager-forum/adobe-experience-manage....

Basically I have developed a custom component which has a dependency on cq.widgets, which in turn has a dependency on (but doesn't embed) cq.rte. This generates the following tags

<script src="/libs/cq/ui/rte.js" type="text/javascript"></script> <script src="/libs/cq/ui/widgets.js" type="text/javascript"></script>

which fail in the publisher, because /libs/cq/ui/rte.js is closed. I've tried embedding cq.rte in my component, but it didn't work.

I have 2 workarounds which I don't like:

1- Add 2 access control rules in the publisher in /libs

everyone    rep:glob=*/rte/*
everyone    rep:glob=*/rte

2- Modify /libs/cq/ui/widgets/embed to include cq.rte

None of them seem right. 

Finally my problem seems to be the same as mentioned in https://github.com/Adobe-Consulting-Services/acs-aem-tools/issues/12

But this seems like a problem a lot of people would run into. Am I doing something wrong? Any suggestions?

Thx.

[smacdonald2008]

The reason there is an issue is because the rich text editor  is meant for components dialogs and is suppose to be used for authoring - which takes place on the author instance. These APIS are not meant for publish instance. 

[smacdonald2008]

If you need a custom API for UI requirements on publish - i would look into JQuery or another JS framework and use a client lib. 

[Lokesh_Shivalingaiah]

or you can also overlay the js you need to your clientlib and then use that clientlib to get it work

[federicos727792]

> The reason there is an issue is because the rich text editor is meant for components dialogs and is suppose to be used for authoring - which takes place on the author instance. These APIS are not meant for publish instance. 

That makes sense.

Actually I don't need this on the publisher. The rte.js came with the inclusion of cq.widgets as a dependency. I had to add it to avoid getting "Uncaught ReferenceError: CQ is not defined" in the browser. Which is needed when creating my custom component:

HArtWidget.CustomWidget = CQ.Ext.extend(CQ.form.CompositeField, {

HArtWidget.CustomWidget = CQ.Ext.extend(CQ.form.CompositeField, { ...

Perhaps there's a more specific dependency to use?

Note that https://helpx.adobe.com/experience-manager/using/creating-aem-multifield-components.html mentions this, but perhaps I'm specifying it in the wrong client lib folder.

UPDATE: it's like some client libs that are only meant for the author are also used in the publisher. Note I have two cq:ClientLibraryFolder for this component. One under /apps/[project]/components/[component]/[clientlib] and other under /etc/clientlibs/[project]/[clientlib]. Having specified the dependencies in the /apps one didn't help.

[edubey]

Hi, 

Few point:-

CQ Widget library does not load in publish instance this is why you got CQ undefined error.

You are not allowed to use these in publish and In author, you are free to use these. 

Because component are never use to author in publish these libraries are not available there. Everything is authored in author and then pushed to publish.

[federicos727792 · Accepted solution]

Hi,

Thanks for the comments, but I still don't understand how this could ever work.

When my custom component adds a dependency on cq.widgets it will always fail in the publisher, whether I use it or not (since embed didn't work).

As mentioned above my component includes the following javascript:

HArtWidget.CustomWidget = CQ.Ext.extend(CQ.form.CompositeField, { 

Which is also evaluated in the publisher for the purpose of assigning the variable, even if it is never used. CQ.Ext is created by cq.widgets, but, as mentioned, I can't add that dependency.

The only way I see this could work is by having the authoring part completely separated from the rest of the component, so that the publisher never tries to execute any part of it. For example by using a different category which is only included using WCMMode.fromRequest(request) != WCMMode.DISABLED

However I've barely seen any reference to this, which is why I think I'm still doing something wrong. What am I missing here?

[edubey]

So you created a component, 

Authored in author instance

Pushed / Replicate / Activate the page to publish instance

When viewing the page in publish instance, you are seeing this error. can you please confirm this ?

if your JS which is having above code belongs to any client lib, please load this client only in edit mode, Check the mode via JSP 

[federicos727792]

> When viewing the page in publish instance, you are seeing this error. can you please confirm this ?

Yes.

> if your JS which is having above code belongs to any client lib, please load this client only in edit mode, Check the mode via JSP 

Indeed, that's the last thing I tried and so far is working as expected. This means I have code like this:

if (WCMMode.fromRequest(request) != WCMMode.DISABLED) { %> <cq:includeClientLib categories="company.custom-component-author" /> <% }

[abhinavc2085585]

smacdonald2008 wrote...

The reason there is an issue is because the rich text editor  is meant for components dialogs and is suppose to be used for authoring - which takes place on the author instance. These APIS are not meant for publish instance. 

Hi smacdonald2008

I am able to access the rte.js and widget.js in publisher too when I am writing in form of http://servername:port/libs/cq/ui/widgets.js and http://servername:port/libs/cq/ui/rte.js but in dispatcher only widget.js is accessible while rte.js is giving us 'page not found' error creating issues here. it seems like the case of permission in dispatcher but as widget.js and rte.js for both path are same so path /libs/cq/ui/* is allowed in dispatcher.any .Please help in fixing that issue.

[federicos727792]

You can probably hack your dispatcher configuration file to enable access to /libs/cq/ui/rte.js, but it seems to me that you have hacked your publisher and now need to hack your dispatcher accordingly.

This is one of the reasons why I didn't like these workarounds in the first place. Probably a security concern and extra environment configuration per installation. I would suggest fixing whatever is requesting these urls in the first place. In case of components I've provided a solution in my answer.

Good luck.