At the end of Chapter 2, I decided to whip up a new WordPress installation on Convesio so that I could try out a new WordPress site on the same hosting platform as WP Mainline to determine if it was a web hosting/security issue or something with the site itself.
After setting up the site, the first thing I did was embed a Gist into a custom HTML block. This ended up working. I then installed all of the plugins and the theme I use on WP Mainline to the test site and discovered that worked as well. At this point, I was feeling pretty frustrated and reached out on Twitter.
Ross Whintle reached out and did some diagnostic work for me. Convesio ended up being contacted on Twitter as well. Although I already had a support ticket open with them, we weren’t gaining much progress. At this point, Tom Fanelli, CEO of Convesio, stepped in and reviewed the ticket.
First, Fanelli explained what the domain ConvesioPerformance.com is used for. “ConvesioPerformance is how we point people to our Enterprise Cloudflare Zone,” he said. Convesio uses a product from Cloudflare called SSL for SaaS. They set up a zone in Cloudflare, then proxy a lot of domains through the same zone, allowing Convesio to in essence have global settings on security, performance, etc. that apply to everyone in that zone.
The reason I know about the ConvesioPerformance domain is that it shows up in the error description when viewing the Network tab in the browser’s inspector tool. This piece of information led me and others to believe that there was an issue with Convesio’s Cloudflare configuration.
As it turns out, there was definitely an issue involving Cloudflare. Fanelli diagnosed the issue by installing a plugin that disables autosaves in the editor. The autosaves in the block editor were occurring at such a frequency that it incremented a security score. The more times the autosave URL would hit Cloudflare, the higher the score would increase until the IP address was blocked.
In the following screenshots, you can see the offending URL and Cloudflare blocking the attempt.
Fanelli explained that while it wasn’t technically Cloudflare’s fault, what is being enforced is a default OWASP security ruleset that triggers the block. He suspects that there could be something in WordPress and the way it autosaves a post that triggers the block. Interestingly enough, a user who posted to the Cloudflare community forums back in May of this year reported a similar problem.
The problem in that instance was solved by disabling the following WAF rule, 100173 – XSS, HTML Injection – Script Tag. So if you’re encountering issues with saving content using certain HTML elements like < script > in the block editor, it is possible that the security configuration behind the scenes is blocking it. We ended up whitelisting my IP address but I’m not sure if that is a long-term solution.
The Mystery is Solved
I am happy to report that this mystery has been solved. It was not WordPress’ fault but a security configuration issue that was out of my control. But when creating content inside of the block editor, how is it possible to know that? For all I knew, the block editor was broken. Although frustrating, I’m glad I went through this experience to broaden my horizons of what could be at fault if something like this happens again. I also hope it helps others, particularly web hosts.
I’d like to hear from those in the security or WordPress hosting space, particularly with Cloudflare setups, on what your or your user’s experiences have been like with the block editor.