WPBakery does not load

General
#1

We have checked out the previous topics wrt WPBakery and we are not utilizing RocketLoader.

We were previously using Verizon Edgecast as our CDN/WAF provider an when we transitioned over to Cloudflare we noticed that WPBakery would no longer load properly in the WP Admin. We then moved our domain back to Edgecast and it worked again.

Here’s the tricky part - we have 2 different pre-production environments that we also moved from EC to CF - and both of those environments work just fine when behind Cloudflare, but the production site does not. We have checked (and re-checked) every config available in the CF Admin area and are sure that they are all set up exactly the same between the 2 pre-prods and the prod site. The only difference we can tell is that each of our pre-prods are set up as unique sites in CF (qa.example.com and uat.example.com) and then the prod site is set up as it’s own site (example.com) and we just created a CNAME record for www.example.com.

Anyone else out there dealt with this before?

#2

Are you seeing anything in the Console Log of your browser’s Development Tools window?

1 Like
#3

Yes – we do have some console errors – but nothing in Network showing a specific js asset being blocked.

image001.png
image001.png3360×940 485 KB

#4

I wouldn’t count on a blocked asset being the issue, but those script errors may be the problem. Do the dev sites have those errors?

If you put Cloudflare into Development Mode for your site, does WP Bakery work?

#5

The dev sites do not have those console errors. We tried everything we could think of to make tweaks to CF – including putting it in Dev mode – still a no go.

#6

Last shot in this direction: From the Overview page of the Cloudflare Dashboard, click on “Pause Cloudflare on Site.” This will completely bypass Cloudflare. Give it five minutes for DNS to propagate before testing. That will show if Cloudflare is causing the problem or not.

#7

Again – this is our main website in production, and we have already moved it back to Edgecast (we need the WAF protection).

The site is now working behind Edgecast – but we have altered our hosts file locally to utilize the CF IP – this allows us to continue to test in the broken state. I think that gives the same affect that you are shooting for – agreed?

#8

Here is what we discovered as a fix for this issue.
We add the following line to our wp-config.php file

define(‘CONCATENATE_SCRIPTS’, false);

This keeps WP from concatenating script files - we are ok with this since we are using HTTP/2 anyway.

1 Like
#9

This topic was automatically closed after 14 days. New replies are no longer allowed.