One of the questions we have asked potential recruits at The Perl Shop is, "What do you feel are weaknesses with Perl?" I feel it's high time that I give my own answer to that question.

About 2 years ago, I revamped my hub site using Django. This was the first step (I had hoped) toward a unified architecture for all my websites. It didn't turn out that way, but this project is still simmering on the back burner.

Most content management systems are designed as monoliths with turnkey features. This is a wonderful boon for authors who want to, for example, throw up a blog, as they have a low-overhead solution they can deploy and quickly start publishing with. But it presents problems if you want to customize them (anything outside of the turnkey modules and settings available) because you have to work around the existing features before you can implement your customizations. And it presents problems when managing multiple websites because now you have to manage multiple independent monoliths and often can't even benefit from automation.

I was hoping that my play with Django would be the beginning of a new relationship that would allow me to address these problems. Unfortunately, I was unhappy with where Django left me (and my hub site has been growing stale since then). In the meantime, I got a new job, which completely dominated my life for the better part of two years. (That is the explanation for my extended absence.) Then I got laid off in a downturn of pandemic proportions—literally.

But my dream of a unified website architecture never died. And I'd like to lay out the business case (as it were) for this solution and the requirements it will need to meet. I'll go further down the road in a later post and talk about architecture options.

In the prior episode of this story, I had written a test to detect the bug I want to fix. The djangocms-picture plugin includes errant whitespace inside of HTML anchor tags, which renders as annoying blue underlines next to the images.

I had also discovered why my test didn’t fail as it should have, because Django’s assertHTMLEqual() doesn’t detect all semantically significant whitespace differences. I’m sure it seemed a good idea at the time. But sorry, that’s not working for me.

Fortunately, it’s not that difficult to redesign assertHTMLEqual().

Last time, I began fixing a fairly simply space-within-anchor-tags bug in djangocms-picture.

I’m using this exercise as an opportunity to (a) try out a disciplined development process in the context of a Django application and (b) dig into the Django and Django CMS APIs.

This involves writing a failing test against the existing plugin rendering code, seeing it fail, fixing the bug, and then seeing the test pass.

My experience so far with this framework has not been as stellar as I had originally thought it would be.

I mentioned a couple fundamental issues off the bat with my website revamp using Django CMS.

I’m in the process of revamping my hub site, www.JTimothyKing.com. I had created a barebones site: only a single page of content, two columns (using djangocms-column), and a row of social-media icons (using djangocms-picture). I only made minimal changes to get it “good enough for now.”

There were still a couple unresolved issues, even before any serious theming, one of which was that the social-media icons are rendering with small, blue underlines in between. Before theming the site, I’d like to deal with this irksome quirk.

But oh! I thought, This also presents a perfect opportunity to apply my standard dev process to a Django project! Let’s go!

It was long past time to redo my hub site, www.JTimothyKing.com. It had been running Drupal for far too long. I won’t tell you what version. Suffice it to say that the version had been unsupported for quite some time before I finally decommissioned it.

Rather than upgrade to a new version of Drupal, I chose to revamp the site and move to Django CMS.