If you have MathML on your WordPress site, using the Mathjax system to show it, then you need to know that Mathjax is shutting down the CDN as of April 30, 2017. If, like me, you use the MathJax-LaTeX plugin, the solution is easy.

Go to the Plugins – Settings – MathJax-LaTeX page. Uncheck the “Use MathJax CDN Service?” checkbox, and add https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.0/MathJax.js to the “Custom MathJax location?” text field. You can, of course, also download the MathJax scripts and install locally, but I prefer to use a CDN.

Save the changes, and you’re all set! Unfortunately there isn’t an equivalent of the MathJax ‘latest’ for the scripts, so every now and then you’ll need to update the location, but other than that there should be no differences.

One of my client websites suddenly started giving an error: Error establishing a database connection. When I went to the /wp-admin URL, the error was still there.

This particular website is on shared hosting, so I logged into the CPanel and checked the database was still there. Then I checked the database 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!


Running those SQL queries on the appropriate database in phpMyAdmin fixed the problem. I don’t know whether the hosting company upgraded the database, or something happened with the automatic WordPress upgrade system, or if something else caused the problem.

[Update] There were a bunch of other errors that cropped up afterwards with the White Screen of Death; I had to call the hosting company to sort out the server-side errors causing those. It’s possible those errors were the original cause of the database problems, whatever they were.

WordPress was designed for public websites, not private ones, so password protection can be a little clunky. Fortunately there are plugins to help, but (as always) there are trade-offs to be made.

When all you want to do is add a password to stop search engines indexing and outsiders reading the content, but you also want make it as easy as possible for people to use, there’s the Password Protected plugin. As it says, it doesn’t protect the images or other uploaded content.

If you also want to protect the media, you will need to give people an account on the WordPress site (with username and password). Then you can use the htaccess 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 system, or make groups of people share an account. So it’s a trade-off – how important is password-protecting the images versus the administration overhead of user accounts with the associated username/password ease of use issues? If you do want to use usernames and passwords, perhaps giving a group of people a shared account, I’d recommend also using one of the plugins that helps with finer-grained access control, such as Members, to stop people being able to change things you don’t want them changing (such as passwords for the shared account).

I've been working at Design Science for a couple of months now, as Senior Product Manager concentrating on the MathFlow products. So I figured I should enable MathML support on my blog. It's not hard, but like everything in tech there are a few niggly details. Many of those issues are caused by WordPress's over-eager helpfulness, which has to be reined in on a regular basis if you're doing anything at all out of the ordinary. Like editing your posts directly in HTML rather than using some pseudo-WYSIWYG editor.

Theoretically, showing MathML in a browser is easy, at least for the sort of equations that most people put in blog posts, even though not all browsers support MathML directly. You just use the MathJax JavaScript library. On WordPress there is even a plugin that adds the right script element, the MathJax-Latex plugin. You can make every page load MathJax, or use the [mathjax] shortcode to tell it when to load.

The wrinkle comes with WordPress' tendency to "correct" the markup. When you add the MathML, WordPress sprinkles it with <br/> tags. MathJax chokes on those and shows nothing. Since the tags don't show up in the editor view, you need some way of stopping WordPress from adding them. The best way I've found is with the Raw HTML plugin.

But there's a wrinkle with that too. For some reason if you use the shortcode version of the begin and end markers ([raw]) the editor decides that the XML characters between those markers has to be turned into the character entities, so for example the < characters are turned into &lt;. To stop that, you need to a) check all the checkboxes in the Raw HTML settings on the post, and b) use the comment version (<-- raw --> and <-- /raw -->) to mark the beginning and end of the section instead of the shortcode version.

Once it's done it's easy to add equations to your pages, so it's worth the extra few minutes to set it all up.

A couple of examples taken from the MathJax samples page

Curl of a Vector Field
$∇→×F→=(∂Fz∂y−∂Fy∂z)i+(∂Fx∂z−∂Fz∂x)j+(∂Fy∂x−∂Fx∂y)k$
Standard Deviation
$σ=1N∑i=1N(xi−μ)2$

and one from my thesis from way back when

$fλ=n!⁢∏i

Given the current state of OpenSolaris (precarious, judging by various posts I’ve seen over the last few months) I decided to move the basement development and blog hosting machine back to Debian. I mostly use it for a couple of small WordPress blogs, and trying out various things (the odd Django project, Ruby on Rails, etc), so Debian is eminently suitable for that.

Step one: move the WordPress blogs on to an interim hosting solution, namely the same host where I currently host this blog. My package allows infinite 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 existed on the old ones.

The whole process worked fairly well (install new WordPress system on new host, export the old blog, import to the new one) except for a couple of wrinkles, which I’m detailing here for next time I need to do this.

1. when setting up the new blog, before you’ve switched the DNS, don’t put the final URL in the settings dialog. This just means you can’t log in to the temporary site and you have to go into PHPMyAdmin and fix the URL back to the temporary version. Get the site set up properly first, then switch the blog URL and the DNS settings.
2. The image attachment probably won’t work. If you import the posts and check the “import file attachment” box, some of them will attach properly, but not all, and you’ll have to manually upload a certain proportion of your images using SFTP or something similar. If you don’t check that box, none of the images will be attached to the right posts and you’ll have to manually upload all of them. If you’ve used standard markup to show photos, that works anyway, but if you’ve used the gallery shortcode, you’ll have to manually attach the images to the post. The best plugin I’ve found to help with this is the Add From Server plugin, 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 useful files saved somewhere, and get on with the OS install.

I was upgrading the WordPress site for someone and had a few moments of panic when, after upgrading, all I could see were blank pages. Visions of having to go through the pain of reinstalling the database from the backup, and uploading all the files from the backup, were dancing through my head, which would turn a quick upgrade into a long marathon. The upgrade here was from 2.6.something to 3.0.1, and I hadn’t bothered doing all the intermediate upgrades, so that made the prospect even worse.

Poking around the various support pages encouraged me to try a couple of different things first. The fact that all the pages were blank, both the admin site and the publicly-visible site, made the problem seem worse than it ended up being. And the solutions turned out to be relatively simple.

Step 1: get the admin site going. I’d made all the plugins inactive, but following the advice on the WP FAQ troubleshooting page, I renamed the plugins directory to plugins.hold, and created a new empty plugins directory. This worked, and I could see the admin site. It turns out that one particular plugin created havoc even when it wasn’t activated. I could then reinstall all the needed plugins cleanly from the automatic install one at a time, testing to make sure each one worked.

Step 2: go to the Appearance page and turn on the default theme (one thing I’d forgotten to do before upgrading). It turns out that the old theme wasn’t compatible with 3.0.1, and showed only blank pages.

Now the site works again, albeit not looking quite the same as it did due to the theme, but that problem is tractable and doesn’t create anywhere near the same “oh, no” problem that the others did.

/* ]]> */