in response to the murder of George Floyd by police

200531 Serve and Protect sculpture, Salt Lake City
200531 Serve and Protect sculpture, Salt Lake City

increasingly violent protests have been escalating globally. if we had all listened to colin kaepernick, way back when, we might have avoided this.

meanwhile, drumpf has issued an executive order making antifa a “terrorist organisation” — meaningless, as antifa isn’t an “organisation”, but convenient, because now drumpf can claim anybody is antifa, and have them arrested — and inciting violence on twitter with rhetoric recycled from the republican side of the ’60s-era race riots.

and “when the looting starts, the shooting starts” means the same thing 50 years ago as it does now.

COVID19 has facilitated increasing fascism. it’s just a matter of time before drumpf declares martial law, and/or someone assassinates him.

something that would be supremely ironic, in drumpf’s case: “assassinate” is a word that begins with not one, but two “ass”es…

ahhhh! now we find out…

my newly redesigned site uses the enfold theme, which has faulty (under certain circumstances) caching and optimisation routines, so we use lightspeed cache, which doesn’t have those (particular) faults, and works better (under certain circumstances).

except, last year, prior to my site being redesigned (when i was still using the avada theme), i was told (by SOMEONE) to disable lightspeed cache, because it had some sort of incompatibility with… something…

so, i went through the site redesign with a disabled lightspeed plugin. no problem, until i put in the enfold theme, and whatever circumstances that cause the caching and optimisation routines to fail, were happening, which was the cause of the first go-round.

turning on the lightspeed cache fixed the first go-round, but whatever incompatibility i was trying to avoid by having the lightspeed plugin disabled, took effect, which was the cause of the second go-round.

which was further confused by the fact that part of my routine for fixing the first go-round was good enough that it fixed the second go-round well enough that i didn’t find out about it until it was too late.

what i found out, today, via my web developer, is that the people who make the lightspeed cache and webhost python (my host provider) have their own battle going on: on webhost python’s servers (which include mine), the lightspeed plugin causes expired transients to multiply and duplicate. lightspeed says it’s python’s fault. python disagrees…

on the record…

OFF the record, python agrees that there is a bug in their system that they haven’t found yet… compounded by the fact that it was THEIR ERROR which caused the third go-round… 😠 but it’s not for me to say “i told you so”, especially with my already somewhat precarious position with this particular host provider…

and so, i’m caught in the middle. 😒

apparently, for the time being anyway, the plan is to disable the caching modules on both enfold AND lightspeed, keep an eye on the database (which hasn’t blown up since implementing this plan), clear the expired transients manually, and examine other options for a cache.


oy! why won’t this just go away?

at midnight (which was 3:00 in the morning, florida time), i got a message saying that the database was blowing up again. they said it was 183 GIGABYTES

because of the fact that i was asleep (thankfully), i didn’t actually read the message until 7:00 my time (10:00 florida time). i immediately logged into my web server, and discovered that the MySQL disk usage was lower than i have ever seen it before, which is to say 253 MEGABYTES

what this tells me is that there’s something else going on besides this whole “enfold-theme-not-caching-correctly” horseshit.

which is bad.

it also tells me that, whatever it is, we haven’t actually found it… we may have found another problem, but not the one for which we’re looking… yet…

which is bad, but not as bad as it could be.

it also tells me that, whatever it is that is going wrong, the cronjob that we put in place to solve the problem, works, REGARDLESS of the actual problem.

which is good.

but, when it comes right down to it, it is not good for me to be so stressed out about something over which i have very little control.

which is bad.

something has to be done. this is ridiculous.

oh, but it couldn’t have ended there, now, could it?

and the answer is, a big, fat, OF COURSE NOT! 😒

i woke up this morning, and couldn’t log in to my web site… at, like, SEVEN in the fucking morning, i was wide awake because i couldn’t log in to my web site.

at NINE, the web designer gets back to me. he can’t login either. apparently the host provider has disabled the config file that makes everything work — i login using SSH, and there’s the file… everything LOOKS okay, but… the host provider apparently did SOMETHING to my web site. as far as i can tell, everything works, sort of, until you get one or two pages deep, at which point it gives me a “unable to connect to database” error.


so, i file a ticket with the host provider. a couple hours later, (all the while, i’m sweating bullets) they get back to me, apparently, the database blew up AGAIN. they disabled the config file so that nobody could use the web site, because the database was growing by gigabytes A SECOND.


eventually (seriously, they took most of the day to UN-disable the config file), the web designer went in and turned off everything having to do with the built-in, screwy, does-not-work, enfold caching and optimisation routines, turned OFF “store transients”, and set a cronfile to delete three rows of a table in the database, every hour.


this better be the last of it for a while, because i’m just about ready to throw in the towel.