Vue SPA SSR preview url

I’m working on integrating the new Vue SDK. I’m using Nuxt server side rendering and I’m trying to get the Experience Manager overlay to work. I’m passing the page object to the component with the initialize function from the spa-sdk with the following config:

options: {
live: {
cmsBaseUrl:
‘-url-/site’,
spaBaseUrl: process.env.VUE_APP_LIVE_SPA_BASE_URL
},
preview: {
cmsBaseUrl:
‘-url-/site/_cmsinternal’,
spaBaseUrl: ‘/site/_cmsinternal?bloomreach-preview=true’
}
},

However, the preview in the Experience manager is still pointing to the production url of the resource manager instead of using _cmsinternal. Could this have something to do with the newly integrated rewrite rules in version 14.2?

1 Like

Hey @Rbbrtoo,

Are you using UrlRewriter with the recommended configuration from our documentation?

The setup you are trying to configure is deprecated and will not work in the next major release. I would recommend using the latest approach without UrlRewriter. You can enable that as it is described here.
Then, the configuration should be like:

{
  cmsBaseUrl: process.env.VUE_APP_CMS_BASE_URL
}

where VUE_APP_CMS_BASE_URL is http://localhost:8080/site.

Best,
Michael

1 Like

Hi @dokmic

Ah. So it is only accepting one config url from version 14.2? Then think an update of the documentation is in order :slight_smile: --> https://www.npmjs.com/package/@bloomreach/spa-sdk#configuration

Thank you, I have it working now :slight_smile:

@dokmic the above configuration change indeed helped. We do get, what seems te be very random, CORS errors. Sometimes it works, sometimes it fails.

Access to XMLHttpRequest at '.../site/resourceapi/' from origin 'VUE_APP_BASE_URL' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

While we do have this configured at the root mount in the hst:responseheaders.

We’re working within 14.2.0.

Any ideas what might cause that?

Hi Yves,

Is it a normal GET request (to the CMS host without _cmsinternal but
with a ‘token’ header?) that fails due to CORS headers?

What do you have configured for hst:responseheaders? Perhaps this:

hst:responseheaders: [‘Access-Control-Allow-Origin: *’]

Can you test it with browser caching disabled? I am curious whether
that helps since that might give us an idea what is wrong and how to
fix it. Thus the request returns from the cms domain but without the
right Access-Control-Allow-Origin set, right?

Regards Ard

Hi Yves,

Did you get it to work? Does it still fail sometimes? If possible, let us know so we can try to improve the CORS headers if the problem is on our end

Regards Ard