episerver / content-delivery-js-sdk

Apache License 2.0
22 stars 14 forks source link

On page editing in sample project question #22

Closed Borange closed 2 years ago

Borange commented 3 years ago

Hi,

First I want to say impressive work and really easy to get the sample project up and running. It seems that the onpage editing is not working. Get 214 to a file locally: http://localhost:8081/episerver/cms/latest/clientresources/epi-cms/communicationinjector.js

If I google this I get a hit to this file: https://github.com/Romanets/RestImageResize/blob/master/AppData/Modules/CMS/1.0.431/ClientResources/EPi/cms/communicationInjector.js

Maybe it can be something just on my local installation. If I then manually add (communicationinjector.js) to the project I get: Uncaught DOMException: Blocked a frame with origin "http://localhost:8080" from accessing a cross-origin frame.

When looking closer to communicationInjector script I see what it does. It tries tom manipulate an iFrame with dojo. Probably to get access to the iframe which is used i CMS edit mode. This will not work unless both frontend has the same host and portnumber for security reasons in browsers. In the sample it set to localhost:8081 //backend localhost:8080 //fronend, ie. different portnumber. Also see this stackoverflow: https://stackoverflow.com/a/25098153

Trying to summarize my question here are there other documented ways to connect and use on-page-edit functionality with Optimizely cms using content-delivery-js-sdk?

JohanPetersson commented 3 years ago

Hi, there will soon be a fix so the JavaScript file works again. Until then, you can replace latest in the URL with the CMS version and it will work, e.g. http://localhost:8081/episerver/cms/12.0.4/clientresources/epi-cms/communicationinjector.js.

On page edit is a bit of work in progress, as you have noted. We have a story in our backlog to address this. The solution is not clear yet, but one approach would be that the frontend itself would provide the CMS with the editable areas instead of the CMS trying to access the DOM across the origins. What you can do until then, is to proxy the backend through Express. This only works if your frontend is not static, i.e. has a backend as well. This is a common practice for other CMS and it's also how Microsoft has set up their SPA templates.

The current setup used to work a while back when port numbers wasn't considered as cross-origin. We're also using document.domain which is deprecated.

ansbar commented 3 years ago

@JohanPetersson The react demo site (https://github.com/episerver/Foundation-spa-react), does it suffer from the same problems? Cause it's decoupled isn't it?

JohanPetersson commented 3 years ago

Yes it does. It has a workaround in place though, where the frontend is running on a subdomain.

ansbar commented 2 years ago

@JohanPetersson We have cherry picked code from the examples but haven't got it working yet. Im trying to figure out what I have missed.

We are running on sub domains.

In editmode I have hard coded some epi attributes on a h1-tag: <h1 data-epi-edit="Title" data-epi-property-name="Title" data-epi-use-mvc="true" data-epi-property-render="none">Startpage!</h1> Not sure which I need, maybe just data-epi-edit..

Anyway, no OPE is visible on the element.

I've added the communicationinjector and its loaded. window.epi is present and ready, however I skipped the "document.domain" since its depricated.

Which part of epi should hook on to the data-epi-edit-attr? Any idea of where I have gone wrong? =)

Maybe im using the wrong epi-edit-prop..

[
   {...
"heroBlock":{
         "title":"",
         "content":"",
         "primaryButtonLabel":"",
         "primaryUrl":null
      },
JohanPetersson commented 2 years ago

I don't think it's possible to get it working, since browsers are actually honoring the deprecation of document.domain now. I.e. on-page-edit won't work without document.domain. We are however working on a solution that would work cross-origin without any hacks.

ansbar commented 2 years ago

@JohanPetersson Ok, I see. Is it the solution you're mentioning earlier, "the frontend itself would provide the CMS with the editable areas"? Do you have an idea when in time this would be available in some form?

JohanPetersson commented 2 years ago

That is one of the implementations we explore. Have no time frame to share at the moment, sorry.

JohanPetersson commented 2 years ago

Both samples are now updated with basic on-page-edit support.