Apr 082017
 

If you have Math­ML on your Word­Press site, using the Math­jax sys­tem to show it, then you need to know that Math­jax is shut­ting down the CDN as of April 30, 2017. If, like me, you use the Math­Jax-LaTeX plu­gin, the solu­tion is easy.

Go to the Plu­gins — Set­tings — Math­Jax-LaTeX page. Uncheck the “Use Math­Jax CDN Ser­vice?” check­box, and add https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.0/MathJax.js to the “Cus­tom Math­Jax loc­a­tion?” text field. You can, of course, also down­load the Math­Jax scripts and install loc­ally, but I prefer to use a CDN.

Save the changes, and you’re all set! Unfor­tu­nately there isn’t an equi­val­ent of the Math­Jax ‘latest’ for the scripts, so every now and then you’ll need to update the loc­a­tion, but oth­er than that there should be no differences.

Apr 242016
 

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 CPan­el 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 wheth­er the host­ing com­pany upgraded the data­base, or some­thing happened with the auto­mat­ic Word­Press upgrade sys­tem, or if some­thing else caused the problem.

[Update] There were a bunch of oth­er 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 serv­er-side errors caus­ing those. It’s pos­sible those errors were the ori­gin­al cause of the data­base prob­lems, whatever they were.

Nov 172014
 

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 does­n’t pro­tect the images or oth­er uploaded content.

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 pass­word-pro­tect­ing 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).

Jun 242014
 

I’ve been work­ing at Design Sci­ence for a couple of months now, as Seni­or Product Man­ager con­cen­trat­ing on the Math­Flow products. So I figured I should enable Math­ML 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 Word­Press’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-WYSI­WYG editor.

The­or­et­ic­ally, show­ing Math­ML 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 Math­ML 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 Math­Jax-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 Math­ML, 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 edit­or view, you need some way of stop­ping Word­Press 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 reas­on if you use the short­code ver­sion of the begin and end mark­ers ([raw]) the edit­or 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 version.

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=(FzyFyz)i+(FxzFzx)j+(FyxFxy)k
Stand­ard Deviation
σ=1Ni=1N(xiμ)2

and one from my thes­is from way back when

fλ=n!i<k(li-lk)l1!l2!lr!
Apr 212011
 

Giv­en the cur­rent state of OpenSol­ar­is (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 Debi­an. 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 Debi­an is emin­ently suit­able for that.

Step one: move the Word­Press blogs on to an inter­im 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 did­n’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 settings.
  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­il­ar. 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 Serv­er 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 oth­er use­ful files saved some­where, and get on with the OS install.

Nov 272010
 

I was upgrad­ing the Word­Press site for someone and had a few moments of pan­ic 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 had­n’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 pub­licly-vis­ible 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 hav­oc even when it was­n’t activ­ated. I could then rein­stall all the needed plu­gins cleanly from the auto­mat­ic 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 was­n’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 does­n’t cre­ate any­where near the same “oh, no” prob­lem that the oth­ers did.

/* ]]> */