January 19, 2020
Server Caching Madness - Part 2
January 19, 2020
Yesterday, two 'tech supports' lied to me about almost everything. The solution that I came up with worked for a few hours, but then a real sysadmin must have noticed it, because it stopped working today. Unfortunately, if you look at the list of hosting companies that EIG has gobbled up over the years, the only other game in town is GoDaddy, and I'm not going there. These are the new Robber-Barons.
The server caching policy is so aggressive, it is even caching images. I cannot imagine the benefits of having the server cache a totally static image file. The extra overhead of creating a copy for the cache must actually slow it down. This is insanity.
After another 'chat' with another support rep who also lied to me ( but this time boldly, blithely, and right away, which was a refreshing change, not to mention a great time-saver ) I realized that I had already coded up a solution and discarded it. That solution is to simply in-line all the css files - have php (WordPress) read them and write the contents directly into the html file. This totally bypasses the web server for the outboard files, at the expense of ruining any caching efficiencies for the end user. It also trashes any caching efficiencies for the server, so ha ha !!! For good measure, I in-lined all the javascript too.
I'm not sure if I will leave this setting on when I am done developing, but it is absolutely necessary right now. What a hellish environment to do any kind of work in. Web hosting has sure gone downhill. But as I said, there are no better alternatives.
WordPress also has some really bizarre default css that is very difficult to override. Some of it I still haven't figured out.
