Plugin Author
Aert
(@aahulsebos)
Hi @rogermuffler,
Could you try two settings, and see if this helps?
Under settings;
– Enable safe mode
– Disable automatic cookie scan
Please let me know if any of these two helps in your configuration,
regards Aert
Hi Aert,
Thanks for your quick response. I’ve just enabled safe mode and did what I was usually doing when it broke in the past. All worked fine so far, although it still felt a bit slow when saving and quitting the builder.
Disabling automatic cookie scan on top didn’t seem to change anything. Would you suggest to keep both changes? I’ll tell my colleague to test it as well as soon as possible, hope it stays good :-))
Thanks and regards,
Roger
Plugin Author
Aert
(@aahulsebos)
Hi @rogermuffler,
You can keep the automatic cookie scan disabled, but safe mode should be off.
Could you tell me more about any console errors during this process, or specific post requests?
I did a quick test with our testversion, but no issues. Is it a specific page, or everywhere?
regards Aert
Hi Aert
Thank you for your reply. It doesn’t seem to be on a specific website, it can occur on every page as soon as i work in the frontend with the Divi builder.
I’ve translated a mail my hoster has sent me the last it occurred:
***
Unfortunately, we have noticed that the following account
puts excessive load on the server’s system resources.
The excessive processor and memory utilization
leads to massive degradation of the environment
and affects all customers on the same system.
This is not a matter of excessive network traffic,
but the required resources of the system
itself.
High load because of extremely many accesses by the IP address XXX.XXX.XXX.XX
We have blocked the mentioned IP address for the protection of all customers.
It is a Swiss IP address of <Provider X>. Therefore, we inform you about the incident. Here’s one example:
XXX.XXX.XXX.XX – – [16/Dec/2020:14:29:33 +0100] “POST /wp-admin/admin-ajax.php?type=errors&nonce=a44ddf6fbb&action=cmplz_store_console_errors HTTP/1.0” 200 652 “https://…” “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36”
***
Does this help?
Thanks an Regards,
Roger
Hi @rogermuffler,
The request you posted from the logs is a request used by complianz to check if there are jquery errors on your site. It seems that because there are a lot of errors, and a lot or requests, this request is posted a lot of times.
It sounds a bit as if the pagebuilder is doing a lot of requests itself, which are each causing the error tracker from Complianz to trigger a post to the server with an error log.
The error checker itself is not disabled when safe mode is enabled. As you describe it, safe mode resolved your issues. This suggests the issue you experienced is not related to the error tracking directly. So I’d like to focus first on the pagebuilder/safe mode issue which should be easy to fix.
Complianz uses a function to detect if a pagebuilder is active. If so, safe mode should enable by default. Possibly this is not working at the moment.
What I’d like to do first, is check if we can fix this. To do this, I need the url used by Divi when in pagebuilder mode. I don’t need the domain name itself, only the part that is appended as variable at the end. Could you post that here?
Hi @rogierlankhorst,
Thanks for stying with the problem! This is the URL-bit after the domain when divi page builder is activated:
/?et_fb=1&PageSpeed=off
Just a short remark: I’m not 100% sure if save mode resolved my problem, it just hasn’t occurred since then 🙂
Regards
Roger
@rogermuffler the et_fb parameter is caught in the function which checks if a pagebuilder is active, so the cookie blocker should not be active when editing.
Maybe it was just a glitch, I haven’t had any other reports like this. Maybe it’s a good idea to monitor this, and if it happens again we can dive deeper into this.
Hi @rogierlankhorst,
I’m pretty sure it was not just a glitch, as the problem has occurred several times (for me and for a colleague of mine).
But I wasn’t able to reproduce it in the last few days, so maybe the problem has solved itself… Anyway, if it happens again I’ll get back to you.
Thanks again for your help
Roger
@rogermuffler We have just merged a fix which I’m pretty confident was also the cause of your issue.
The function that fires a call to the server to track if there are jquery errors, is now limited to not preview, builders, cookie scans, etc. We had another thread where this branch resolved the issue. We will be releasing this update soon.
Hi @rogierlankhorst
Thank you for the good news, sounds great. When does it make sense to check again, do you already have a timeline?
Regards,
Roger
@rogermuffler should be released this week, or early next week at the latest.
