In the unlikely event you care, be aware that I have just installed a new digital certificate for discourse.net:
If your browser popped up a warning about the site’s cert changing, this is the reason. If it didn’t, well that just shows you how far we have to go in getting security to work well online.
The cert is issued by Let’s Encrypt, and replaces one I had to pay for.
Something is duplicating my blog posts on Twitter. Or rather, two somethings.
Doubtlessly, they are both things I set up myself some time long in the past, set and forgot. Now I have to reverse engineer it to figure out what they are.
The one that makes nicer posts is Twitterfeed. I want to keep that one and kill the other one. But I not sure what the other one is. Presumably it should show up in the — shockingly long — list of Twitter Apps I’ve enabled, which is how I cottoned on to Twitterfeed. Perhaps the other is WordPress’s native twitter feed which I hope I’ve disabled.
This post will tell.
(Of course the real mystery of Twitter is how I ended up on the list of Top 50 Law Professors to Follow on Twitter, when almost all my Tweets come from this blog…. Oh well, I’m near the bottom, maybe I’ll fall off next year.)
No, I don’t mean the climatic conditions you may be experiencing while I endure temperatures of 75-85 degrees Fahrenheit (24C-30C) at mid-day here.
I mean the symbolic stuff that fell on the blog today.
It seems that the Jetpack plugin I use has a snow setting and that something turned it on. The story of how I turned it off is a cautionary tale of a little knowledge being dangerous. Ignore the rest if tech talk bores you.
First thing I did was look at the code being served up by the blog. And sure enough, there was a call to a “holiday-snow” module in Jetpack. I turned to Google, which on what turned out to be a careless reading told me I should see a control in the Jetpack configuration settings. So I went to the (very extensive) Jetpack control menu and looked for a snow toggle. No luck.
Worrying it might be a hack I logged into the blog’s server and confirmed that there was in fact a jetpack module of that name sitting deep inside the code dropped in by jetpack.
Since I vaguely remembered running snow on purpose some time in the past, I started to worry that maybe I had hand-coded the call to the snow module. This is a bad practice, one I abandoned long ago for the much cleaner and safer method of using child themes, but maybe it was so long ago…? But, no, all the grepping I tried found no hard-coded calls to the holiday snow routine.
So after wasting a lot of time on this, I went back to Google. There I found that Jetpack works differently on wordpress-hosted blogs (the snow toggle is where you would expect it), and on self-hosted blogs like mine. In those cases, the plugin adds a snow toggle into the Settings > General menu of WordPress, completely separate from the Jetpack > Settings menu where all of its other options reside. I think that’s sort of sneaky, and uncalled for, but if I’d read the instructions I found the first time a little more carefully, I’d have saved half an hour or more.
In order to debug some very odd behavior under the hood, I’ll be doing odd things to the site theme in the next day or two. While it may temporarily change the looks, it shouldn’t change the content.
I think I’ve pretty much got https working on this blog. At present it will serve up both unencrypted or encrypted versions depending what you ask for. The encrypted version is, at least on my computers, noticeably slower to turn up.
So the question is, What do I do now? Should I turn of http and forward all traffic to https? If I do so, should I remove the remaining insecure items, which I take to be the counters and the little map that shows where visitors come from? Is there a free counter somewhere that is https compliant? If I don’t force https, what’s the point of having the encrypted version there if almost no one other than the people running EFF’s great https-everywhere plugin will ever see it?
I’ve purchased a certificate for the blog so it can run on SSL/TLS, ie have an https address.
Little did I know how much grief this would cause. However, I only locked myself out of the blog once, and with the help of of a WordPress https plugin I am gradually reducing the number of mixed-content errors.
Security really shouldn’t be this hard …
Blog migrated to a new server. Many things still flaky.
Along the way I learned that I had 2.2 GB — yes gigabytes — of useless accumulated metadata for comments, caused by getting
1.5 million 2.1 million or so sp*m comments over the last decade. I removed those with the WordPress WP Clean Up plugin which worked like a champ.
Before I got to that point, however, I had to back up my databases, and because of all the cruft they were too large to back up on the old host. Eventually I figured out how to let PHP run for half an hour and I got there.
The transfer to the new service (Dreampress instead of a VPS at Dreamhost) was supposed to be automatic, but it wasn’t. Files didn’t get copied over, permissions were wrong, and doubtless more stuff I don’t know about yet.
Anyway, lots of cleanup and checking left to do.