Or, How to Stop The Divi Visual Builder Spinning Dots of Death
Here at Webidextrous, we maintain several websites for our clients who have chosen Pantheon.io for its high-quality security and performance for WordPress and Drupal sites. We like Pantheon.io so much that we became an agency partner.
For anyone not familiar with it, Pantheon.io has rebuilt how hosting works from the ground up to support more robust and secure WordPress hosting. You can read my article about how Webidextrous creates high value for our clients via Pantheon.io on their website.
Sometimes with added security and performance come a few inconveniences. About a week ago, as I was editing a few sites that use the popular Divi theme builder by Elegant Themes, I noticed that the Visual Builder was not loading. It would begin to load, and then would get stuck on the “spinning dots” preloader.
I remembered that I had recently upgraded from Divi 4.0.5 to 4.0.6. Usually, a Divi upgrade has at least one bug that can affect most sites. So, I rolled back to 4.0.5 and that solved the issue. It was definitely the Divi 4.0.6 Visual Builder that was having problems.
But that was only a temporary solution. Eventually, I’d want to upgrade to 4.0.6 and beyond. If this issue was something more permanent and systemic, I needed to know.
The Solution (For Now)
Long story short, and after lots of trial and error and testing of the Divi 4.0.6 Visual Builder, plus many rounds with the Divi community and Elegant Themes chat support later, I had a solution in hand. I share it here with you now in case you’re a Pantheon.io agency or site owner. It may also be applicable on other hosts that choose to make the live WordPress site more secure from malware injections by making the production site 100% read-only.
- Add
/files/et-cache/to the filesystem. - Create et-content symlink pointing to
/uploads/et-cache/in/code/wp-content/per instructions from “Using Extensions That Assume Write Access” in the Pantheon Docs. - Create
/files/et-cache/via the SFTP client. - Add this to
wp-config.php.
if ( ! defined( 'FS_METHOD' ) ) define( 'FS_METHOD', 'direct' );- Update to Divi 4.0.6.
- Test and deploy.
Gone are the days of clicking “Update” and hoping for the best. Let Webidextrous manage your maintenance. We’ll give you back your time and peace of mind.
Why Did This Happen?
In the updates to 4.0.6, the /cache/ directory that the Divi theme was writing to changed paths. The new path is now /et-cache/. That’s basically it. Pantheon.io just needs to know the new path and map it to its writeable, secure filesystem via a symlink.
As to why this happens in general, well, it’s because as awesome as WordPress is, it was built around a hosting ecosystem that is inherently insecure.
Hosting got that way because hosting has largely been an exercise in patching together different bits of software to try to efficiently serve web pages to browsers.
So, WordPress theme and plugin developers have gotten used to being able to write pretty much whenever and whatever they want to WordPress directories.
Pantheon.io aims to change that default behavior while still accommodating the need for plugins and themes to write somewhere.
This added security results in our needing to do a little extra work to ensure the site remains stable and secure.
What’s Next?
As I discussed this in the official Facebook group for Divi, the community moderator tagged a lead developer/support person at Elegant Themes. This person stated that this issue will be addressed more directly in a forthcoming version of Divi. So, I’m assuming that means that the above workaround might not be necessary from that fix onward. But this fix will return most Divi sites on read-only WordPress sites back to normal working order and can probably remain as-is going forward.
This also explained the Pantheon phantom /et-cache/…css etc. changes that were showing up in my Dev even if I didn’t change anything. Thanks for posting Rob! If you hear about a fix for this so I can remove this wp-config.php FS_METHOD direct business, be sure to broadcast it!
Will do! Glad this was helpful.
Thank you! I am having the same problem with Pantheon and Divi. Thanks for sharing your solution. 🙂
Glad to help! 🙂
This also helped us a lot in our own setup, with restricted prod file permissions. Thank you very much Rob for posting this.
Great! Glad this was helpful.
Rob,
What directory are you adding /files/et-cache/ to?
On Pantheon, the trick is to create a symlink called et-cache in the wp-content/uploads directory and point it to /files/et-cache.
Sorry, I got caught in spam filter. Was eager to know if you have had any issues with Divi’s generate static CSS generating large, unmanageable numbers of files on Pantheon. I had support recommend to me that I disable it, but I’ve struggled to follow some of their feedback to me — I haven’t been able to understand why they thought this might be an issue so wanted to see if it had been for others.
They told me I had set up the symbolic links right and things seem to be working on Dev and things appear to have transferred properly when I generated the Test site for the sandbox I’m working on.
Pantheon also raised a concern, that was hard for me to understand, about the cache files getting committed to code and that causing a problem. That didn’t seem possible to me given where those files are linked to write to, but could anyone comment on that or help me out?
Also, any tips on safest ways to babystep into Git with a launch coming soon? I’ve been trying to find a way to ramp up without success as I have no background in source control.
Sorry I missed unspamming your comment. Unfortunately there was a spam attack right about the same time you posted your comment and my anti-spam plugin flagged yours with it.
To answer your questions, yes, the et-cache files Divi generates are a bit of a pain on Pantheon. You don’t need to commit them through Test and Live from Dev. They end up being regenerated anyways on Test and Live. I generally try to avoid committing them when I’m in SFTP connection mode and switch to Git. Assuming, that is, that I haven’t made changes to other files in which case I’m stuck with committing et-cache files and directories because I can’t separate them from the commit. You could, while still in SFTP mode, delete the et-cache items. Even better, you can edit your .gitignore file so that it will exclude Git paying attention to et-cache stuff. That way you won’t have to deal with them at all when committing legitimate changes.
Git is a lifesaver and a beast to learn. I suggest taking a LinkedIn Learning class on the topic. Set up a sandbox project and play around with it on the command line.