Jul 232017
 

For a while there XML.com did­n’t handle tags on sub­mit­ted news items very well. If a tag was included that was in a dif­fer­ent case to an exist­ing tag, the pre­view and pub­lish would res­ult in a 500 serv­er error. For­tu­nately this was some­thing that was­n’t vis­ible to the out­side world, but annoy­ing nonetheless.

Wag­tail allows case-insens­it­ive tags, and I had already turned that on (it would be con­fus­ing to have searches for the tags “XSLT” and “xslt” return dif­fer­ent res­ults, for example). Art­icles and news items sub­mit­ted using the stand­ard inter­face behaved prop­erly, it was just the news items sub­mit­ted by people without logins on the sys­tem that didn’t.

It turns out that the prob­lem lay in the way I called the get_or_create() meth­od, which is used to look up the tags in the data­base and then cre­ate them if they don’t exist. In my code, that looked like this: 

tag, create = Tag.objects.get_or_create(name=tag_name)

By default, this is a case-sens­it­ive meth­od (as it should be, for the gen­er­al case). To make the look­up case-insens­it­ive, you use name__iexact instead of name. The next prob­lem I found was that no tags were being cre­ated if the tag did­n’t already exist in the data­base. To cre­ate the tag, if you’re using name__iexact instead of name for the tag look­up, you also need to give the get_or_create() meth­od a defaults para­met­er to use when cre­at­ing the tag. Now that line looks like this:

tag, create = Tag.objects.get_or_create(defaults={'name': tag_name},
                                        name__iexact=tag_name)

and it all works the way it’s meant to.

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.

/* ]]> */