I need to get this written up before I forget all the details.
I decided to implement the contact form first. It seemed like a straightforward and simple way to get my feet wet with user interaction for the website over and above the built-in WordPress blog post comment functionality. Being not that bright, and hopelessly persnickety, it took me several weeks to get it up and running – mostly because I was trying out a number of form plugins. But I finally got it going, and wanted to test it on as many browsers as I could. Everything worked great with Firefox for Windows and Android, Chrome for Windows and Android, Safari for Apple IOS, Internet Explorer for Windows, Microsoft Edge for Windows, and Brave for Android. But when I submitted the form from Brave for Windows, afterward the Soliloquy image slider stopped being displayed. What was even worse was that after using Brave to submit the form, none of the other browsers would render the slideshow properly either. I found that if I opened up the Home page in my WordPress back-end and re-published it without making any changes, everything started working fine until I used Brave to submit the form again.
If it hadn’t been for the fact that the Brave form submission broke image display for all the other browsers, I probably would have just blown the issue off, with maybe a little warning notice on the form for Brave visitors. But I couldn’t have Brave breaking the website for everyone. I also considered using a script on the form to detect whether the visitor was using Brave, and simply not allowing the form submission after providing a gentle suggestion to use another browser. Turns out that isn’t easy because Brave doesn’t provide a “user agent” identifier. Brave users show up as “Chromium.” The Brave development community has decided that allowing a web server to identify visitors using Brave would allow a website to circumvent the adware blocking for which Brave was created. So I needed to fix the problem rather than working around it.
Not knowing what might be causing the issue, I opened up support tickets with the Brave community, Generate Press, Soliloquy, and Ninja Forms. While trying out the various suggestions that came out of these trouble tickets, I noticed that not only did the rendering of the Soliloquy slideshow get broken when the form was submitted, the site logo image was also not displaying properly. I decided to take Soliloquy out of the equation. I reverted the site to the old static homepage, and disabled the Soliloquy plugin. Sure enough, the problem was still evident without the slideshow.
I couldn’t figure out a way to eliminate the Generate Press theme as a potential cause. In any case, I didn’t want to change themes. Nevertheless, I did research a few other themes, but couldn’t find one I liked better. The folks at Generate Press, and Ninja forms both agreed that the issue was very likely with the Brave browser, but no one seemed to have any idea how one browser could impact the site rendering by another browser. Somewhere in the middle of all this, I noticed that the same issue cropped up when I used the WordPress built-in comment form to respond to a post. That was blind luck. For some reason, I needed to submit a comment on one of the posts, and I was already on the site using Brave to test the image rendering issue. So that eliminated the Ninja forms plugin as the culprit.
The folks on the Brave community seemed to think that the issue was related to my hosting service. So I called up GoDaddy and explained the problem. They did some testing, and couldn’t find anything wrong. In the meantime, someone at Generate Press e-mailed me and suggested I disable my CDN. Since I had no idea what a CDN was, I decided to research that later, and went back to troubleshooting with the Brave folks. I tried to set up a test on my staging site for the Brave folks to use, but I couldn’t reproduce the symptom on the staging site. I was in the process of setting up a user account on the live site for one of the Brave community troubleshooters, when he sent me a screen shot of the error he was receiving. The error he was receiving was from the server saying that access to the image files was not allowed (following form submission from Brave). He suggested that the issue might be related to a CDN. I remembered the same suggestion from the Generate Press guy a few days before. So I started looking into exactly what a CDN is.
Google is our best friend, as everyone knows. Google said that a Content Delivery Network or Content Distribution Network (CDN) is a distributed set of proxy servers and their associated storage and Internet connectivity that makes a web hosting provider’s delivery of hosted web content more efficient by geographically dispersing the content servers so they will be closer to the client. Okay. So I knew what a CDN is. But how to enable/disable it. I was about to call GoDaddy to ask, but I had to clean up that work I’d been doing on the staging site first. When I logged into GoDaddy, there was an on/off switch on the Managed WordPress management dashboard labeled CDN. It had been set to On by default when the site was created, and since I didn’t then know what a CDN is, I prudently left it alone. This time though, I clicked it to disable the GoDaddy CDN, and presto – the problem disappeared. Just to make sure it wasn’t a coincidence, I clicked the switch again to turn the CDN back on, and sure enough the problem re-appeared.
So I profusely thanked everyone who had been helping me with the issue, and wrote up a note to GoDaddy support about the issue. I also updated the ticket with the Brave community, and left the thread open. For now, the GoDaddy CDN remains disabled, and I’m just ignoring the pop-ups telling me that a CDN is available that could make my visitors’ experience mo betta. Every once in a while when I’m bored, I’ll go back and try it again to see if Brave has made a change that will fix the problem. For now there’s a workaround in place that, while not optimal at least works.
“Better is the mortal enemy of good enough.”Joe Hodl