When I launched 24 ways in 2005, it was pretty much a last-minute project. To get the site live quickly, I just reached for the blogging system Textpattern, as I was familiar with it. Textpattern did a good job managing articles, comments, RSS feeds and so on, but for one reason or another development stagnated.
Textpattern’s flexibility enabled me to implement some custom features as plugins (like the day-by-day navigation down the side of the article pages) but basic features like comment spam detection were causing problems. Replacing a CMS isn’t usually a fun job, so I carried on with Textpattern for longer than perhaps I should have.
Fast forward to 2012, and we now have our own CMS, Perch. I’m currently working Perch 2.1, and so it made sense to rebuild 24 ways using it and at the same time test the new features I’ve been working on.
Rebuilding the site with Perch took about a day, and migrating the content took another day on top of that.
The design hasn’t changed, but we’ve changed the comments functionality a little. Comments can be a real challenge – very often they don’t add anything of value to a post. We’ve all see cases of people rushing to post the first comment, just posting something useless, trolling or getting into pointless arguments about things only tangentally related to the topic of the post. I’d thought about removing comments from the site all together.
We do get lots of useful comments, but they can get lost in the noise. To try and combat this, I set about creating a system which I hope will surface the good comments, and bury the less useful ones. I’ve done that by adding a simple voting system (a helpful or unhelpful vote on each comment) with the list sorted from most helpful to least.
This has the obvious effect of putting the most helpful comments at the top, but sorting comments by something other than time has a useful secondary effect. ‘First’ comments are now no longer valid – what appears at the top is the ‘best’ comment, not the first. The fact that the comments are not sorted by time makes it hard to have an argument with another commenter, which helps solve another problem.
Having the site built in Perch has enabled me to immediately implement those improvements to comments, and to implement Akismet spam filtering. Using the Perch API, I built an app (most of it extracted directly from the existing Blog app) to handle comments on any sort of content. I’ll be packaging it up and making it available on grabaperch.com once 2.1 is done.
Eating my own dog food
Despite leading development on the core of Perch, I don’t spend a lot of time building sites using it. Rebuilding 24 ways alongside Perch 2.1 has proved to be incredibly useful in both finding bugs in my new code and in identifying features that are needed.
Querying across multiple pages
I’ve implemented each year as a page containing a region with 24 items. This meant that wherever I needed to display a list of articles from multiple years (such as the author detail page) I would need to be able to filter articles across multiple pages. So one big improvement in 2.1 is that the
page option in
perch_content_custom() now will accept a list of pages, or even a wildcard string. You could, for instance, use a value of
/products/* to display content from any product pages a client had dynamically added. That will be useful.
The 24 ways Authors page is a region containing multiple ‘author’ items. An article is then associated with an author by using a dataselect to list the authors. As I needed to display the author’s first and last name in the select box as labels, the
dataselect label options can now take multiple field IDs, which are concatenated to form the label.
When displaying an individual article, I needed to get the article title to use in the HTML title tag. That’s easy enough, using the
skip-template option, but then I also needed the templated HTML output for the rest of the page. Needing to query for the data twice seamed like the sort of thing a lesser CMS would do, so I added a
return-html option for using alongside
skip-template. This gives you the usual raw data output, but then also returns the templated HTML for use without needing to re-query.
One thing we knew we wanted to add to 2.1 was the ability to filter a region by multiple fields. 24 ways helped test this, as we need to do things like list all articles that are by a given author and are set to be live on the site. The multiple filters can be AND or OR filters and are really quite powerful. They enable you to do things like filter a list of properties that are houses, with two bedrooms or more, cost more than £100,000 and less than £500,000, for example.
The basic image resizing in Perch has been the same for a couple of years, so I thought it was time for some improvements. The first thing I added was image sharpening. Scaling images down tends to make them a bit softer, which is usually undesirable. A new
sharpen attribute on image tags lets you set a value from zero to 10 for the amount of sharpening you want to apply. It defaults to 4, which is usually about right to correct the natural softening that occurs, and you can tweak that up or down or turn it off.
The other big feature for images is a
density template tag attribute. This is for producing sites to work well with hiDPI screens like Apple retina displays. Density defaults to 1. If you set it to 2 and set a resize width of, say, 200 pixels, Perch will actually scale the image to 400 pixels, but then display it at 200 pixels. The density is doubled, and it all happens automatically. Of course, it doesn’t need to be 2, you can set the density to 1.4 or whatever value makes sense to your project.
This change makes Perch ready and able to serve any of the proposed responsive image
Perch 2.1 isn’t done yet, as there are more features and improvements we need to add. We’ll be announcing what those are once they’re ready. 24 ways is running a beta of 2.1 and the new Comments app, and it should be available soon. It’s shaping up to be a really useful release.