Why I custom code my personal sites

The static route

When I built my first website, I wrote all of the HTML by hand. At that point, it was just HTML. It was annoying to replicate the navigation bar across every page, even though I only had a few pages to update.

I tried a few different methods, such as using frames, and adding the common code via Javascript. I also tried reducing the number of pages on the site that I needed to update, by adding a dropdown and opening some of the pages in a new window, sans navbar. The Javascript method stayed on the site for quite a while.

Continue reading “Why I custom code my personal sites”


SEO and technical issues we encountered in Drupal 7

Since I joined City A.M., we’ve been gradually migrating away from Drupal 7 to a fully bespoke CMS built on Laravel. We had planned to do this anyway, but we accelerated parts of the migration as we hit issues that we were unable to solve. Here’s a summary of the main ones.

Continue reading “SEO and technical issues we encountered in Drupal 7”

Rebuilding the post editor at City AM

When I joined City AM, one of the first things I experienced was the post editor. It did the job, but it was not particularly quick or intuitive to use. We had to add new fields in a predefined way – and doing so usually added extra work for the content team. Plus, there were a number of tasks that had to be done outside the system – such as finding and resizing images from Getty.

I knew we needed to take a radical approach and consider scrapping the existing post editor.

Continue reading “Rebuilding the post editor at City AM”

The Washington Post: publishing observations

There’s a good story over at Journalism.co.uk on the Washington Post redesign (“New WaPo ‘flexible’ homepage completes site redesign“).

Here’s a quote that stands out:

If you’re going to be quicker, agile and innovative, you can’t be in a place where it takes you six months to build something.

I’d agree with that, and I’d add that it’s risky to have any lengthy period of uninterrupted development. Even one month is a long time, particularly for a small team where time is so precious. Big projects need lots of work – but it’s not just about completing the task, it’s about doing it right. Even with perfect project management (is anyone perfect?) it’s surely better to spend between a few days and a couple of weeks building core functionality, and giving the primary user(s) an early demo to see if you’re on the right track.

In terms of the platform that the Washington Post uses:

The publishing process on the outlet’s website is now entirely powered by Arc, a collaborative tool developed by engineers and journalists

The Post uses WordPress for 70 per cent of the content it produces – Arc integrates through APIs with WordPress and other platforms, such as the Washington Post recipe or quiz database.

Emphasis mine. If WordPress still powers a large part of the process, then it’s not entirely powered by Arc. It sounds like WordPress is largely used for the back-end CMS with some custom tools added onto it, while the front-end of the site is entirely bespoke.

If that’s the case, then that makes a lot of sense – mainly because I think it’s far better to build a theme in Twig than in pure PHP.

Based on this assumption, I’ve updated my CMS usage chart to include the Washington Post.