One of my cli­ent web­sites sud­denly star­ted giv­ing an error: Error estab­lish­ing a data­base con­nec­tion. When I went to the /wp-admin URL, the error was still there.

This par­tic­u­lar web­site is on shared host­ing, so I logged into the CPanel and checked the data­base was still there. Then I checked the data­base and found some issues with some of the tables.

[site.wp_links] error: Table upgrade required. Please do "REPAIR TABLE wp_links" or dump/reload to fix it!
[site.wp_options] error: Table upgrade required. Please do "REPAIR TABLE wp_options" or dump/reload to fix it!
[site.wp_postmeta] status: OK
[site.wp_posts] status: OK
[site.wp_term_relationships] status: OK
[site.wp_term_taxonomy] error: Table upgrade required. Please do "REPAIR TABLE wp_term_taxonomy" or dump/reload to fix it!
[site.wp_terms] status: OK
[site.wp_usermeta] error: Table upgrade required. Please do "REPAIR TABLE wp_usermeta" or dump/reload to fix it!
[site.wp_users] error: Table upgrade required. Please do "REPAIR TABLE wp_users" or dump/reload to fix it!


Run­ning those SQL quer­ies on the appro­pri­ate data­base in phpMy­Ad­min fixed the prob­lem. I don’t know whether the host­ing com­pany upgraded the data­base, or some­thing happened with the auto­matic Word­Press upgrade sys­tem, or if some­thing else caused the prob­lem.

[Update] There were a bunch of other errors that cropped up after­wards with the White Screen of Death; I had to call the host­ing com­pany to sort out the server-side errors caus­ing those. It’s pos­sible those errors were the ori­ginal cause of the data­base prob­lems, whatever they were.

Word­Press was designed for pub­lic web­sites, not private ones, so pass­word pro­tec­tion can be a little clunky. For­tu­nately there are plu­gins to help, but (as always) there are trade-offs to be made.

When all you want to do is add a pass­word to stop search engines index­ing and out­siders read­ing the con­tent, but you also want make it as easy as pos­sible for people to use, there’s the Pass­word Pro­tec­ted plu­gin. As it says, it doesn’t pro­tect the images or other uploaded con­tent.

If you also want to pro­tect the media, you will need to give people an account on the Word­Press site (with user­name and pass­word). Then you can use the htac­cess edits detailed at http://www.idowebdesign.ca/wordpress/password-protect-wordpress-attachments/. This works, but in many cases you just don’t want to give lots of people accounts on the sys­tem, or make groups of people share an account. So it’s a trade-off — how import­ant is password-protecting the images versus the admin­is­tra­tion over­head of user accounts with the asso­ci­ated username/password ease of use issues? If you do want to use user­names and pass­words, per­haps giv­ing a group of people a shared account, I’d recom­mend also using one of the plu­gins that helps with finer-grained access con­trol, such as Mem­bers, to stop people being able to change things you don’t want them chan­ging (such as pass­words for the shared account).

I’ve been work­ing at Design Sci­ence for a couple of months now, as Senior Product Man­ager con­cen­trat­ing on the Math­Flow products. So I figured I should enable MathML sup­port on my blog. It’s not hard, but like everything in tech there are a few nig­gly details. Many of those issues are caused by WordPress’s over-eager help­ful­ness, which has to be reined in on a reg­u­lar basis if you’re doing any­thing at all out of the ordin­ary. Like edit­ing your posts dir­ectly in HTML rather than using some pseudo-WYSIWYG editor.

The­or­et­ic­ally, show­ing MathML in a browser is easy, at least for the sort of equa­tions that most people put in blog posts, even though not all browsers sup­port MathML dir­ectly. You just use the Math­Jax JavaS­cript lib­rary. On Word­Press there is even a plu­gin that adds the right script ele­ment, the MathJax-Latex plu­gin. You can make every page load Math­Jax, or use the [math­jax] short­code to tell it when to load.

The wrinkle comes with Word­Press’ tend­ency to “cor­rect” the markup. When you add the MathML, Word­Press sprinkles it with <br/> tags. Math­Jax chokes on those and shows noth­ing. Since the tags don’t show up in the editor view, you need some way of stop­ping Word­Press from adding them. The best way I’ve found is with the Raw HTML plu­gin.

But there’s a wrinkle with that too. For some reason if you use the short­code ver­sion of the begin and end mark­ers ([raw]) the editor decides that the XML char­ac­ters between those mark­ers has to be turned into the char­ac­ter entit­ies, so for example the < char­ac­ters are turned into &lt;. To stop that, you need to a) check all the check­boxes in the Raw HTML set­tings on the post, and b) use the com­ment ver­sion (<– raw –> and <– /raw –>) to mark the begin­ning and end of the sec­tion instead of the short­code ver­sion.

Once it’s done it’s easy to add equa­tions to your pages, so it’s worth the extra few minutes to set it all up.

A couple of examples taken from the Math­Jax samples page

Curl of a Vec­tor Field
$∇→×F→=(∂Fz∂y−∂Fy∂z)i+(∂Fx∂z−∂Fz∂x)j+(∂Fy∂x−∂Fx∂y)k$
Stand­ard Devi­ation
$σ=1N∑i=1N(xi−μ)2$

and one from my thesis from way back when

$fλ=n!⁢∏i

Given the cur­rent state of OpenSol­aris (pre­cari­ous, judging by vari­ous posts I’ve seen over the last few months) I decided to move the base­ment devel­op­ment and blog host­ing machine back to Debian. I mostly use it for a couple of small Word­Press blogs, and try­ing out vari­ous things (the odd Django pro­ject, Ruby on Rails, etc), so Debian is emin­ently suit­able for that.

Step one: move the Word­Press blogs on to an interim host­ing solu­tion, namely the same host where I cur­rently host this blog. My pack­age allows infin­ite add-on domains, so that works. To start with, I made sure I had no broken links on the blogs in their old home — I didn’t want to try to hunt down errors in the new blogs that already exis­ted on the old ones.

The whole pro­cess worked fairly well (install new Word­Press sys­tem on new host, export the old blog, import to the new one) except for a couple of wrinkles, which I’m detail­ing here for next time I need to do this.

1. when set­ting up the new blog, before you’ve switched the DNS, don’t put the final URL in the set­tings dia­log. This just means you can’t log in to the tem­por­ary site and you have to go into PHPMy­Ad­min and fix the URL back to the tem­por­ary ver­sion. Get the site set up prop­erly first, then switch the blog URL and the DNS set­tings.
2. The image attach­ment prob­ably won’t work. If you import the posts and check the “import file attach­ment” box, some of them will attach prop­erly, but not all, and you’ll have to manu­ally upload a cer­tain pro­por­tion of your images using SFTP or some­thing sim­ilar. If you don’t check that box, none of the images will be attached to the right posts and you’ll have to manu­ally upload all of them. If you’ve used stand­ard markup to show pho­tos, that works any­way, but if you’ve used the gal­lery short­code, you’ll have to manu­ally attach the images to the post. The best plu­gin I’ve found to help with this is the Add From Server plu­gin, where you can attach the images after you’ve uploaded them all. It’s still a lot of work if you have a lot of images.

Apart from that, step one went well. Now I have to make sure I have all the other use­ful files saved some­where, and get on with the OS install.

I was upgrad­ing the Word­Press site for someone and had a few moments of panic when, after upgrad­ing, all I could see were blank pages. Vis­ions of hav­ing to go through the pain of rein­stalling the data­base from the backup, and upload­ing all the files from the backup, were dan­cing through my head, which would turn a quick upgrade into a long mara­thon. The upgrade here was from 2.6.something to 3.0.1, and I hadn’t bothered doing all the inter­me­di­ate upgrades, so that made the pro­spect even worse.

Pok­ing around the vari­ous sup­port pages encour­aged me to try a couple of dif­fer­ent things first. The fact that all the pages were blank, both the admin site and the publicly-visible site, made the prob­lem seem worse than it ended up being. And the solu­tions turned out to be rel­at­ively simple.

Step 1: get the admin site going. I’d made all the plu­gins inact­ive, but fol­low­ing the advice on the WP FAQ troubleshoot­ing page, I renamed the plu­gins dir­ect­ory to plugins.hold, and cre­ated a new empty plu­gins dir­ect­ory. This worked, and I could see the admin site. It turns out that one par­tic­u­lar plu­gin cre­ated havoc even when it wasn’t activ­ated. I could then rein­stall all the needed plu­gins cleanly from the auto­matic install one at a time, test­ing to make sure each one worked.

Step 2: go to the Appear­ance page and turn on the default theme (one thing I’d for­got­ten to do before upgrad­ing). It turns out that the old theme wasn’t com­pat­ible with 3.0.1, and showed only blank pages.

Now the site works again, albeit not look­ing quite the same as it did due to the theme, but that prob­lem is tract­able and doesn’t cre­ate any­where near the same “oh, no” prob­lem that the oth­ers did.

I’ve been imple­ment­ing more web sites recently; it appears to be one part of the tech­no­logy mar­ket for which there is still demand. One of the things I push when I meet with cli­ents is access­ib­il­ity, so I figured I should test my own sites and make sure they’re reas­on­ably access­ible. Lynx is one tool to use to check access­ib­il­ity (as well as being a good basic text-based browser). I was a little flum­moxed when I got back a 406 http error, which usu­ally means the user agent can’t read the char­ac­ter set, lan­guage, or encod­ing the web site uses. Even the most basic text html page was rejec­ted.

It turned out that my ISP had mod_security enabled (good) and con­figured in such a way that lynx was banned (not so good). Ban­ning lynx seems to be a fal­lout from a quick way of con­fig­ur­ing mod_security by fil­ter­ing out keywords that might be used in hack­ing attempts. Per­son­ally I can’t see the point as lynx can be told to use a dif­fer­ent user agent string if need be, and people who want to hack your site will likely know how to do that, and I can’t under­stand how people use lynx to hack a site either. Mind you, I don’t hack other people’s web sites, so I don’t know the tools people use who do. Any­way, the ISP cheer­fully took out the fil­ter caus­ing the prob­lem, but in the mean­time my IP address had been flagged by mod_security for try­ing to bypass the fil­ter too many times, so I was com­pletely banned from my own site, as well as every other site that hap­pens to be hos­ted on the same server.

Even­tu­ally we cleared up that little prob­lem as well, and I could get back to tweak­ing my style-sheets and HTML to be more access­ible. There’s a bit more to do yet, but I’m get­ting there. And I’m grate­ful for an assidu­ous ISP (Cana­dian Web Host­ing) with a sup­port team that works late on Fri­day nights.