Thank you for credentials, is this happening to specific pages? I was able to open a couple of your pages in Cornerstone without encountering the issue. Try using the incognito/private mode of the browser and see if the issue is still happening.
Weirdest thing is that it might be working with some browser, not others, and not every computer. So it looks like a browser issue to me, but we keep having a 404 on cs-vendor.map
I’ve completly reinstalled my web server (with webinoly)
Out of the box fresh config, no fancy thing, no caching enabled, browser history completly cleaned
I can create a page, but a few minutes later, can’t edit it. Still the same error :
I’m sorry, but if support can’t help me on that one, we’re done.
I can’ t use a theme for my business if I can’t trust it, and if support can’t help with those kind of issue.
What would my customer think if I recommand a theme that’s so instable ?
If you have lvl 2 support, I’ll be glad to have a bit of help here.
Erreur dans les liens source : request failed with status 404
URL de la ressource : https://www.luvy.fr/wp-content/themes/pro/cornerstone/assets/dist-app/js/cs.js?ver=2.1.7
URL du lien source : cs.map
This does not pose any issue at all. cs.map is not as critical as any part of the editor. This file is a source map.
A source map provides a way of mapping code within a compressed file back to it’s original position in a source file. This means that – with the help of a bit of software – you can easily debug your applications even after your assets have been optimized. The Chrome and Firefox developer tools both ship with built-in support for source maps.
You can ignore these errors.It will not affect anything in the builder or in the theme features. If you do not want to see the errors, you will have to disable Source maps in your browser settings.
Meanwhile, you are experiencing an issue in the editor because of your caching plugin, Comet Cache. In the plugin settings, you have enabled the HTML COMPRESSION feature and it has caused the editor not to load the preview. I went ahead and disabled this feature, cleared the cache and now the editor preview is loading. Please see my screenshot in the secure note.
I’m not BSing you guys, I know you’re all really dedicated to your job, but this issue is completly pissing me off.
I’ve spent hours yesterday checking at all technical issue I could think of, but can’t figure out why this bug is so inconstant.
For post 1246, it was working the first time, then didn’t after a few minutes…
What’s going to happen if my customer has the very same issue ? He’s just goign to think I’m providing poor service, and that the tool I’m very fond of are completly rubbish.
It’s a risk I can’t take. I’ve been working with company in France for 8 years now, only because I’m dedicated to provided the best service I can, with the best flawless products.
Please check at the video and let me know what you think
You’re right about the issue, it’s loading but sometimes not.
The same goes for Firefox and Safari, it sometimes loads but mostly not. That popup error will also appear if the loading process is too slow or taking time even if there is no error at all. Hence, greatly affected by performance and loading speed. Unfortunately, I can’t help you with performance issues related to hosting environment. Have you tried the managed hosting? Their systems are pre-configured.
In your site, if it loads under 20 seconds, the builder preview is rendered properly. If it takes more than 30-40 seconds then the popup will appear. And this could be related to NGINX web server too and it can’t handle too much requests (in home page, it issues about 150 requests on initial load, rendering requests are excluded).
Thank you for the information. I did a great deal of testing on your website and I found an interesting thing in the 1246 post.
I started to edit the current stuff and for example, add random numbers at the end of the text elements and it worked with no issue. Then I added a new Row and added an Alert box, No problem! then I tried to use the options of the Alert box to change the colors and the stuff, in the middle of the changing I see that there is no refresh of the iFrame and my changes do not reflect. Meanwhile, I tried to save and the progress bar of the save just went to the end but was there for a while.
Then I went to another tab and was away for 5 minutes, when I came back I see that the iFrame is reloaded and save happened. I hit the save button and tried to refresh about 5-6 times and when I checked the blog I see nearly the same amount of the attempts to save:
So what I conclude from the test above is that your server and hosting caches the requests and serve them all together and that is why you see the inconsistency.
Unfortunately, we are not server related experts and I cannot investigate more but that is something that worths the check.
To see if this is indeed a bug in Pro or a server issue (Which I am sure it is your server as we have more than 200000 installations with no problem) I suggest that you give us a backup of your website and we test it on our hosting server as we do have the hosting service:
If the site works ok on our hosting service then we will be 100% sure that is something related to your hosting service.
thank you for your response, I really appreciate the time and effort the staff is putting on that ticker, it means a lot to me.
You’ll find attached a link to DL a tarball of the website (link below in secure note).
What I don’t get is that my nginx cache is set to a strict minimum (1second here for testing purpose). And that if the server caches the request, I should have consistent result, wich I don’t. Chrome works fine, firefox doesn’t.
I use webinoly, a LEMP stack on a VPS server. Cheap and very fast. I tried a few tweak at conf file to see if I can handle caching differently, but it doesn’t change one thing : browser cache is completly disabled. And I have set all request to 1 sec caching.
So I should have consistent result, whatever the browser, but I don’t…
I’ve checked again this morning, fastCGI cache is completly disabled on this website…
I’ve asked a sys-admin to check at this issue. I’ll keep you updated on what we discover, and will document everything.
Maybe it will be usefull for other users who encounters the same issue.
Best regards and thanks again to everyone implied in this ticket
Does the working site hosted on the same web server (you’re restarting it in your video)? Or are they completely different instance? Because each instance could have different performance depending on the configuration.
And please let us know if you find something, more information will be a great help solving future issues.
