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.

Mar 262017
 

Let’s Encrypt has made it much easi­er for web sites to use https instead of http, even those on shared host­ing. In my case, all I needed to do was ask my ISP, Cana­dian Web Host­ing, to move my accounts to a serv­er that sup­ports a cPan­el exten­sion (I assume this one). Installing the certs is trivial.

Chan­ging the basic Word­Press set­ting was easy — update the WordPress Address (URL) and Site Address (URL) set­tings in Gen­er­al. This did break a lot of image links, mostly because I’ve had my blog on Word­Press for so long that I still had all my images in a cus­tom image dir­ect­ory and the gal­lery could­n’t find them any more. That took a cer­tain amount of fid­dling, and I haven’t yet got all the images in the old posts back to the way they were.

Anoth­er thing that broke was my spam detec­tion. I used Spam Karma for many years, and even after it was no longer updated it was suit­able for my needs. But it does­n’t work with https for some reas­on. I’ve now switched to Anti­s­pam Bee and find it does what I need. I haven’t noticed any spam slip­ping through, nor real com­ments being marked as spam. Most of the com­pet­it­ors had some fea­ture I did­n’t like, such as by default delet­ing com­ments without my hav­ing a chance to check them. That would be use­ful on sites with lots of spam, but not neces­sary for mine. It has a well-deserved high rat­ing on the Word­Press plu­gin site.

Over­all, switch­ing my sites to https cost me a couple of hours work and the time wait­ing for the new serv­er DNS to propag­ate. Well worth it.

Feb 012017
 

I coded XML.com in Wag­tail, a CMS based on Django. It works well for my needs and I like Python as a pro­gram­ming lan­guage. One of the big reas­ons I like Wag­tail is that it includes a power­ful enough but not overly com­plic­ated work­flow with roles and a built-in mod­er­a­tion and pre­view system.

But, I wanted a sys­tem where people could sub­mit news items that would go into the mod­er­a­tion queue without need­ing to sign up for a login first. For­tu­nately, Wag­tail makes that pos­sible, and there’s a nice art­icle by Erin Mul­laney at Wag­tail: 2 Steps for Adding Pages Out­side of the CMS that details all the steps you need. It all worked nicely in more recent ver­sions of Wag­tail (thanks, Erin!) except for one part, the noti­fic­a­tion that the news item is in the mod­er­a­tion queue. That was­n’t a stop-ship item, so XML.com launched without those emails working.

I’ve now found the source of the prob­lem. It turns out that when you sub­mit a news item in this way, it does­n’t have a login iden­tity attached to it (obvi­ously, since there isn’t one). The send_notification func­tion that sends the email uses tem­plates, and these tem­plates use the login iden­tity of the author in the body of the email. Since that does­n’t exist, the whole func­tion fails. 

That means the solu­tion is easy. The affected tem­plates are wagtailadmin/notifications/submitted.txt and wagtailadmin/notifications/submitted.html, and Wag­tail lets you cus­tom­ize the admin tem­plates. I put my cus­tom­ized admin tem­plates into a utils applic­a­tion, which con­tains all my util­it­ies for the site. My utils/templates/wagtailadmin/notifications/submitted.txt file now has the content

{% extends 'wagtailadmin/notifications/submitted.txt' %}
{% load i18n %}

{% block content %}
{% blocktrans with page=revision.page|safe %}The page "{{ page }}" has been submitted for moderation.{% endblocktrans %}

{% trans "You can preview the page here:" %} {{ settings.BASE_URL }}{% url 'wagtailadmin_pages:preview_for_moderation' revision.id %}
{% trans "You can edit the page here:" %} {{ settings.BASE_URL }}{% url 'wagtailadmin_pages:edit' revision.page.id %}
{% endblock %}

Sim­il­ar changes are neces­sary for the wagtailadmin/notifications/submitted.html file if you want to send HTML emails instead.

May 102016
 

If you read the doc­u­ment­a­tion closely enough, of course all the inform­a­tion is there. Get­ting the order of oper­a­tions right, how­ever, can cause the odd issue.

Devel­op­ing Django apps means apply­ing migra­tions, and those don’t always do what’s expec­ted. In that case, you can roll back to the n‑1 migra­tion by using ./manage.py migrate [app_label] {n-1_migration_label}, then delete the nth migra­tion, then edit the models.py to try again.

To clean up the data­base from some third-party app you decide you don’t want after all, you use ./manage.py migrate [app_label] zero to get rid of the migra­tions from that app. You have to run this before delet­ing the app from your settings.py file.

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.

Apr 222016
 

I dis­covered anoth­er issue while deploy­ing to Python­Any­where (maybe it’s applic­able to oth­er PAAS pro­viders as well).

There was an odd Impor­t­Er­ror when run­ning manage.py. In the spe­cif­ic case I had, it showed up when run­ning the tests with coverage: from Uni­path import Path Impor­t­Er­ror: No mod­ule named ‘Uni­path’. It turned out I had­n’t installed cov­er­age in the vir­tu­al envir­on­ment, which meant the sys­tem was using the default one. Installing cov­er­age in the vir­tu­al envir­on­ment as well fixed the problem.

/* ]]> */