Jul 232017
 

For a while there XML.com didn’t handle tags on submitted news items very well. If a tag was included that was in a different case to an existing tag, the preview and publish would result in a 500 server error. Fortunately this was something that wasn’t visible to the outside world, but annoying nonetheless.

Wagtail allows case-insensitive tags, and I had already turned that on (it would be confusing to have searches for the tags “XSLT” and “xslt” return different results, for example). Articles and news items submitted using the standard interface behaved properly, it was just the news items submitted by people without logins on the system that didn’t.

It turns out that the problem lay in the way I called the get_or_create() method, which is used to look up the tags in the database and then create 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-sensitive method (as it should be, for the general case). To make the lookup case-insensitive, you use name__iexact instead of name. The next problem I found was that no tags were being created if the tag didn’t already exist in the database. To create the tag, if you’re using name__iexact instead of name for the tag lookup, you also need to give the get_or_create() method a defaults parameter to use when creating 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 Wagtail, a CMS based on Django. It works well for my needs and I like Python as a programming language. One of the big reasons I like Wagtail is that it includes a powerful enough but not overly complicated workflow with roles and a built-in moderation and preview system.

But, I wanted a system where people could submit news items that would go into the moderation queue without needing to sign up for a login first. Fortunately, Wagtail makes that possible, and there’s a nice article by Erin Mullaney at Wagtail: 2 Steps for Adding Pages Outside of the CMS that details all the steps you need. It all worked nicely in more recent versions of Wagtail (thanks, Erin!) except for one part, the notification that the news item is in the moderation queue. That wasn’t a stop-ship item, so XML.com launched without those emails working.

I’ve now found the source of the problem. It turns out that when you submit a news item in this way, it doesn’t have a login identity attached to it (obviously, since there isn’t one). The send_notification function that sends the email uses templates, and these templates use the login identity of the author in the body of the email. Since that doesn’t exist, the whole function fails.

That means the solution is easy. The affected templates are wagtailadmin/notifications/submitted.txt and wagtailadmin/notifications/submitted.html, and Wagtail lets you customize the admin templates. I put my customized admin templates into a utils application, which contains all my utilities 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 %}

Similar changes are necessary for the wagtailadmin/notifications/submitted.html file if you want to send HTML emails instead.

/* ]]> */