I am trying out a system that puts my media files onto Google Cloud Storage, which is much cheaper than using increasingly huge VPS instances.
I am trying WP-Stateless, and I will post a photo as a test.
Well, it works – you can absolutely do this. However, it only works if you have a public-facing bucket. The flow I was hoping for is for a password-protected site, and that does not work with a public bucket. I also explored using a FUSE-based setup, where I use SSH for a virtual link between my filesystem and a non-public bucket.
That works OK in a test, but if you add 40Gb of data, the FUSE link just fails to work – you can’t manage the throughput for even the ls command, let alone working as a high-latency-localish filesystem. Oh well.
A recent update of PHP broke one of my oldest WordPress blogs. It was set up with an offset for the timezone, which is no longer supported. What it looked like was the white screen of death, but enabling debug mode in my wp-config.php gave me some hints.
The first hint that it was something weird is that all of my other blogs, which all run off of the same database, were all fine. I can look at their settings, log into their administration interfaces, change their settings, but my old blog would not load.
After considerable DuckDuckGo-ing, I figured out the setting that needed to be fixed, but because I couldn’t load the administration interface, I could not fix the setting. Access to all of your WordPress settings is inside the database, so I had to figure out how to change that setting directly in the database, preferably without ruining everything.
The option was timezone_string, but if you don’t know how the database is laid out, you have to do some poking before you can get yourself sorted.
All of the options are in a table called options, or in my case, since I have multiple WordPress blogs in the same database, there is a prefix underscore first. I found this by logging into the database engine, navigating to the correct database, and then using the show tables; command.
mysql -u $BLOGDATABASEUSERNAME -p
show columns from $BLOGNAME_options;
The next wrinkle was interpreting the results – they lay out the columns vertically, which isn’t very intuitive, since we definitely asked for columns, and they are shown as rows. Still, it is standard, and looks like this:
I was then able to figure out that I need to change the option_value for the row with the option_nametimezone_string. Since I want to figure out what to change it to, I tried this:
select option_value from $BLOGNAME_options where option_name='timezone_string';
That showed me the problem that I was seeing in the debug messages. Then I looked at the timezone_string from one of the blogs that wasn’t broken, which in that case was “America/Toronto”. Then I finally had enough information to update the option_value to (hopefully) fix my ailing blog. So, I ran this:
update $BLOGNAME_options set option_value = 'America/Toronto' where option_name = 'timezone_string';
And it worked! It took too long, and was stressful and annoying, and made me wish that all of these options were in a flatfile, ’cause doing this with no interface is annoying, and completely beyond the average blog-haver, I think.
If the whole blog is going to go down from a borked option, maybe the blog should load a default set of options and then tell the user which options to fix.
There are lots of times when you want to get the inverse of an operation – like finding all of the rows not like some criteria. This is possible, but hard to search for, especially because this functionality is hiding behind the “tilde (~)” operator.
Here’s how it works:
What if you have a column that is supposed to be a date-as-a-number, but your parse-this-column-as-a-date code keeps barfing? Now you can filter by a doesn’t-match-this-format criteria.
weirdos is now a DataFrame which includes the rows where it doesn’t match the format, because of the tilde (~) beginning the definition.
I have also used this is get subsets of non-conforming DataFrames – I know what it is supposed to be like, but it is too hard to know all of the ways that your data may not be like that.
I found this when I was looking for the NOT equivalent of .isin – which unfortunately doesn’t exist. That’s the problem with Huffman coding your operators into single characters – you can’t easily search for them if you don’t know what they’re called.