So I did finally fix the login issue with the blog.  Not that there's anyone but me who has any reason to log in at this time, but it sure is nice for me!  The 3D printer post is still extant simply because I want to post a video of the thing working, which I have, but I don't have uploaded to the Internet yet.  I did learn that I need to find the power adapter for the camera, because its batteries last abount a minute and a half (I am not exaggerating) when it's recording 1080p.  Ah well...

You know, I occasionally wonder to myself, especially when I consider the feature list I'd like to implement and how little time I spend (or am able to spend) implementing it, if rolling my own blog software is really worth it.  I mean, I got what I wanted out of it: I learned the basics of MVC design.  I could just take that information, file it away, and replace this silly thing with a "proper" blog CMS.  The temptation's there.  There are probably Wordpress plugins to do the stuff that I want to do, and if there aren't, I'm fully capable of making them.  I'm not much of a developer, but I'm reasonably competant at PHP, certainly more competant at PHP than I am with C++, and I'm writing a game in that.  A blog plug-in is not going to be more complicated than a game.

Fortunately (I guess), I'm offered the occasional instructional moment by my job.  We're implementing Wordpress at work to provide a way to roll better-looking websites for our customers more quickly and less expensively than we have been.  I, as the schmuck who must keep the CMS up to date so that we don't invite the entire world into our database or web server, have insisted that we use a "Network," a multi-site install, so I only have one, easy-to-find set of Wordpress implementation files to keep updated.  We've been taking the first site live, importing it from a designer's test implementation, over the past two weeks.  And wow, I'm now pretty happy with my choice to make a half-implemented, partially-broken thing which I know because I built it myself, rather than installing a half-implemented, partially-broken thing used by thousands-if-not-millions of people across the web.  I have been forced to learn more about Wordpress' innards than I ever wanted to know.

First, if you don't know, Wordpress pretty much never generates error messages, whether to the user or in the log.  Usually, it just doesn't work. Often that means you'll get nothing, a plain blank "page" of no content, not even basic HTML tags; sometimes you get the theme's default content and none of your own.  So you don't know what's wrong, or where it's wrong, and occasionally you don't even realize that something's wrong until later.  Then, you learn that everything is stored in the database...somewhere (usually, it appears, in wp_options).  Which row?  Well, I guess you'll be looking.  Then you discover how clever the Wordpress devs are.  I mean, their solution to the very hard problem of storing configuration parameters in the database is sort of smart.  And sort of "they'd better not get caught near a dark alley with me and a half-brick."  I'll get into their solution in a minute, but I do want to make it clear that this is a difficult problem.  See, you've got a static database format.  You really can't store these options in anything but text.  Unfortunately, you don't know what options any given theme or plugin, or whatever, might need.  You don't know what the options are, what types of things they are, or even how many options there might be.  You're stuck storing a completely arbitrary set of things as text with no idea what it's going to be coming in or what it'll be coming out.  So you have to serialize it somehow.  There are a lot of ways to do this; it's a difficult problem, but a blessedly solved one.  Personally, I'd stick to a data-representation language like XML or YAML.  There are plenty out there, and PHP even has a few XML translation layers in it.  Unfortunately, doing that is very slow.  XML is super slow (though since you're just reading it out and not searching it, it's not that bad; you're only going to parse it the once).  They're also varying amounts of verbose; one of the things I'm not thrilled with about XML is how much space it wastes.  Of course, there's another option, and it's what the Wordpress devs used: PHP's built-in serialize() function.  See, PHP itself needs to serialize data, notably for session variables.  So it's got to have a reasonably robust serialization handler, which can convert arbitrary, basic objects into a plaintext string and then back into an equivalent basic object.  Wordpress just serializes option objects with this thing and stores the resulting data in the database.

But here's the problem: if there are any issues with the data, due to corruption, or it not being what you expect, or intentional fiddling, everything is totally broken.  PHP can't even tell you what's wrong, just that there's an error in the data somewhere (it's usually pretty good about "near the beginning" or "near the end," but that's about all you get).  Wordpress, with it's "never bother telling anyone anything" motto, doesn't even try that.  And this serialized data is very sensitive.  All of the content has expected sizes (counts for arrays, byte length for strings), and if this is wrong, everything breaks.  I have now spent days correcting imports.  See, these imports often have things like domain names in them.  And if your designer hasn't been clever enough themselves to trick their computer into matching the expected production environment, then you have to fix those domain names or Wordpress won't serve that content correctly.  And your designer won't want to redo everything by hand, so you have to do a batch conversion in the database.  There are tools to help you do that, and they are supposed to correct the string lengths.  They don't always succeed.  And sometimes they screw up the string lengths on strings that they aren't supposed to be fiddling with.  This leaves you with data which is broken somewhere inside it, and the systems guy or girl has no choice but to walk through the data by hand correcting the serialized data which was never meant to be seen by human eyes.  Needless to say, this is very unpleasant. Add on to this general problem the fact that your designer may have used a different character set in either the database or their editing tools than the production environment (which might mean that characters do not use an easily predictable number of bytes because, just for instance, they didn't bother to even try to make their dev environment even remotely resemble production) or they put in line breaks which inexplicably work on their system but totally mangle everything after export and import, which are all problems that your find/replace tool isn't going to fix even if it doesn't break things on its own.  So as systems, you're going to spend a lot of time doing real systems dev work to fix it, all the while your designer wrings their hands.  You're going to walk through the serialization data piece by piece, because there are no error messages, there's no logging, you only know if it works or doesn't work.

If I ever have to even think about doing that again, I'm going to write a tool that fixes PHP serialized data stored in a database.  It'll be a really unpleasant tool to write, but it's going to be a hell of a lot more pleasant than doing it by hand for another eight hours.

As nice as plugins and themes are, and as cool as they can be, this experience has pretty well and truly spooked me away from wanting to use Wordpress outside of my professional life.  It's still our best choice, professionally, so I'll have to live with it.  But I don't have to live with it here.  I'm also really grateful that I went with a more sane serialization option for TD -- using YAML instead of some machine-oriented approach.  Processor cycles are cheap these days.  Programmer time and brain capacity is very expensive.  I'll make that trade gladly.