We implemented the preview feature of prismic.
On the localhost domain, everything works as excepted, but once the application is deployed and accessed through a domain, the page is reloading every second.
We seem to have two cookies :
the first one with the name io.prismic.preview is set by the /preview endpoint we had to implement. Here are its parameters:
C’est fait :“Tue, 16 Jun 2020 10:01:15 GMT”
Dernier accès :“Tue, 16 Jun 2020 10:02:26 GMT”
Domain :“.test.io”
Expiration / Durée maximum :“Tue, 16 Jun 2020 10:31:09 GMT”
HostOnly :false
HttpOnly :false
Path :“/”
SameSite :“None”
Secure :false
Taille :135
the second one with the name io.prismic.preview is set with the domain example.test.io with a Session expiration and reloads every second. Here are its parameters:
What’s happening here is that the cookies weren’t cleared correctly when you exited the preview.
The solution here is to make sure that you exit the preview correctly by click the ‘X’ button in the preview module, this will clear the cookies in the browser.
We already cleared the cookies and other browser storage completly and manually.
We tried with Firefox and Chrome, but the problem is the same. I don’t know what is refreshing our page. And when we prevent the browser from refreshing, we can see in the storage tab of our browser that the second cookie keeps refreshing each second. The only script that we believe is setting the second cookie is the prismic script we integrated, following the documentation. The first cookie is set only once thanks to the /preview endpoint we implemented.
To give a bit more information, we use the javakit in the backend providing the preview endpoint.
Would you have a diagram (like a sequence diagram) or any kind of description of the technical steps happening from the click on the preview button to the display of the wanted page version ? We want to investigate which phase is not working to correct whatever we could be doing wrong.
I think there is a misunderstanding, we do not know what the sequence of calls and operations is with the prismic preview feature. So we expected you could give us a sequence diagram of what is happening between the moment we click on the preview button in the prismic interface, and the display of our page.
No we don’t have diagram on hand, but essentially what happens is that Prismic generates a preview token with the draft version of document you’re working on and live versions of every other document.
It sends this through the browser as a cookie to your Domain that you configure in the ‘previews’ section of your repository settings, specifically the preview route that you defined.
Then when it hits this path ‘/preview’ the script that should be used in this a path will pass the cookie to the previewSession function which will retrieve the preview token from the token parameter in the query string.
It will then call the Prismic development kit with this token and the linkResolver will retrieve the correct URL for the document being previewed and redirect to the given URL.
Here’s an example with our starter springmvc framework example.
Ok, so this is the sequence we implemented, and the preview endpoint seems to be doing its job according to the cookie parameters we showed in our first message.
Now, as our page is constantly reloading and it doesn’t seem to come from our code, we are wondering if it comes from the browser (according to some configuration or context), or from the prismic script we need to set on our pages (this one <script async="" defer="" src="//static.cdn.prismic.io/prismic.js?repo=<project_name_that_we_actually_set>&new=true"></script> )
From a quick search through the prismic.js code, we can see a window.location.reload, that seems to be used through a “reloadOrigin” function that is called several time throughout the code. Could you tell us in which cases this function is triggered so we can see if we set a context triggering this function indefinitly ?
Except, when you look into the browser console, the prismic script is giving this warning :
Prismic Toolbar
window.prismic.endpoint is deprecated.
Please remove your current Prismic Toolbar installation and replace it with
<script async defer src=//static.cdn.prismic.io/prismic.js?repo=example-repository&new=true>
</script>
For complete documentation on setting up the Prismic Toolbar, please refer to
https://prismic.io/docs/javascript/beyond-the-api/in-website-preview
We tried using the script async defer line with the endpoint in case it was the reason of the reloads, but the page still refreshes indefinitly and the warning comes back
I think we found the problem, the /preview endpoint was creating the ‘io.prismic.preview’ cookie. I imagine this was necessary in a previous version of the preview. So we had 2 preview cookies because the script seems to do this part now.
The reason we have this old code is we updated a library we build over the prismic java kit. The feature wasn’t used anymore, so we didn’t see the problem come.
Ok, we don’t have reloads anymore, but our next problem is we can’t retreive the io.prismic.preview cookie in our requests to our backend.
The io.prismic.preview cookie has the HostOnly attribute, and as the backend processing this cookie is under another host, the cookie is not forwarded.
Previously, as we were setting this cookie ourselves, we did not have this attribute, so the preview was working (even though the page was reloading).
We will add specific code to the proxy to set the ref from the cookie as a simple header, but this is an weird patch. Is there another way to obtain this ref ? Is this attribute necessary for this kind of information ?
Note that outbound requests from our backend doesn’t need to go through the proxy.
I can tell you there is definitely no other way to get this ref other than the cookie, but I’m not sure if about the attribute or whether previews can work with proxies (though I think not).
So I’ve passed the question to the devs to see if I can get more clarification. I’ll let you know when I have more information.
At the end, the cookie value is sent to our API in the query string of your request as a ref. So if you can send the ref outside of the cookie to recreate your query with the ref in the cookie in the querystring this should work.
You can also pass it as a header to your proxy and recreate the query.