Web developer at the University of St Andrews digital communications team. Aaron joined the team in September 2015 and has been working with mainly front-end development (HTML, CSS, and JavaScript) and the DPL (Digital Pattern Library).

I’ve set out on a new adventure

As I write this, I’ve been working remotely for the digital communications team for a little over a month now and will formally leave at the end of July.

The reason being that my wife needed to move to Philadelphia for the next year to do research in the archives there—and I quite like her, so I’ve gone with her. While we’re excited about this time to be in Philadelphia, we’re sad to be leaving such an amazing community in St Andrews.

We have loved living in St Andrews and being a part of the community, with her studying and me getting a chance to help develop the website, it has been great. It’s made the decision to go overseas difficult; I will miss the team.

Getting to work using DSDM agile project management was one of the things I value most from my time as part of the team. I also enjoyed the opportunity to develop and help mature the digital pattern library, and so contribute directly to how the new University website will look and function.

The team has been amazing, I couldn’t have imagined a better team to be a part of, and it will be the standard against which I will measure my future teams involvement. I felt like I contributed and was valued for the work I brought to the University. I’m grateful to have spent the last two years with them.

Thank you.

Migrating a WordPress single install to a multisite – direct method

Migrating a WordPress single site install into a WordPress multisite isn’t exactly straightforward, but I’d like to present a method for those of you that are not scared of FTP, SQL queries or dropping some tables.

So, if you…

  • Have FTP access to both of your sites
  • Have some kind of database access for both of your sites
  • Aren’t scared of dropping some tables or editing a SQL export

Then read on.

1 – Your single WordPress installation

1.1 – The files

You’ll need the files for your single site install and specifically you’ll need the

  • media files wp-content/uploads/[years],
  • theme wp-content/theme/[your-theme] and
  • plugins wp-content/plugins/.

In this screenshot I’ve selected the folders that I needed, wp-content/themes/discoverstandrews, wp-content/uploads/2016, wp-content/uploads/2017 and the wp-content/plugins/ folder. Your themes, plugins and years may vary.


1.2 – The database

You’ll need to get an export of your database for the single install, I use the superb Sequel Pro on OSX for this, but you could use phpMyAdmin just as easily. The exported database should look something like this when opened in a text editor

2 – The WordPress multisite

You’ll need to do a little bit in the multisite before we edit the SQL file, so go create a new site (be sure to make a note of the new url for later). What we’re looking for is the id for that new site, you can usually find this from the [your-multisite]/wp-admin/network/sites.php page and hovering over the new site url. In Chrome it pops up in the bottom lefthand corner or you can copy the link address. Whatever way you find it just write down the site id, in my case it was 292.

2.1  Jump in the database

Now this part always makes me slightly nervous, trust me on this, but filter down your tables to your new site id. You’ll see stuff like wp_292_options and etc, as long as all you see are tables with your site id you’re good to go. Now delete those tables, as we’ll be adding them from the single install.

Your table may look differently to mine, so don’t panic if it doesn’t match exactly! This can vary depending on the plugins you have installed on your multisite.

Here’s what mine looks like from Sequel Pro:

That’s all we need for now in the multisite database, but leave your connection open as we’ll need it again shortly.

2.2 – The files

Now go and upload your files from the single site, remember for me it was the theme, plugins and uploads. The theme(s) and plugins go in the same place as they were on the single install, so no difference there (I just uploaded them in place, you could install them if you have the zip for the theme or plugins).

For the media files, look in your wp-content folder, you’ll see a folder called blogs.dir, inside of that are a bunch of folders with site ids. Go find yours and upload your year folders inside the files folder. So for me that was wp-content/blogs.dir/292/files/.

2.3 – Editing the exported SQL file

Now the fun/tedious part, we need to translate the SQL file (remember the one you exported for the single site?) into something that’ll work with your multisite. Open up your text editor of choice, we use Sublime text here, and we’re going to be adding the new site id to all our CREATE TABLE statements. So we’re changing CREATE TABLE `wp_commentmeta` ( to CREATE TABLE `wp_292_commentmeta` (. But as a word of warning…

DO NOT just find-replace wp_ with wp_292. This will lead to bad things, in my case it broke the media library links.

It’ll take a little bit of time but just find all the CREATE TABLE statements and run a find-replace for each thing, so wp_commentmeta to wp_292_commentmeta is great. Rinse and repeat until you have all of them with the id inserted into those tables names.

While you’re in there you might as well replace the single site URL to match what your new multisite URL is, this one is safe to do a straight up search-replace on.

2.4 – Import the SQL file

Once you have your SQL file setup you just need to import it into your multisite database. Sequel Pro makes this quite easy for me, but phpMyAdmin and other database tools will do this as well.

Take a backup of your multisite database, just in case something goes awry. If you’ve replaced all the CREATE TABLE statements you should be ok, and even if you missed one that part of the import should fail and not overwrite your tables. But that’s why you have the backup!

3 – Time to test your new site

Navigate to your new site and see that it looks and works as it should, both on the front-end and back-end. Make sure you can add posts or pages and edit them.

If you notice anything going wrong just drop those tables prefixed with your site id, edit the SQL file, and try again. You shouldn’t need to re-upload the files/media with any of the import, in my case I just had to do a few tweaks to the SQL file and reimport it before the site was up and running.

Now you can kick back and enjoy your single site that’s now safely inside of your WordPress multisite.

What our version numbers mean

By the end of March we will have reached a milestone: version 1.0.0 of the digital pattern library.

As I write this, we are currently on version 0.22.0. But what exactly do those version numbers mean?

Semantic versioning

Tracking changes in something like the digital pattern library is important. It helps people know what version of the resource they are using. At a glance it can tell them whether something has been fixed, a new feature has been added, or more.

We follow a versioning standard called Semantic Versioning 2.0.0.

Here is a handy graphic to explain it:

Image showing the versioning, breaking, feature and fix

As you can see, there are three levels of change:

  • Major (a breaking change)
  • Minor (a backwards-compatible feature)
  • Patch (a backwards-compatible bug fix)

To explain how this works, let’s use the analogy of writing a book.

We begin with version 0.0.0.

The author writes a draft of chapter one. This is a new feature, so he increments the minor version by one: v0.1.0.

Reading through the draft, he spots a couple of typos which he corrects. These are equal to backwards-compatible bug fixes. We are now at v0.1.1.

As new chapters are written, and typos are caught, the minor and patch versions increment accordingly.

Perhaps at version 0.32.4 the author feels his book is now ready to be published.

On publication the version number gets bumped to v1.0.0. This is the first major version of the book.

Any revisions would then affect the version numbers in the same way. Typo fixes would increment the patch version; new chapters would increment the minor version.

Translating the book into French, say, might bump the major version to v2.0.0. This version is now incompatible with the original v1.0.0 which is in English.

Version 3.0.0 might be in German, v4.0.0 in Spanish, etc.

Aiming for DPL v1.0.0

This is like what we are attempting to do with the digital pattern library.

We are aiming to reach v1.0.0 by the end of March. We are aiming for a product we believe is complete, and good enough to put our names to.

Of course, that doesn’t mean the DPL will be complete at that point. We will continue to improve it and add to it as we go along. But once it reaches v1.0.0 it will be good enough for us to release for more widespread usage.

A piece of software is only as robust as the foundation it has, and we want the DPL to be as strong as we can make it.

Why we have code standards and style guides

Code standards and code style guides are like two sides of the same coin. They essentially tell programmers in a team, or across a larger organisation, how to best write their code. Code standards are the rules and conventions at a high level, whereas code style guides are specific to a particular coding language. We have style guides for – amongst other things – HTML, CSS, JavaScript, PHP and XML.

Why have code standards?

There are many reasons why an organisation might want to have code standards, and there are some reasons we’ll cover for why you might not have them (yet).

Cost is a big concern: somewhere between 40–80% of the cost of a piece of software is in its maintenance. And given that the vast majority of code is not maintained by its original author, this cost can snowball rapidly as it takes more time for each programmer to understand the logic and style of the author.

At St Andrews currently, most developers have their own way of doing things, which may be fine for small, stand-alone projects but within an enterprise-level project this can lead to issues such as:

  • inconsistent code in terms of organisation, syntax, formatting, and naming conventions.
  • code bloat in production systems, often including code that is either never used or is out-of-date (e.g. hacks for redundant versions of Internet Explorer).
  • multiple implementations of functionality, with the consequential maintenance overload due to multiple chunks of code that solve the same problem in different ways, and an inconsistent look-and-feel due to multiple implementations of similar features e.g. tabs, sliders.
  • bugs and typos.
  • uncommented or poorly documented code.
  • unreadable code.
  • code from one site linked to from other sites, that if updated at source runs the risk of breaking features implemented elsewhere.

While it’s obvious that these inconsistencies and issues can result from multiple developers working across multiple projects, it can also be true for solo developers working on single projects. In other words, developers can be inconsistent even with themselves in the same project. We grow and change as developers, hopefully getting better with time, and without standards we can write code that is strikingly different just 6 months later.

If code standards and style guides are good, why are you getting them just now?

It’s costly in terms of time and effort to figure out what these guidelines should be and get them documented, even if you’re adopting ones that are available from the programming world at large. In addition to this we’ve got the task of getting a consensus among developers on which particular style to use. It’s a bit like asking art students who their favourite Renaissance painter is, you’ll get many passionate answers that are all probably great answers, but the trouble is that you’ve got to choose just one.

What if we don’t have standards?

The consequences of not having code standards are many:

  • code that is difficult or impossible to maintain.
  • code that is fragile and easy to break in unknown ways.
  • fear of updating or improving code that leads to forked code and/or duplicating functionality using different resources.
  • maintenance overload.
  • slows down development.

What is our objective with having these code standards?

Our objectives for introducing code standards and style guides are to:

  • develop an agreed standard for all code and ensure that code within scope adheres to these standards.
  • use industry best practices.
  • promote efficiency in maintaining code.
  • continuously improve our code.

That way we don’t have any of the scary, bad stuff that happens when you don’t have standards.

We want code that programmers can all work on, code that people can be proud of. When the code all follows a standard, it looks great, works great and the developers can all get onto more productive work rather than being bogged down on complex maintenance tasks.

What’s our scope for these code style guides?

We have begun with guidelines for the following languages:

As well as:

This is naturally quite a lot of work to define exactly what we want and how we want it, but hopefully you now have and idea of why we think it’ll be worth it. You can read our code style guides as we continue to work on them on GitHub.

TerminalFour programmable layouts

TerminalFour programmable layouts

The following article assumes you are an existing power user or administrator of T4 and have access to their community extranet site. It gives an overview of what programmable layouts are and provides useful examples of how they can be used to greatly simplify the setup of T4.

For example, consider the need to have a different navigation object to display the list of sections within a particular level of the site structure. Without programmable layouts you would need to have a page layout for each navigation object that links to each level of the structure. With programmable layouts you can have just one page layout with server side JavaScript deciding which navigation object to use based on criteria such as the name of the section or level within the structure.

Continue reading “TerminalFour programmable layouts”

Browser wars 2016

We are presented with a plethora of options when it comes to browsers and devices to access the web with, but which ones do the world at large use? Does this make a difference in how we design and build websites? This can be a rather math heavy topic, with various percentages and such, so prepare yourselves and I’ll try to keep the graphs to a minimum!

Continue reading “Browser wars 2016”

The digital pattern library is platform agnostic

At the University of St Andrews we have a digital framework called the digital pattern library (DPL), which is used to make the University digital presence consistent across the website. We primarily build in TerminalFour Site Manager but it’s not the only platform we build websites for and we aren’t the only ones making digital products either.

What exactly is the digital pattern library?

The DPL is the standard that we, or other designers and programmers around the University, reference when building digital content. The framework has all the colours, font styles and sizes, and code patterns that are used around the website. These code patterns are modular elements of websites that can be used on a variety of pages or web applications. They will have undergone testing to ensure they work on a wide range of computers, tablets and phones, making certain that they work and convey the same information to any visitor regardless of device. Continue reading “The digital pattern library is platform agnostic”

Sleep and technology

Technology can be good for our sleep and bad for our sleep, but how can it be both at the same time?

How is technology bad for our sleep?

WebMD explains why using phones before or in bed is bad:

Our brains: “As your brain revs up, its electrical activity increases and neurons start to race…”

Our bodies: “The physical act of responding to a video game or even an email makes your body tense.”

The small amounts of light from these devices pass through the retina into a part of the hypothalamus (the area of the brain that controls several sleep activities) and delay the release of the sleep-inducing hormone, melatonin.

Continue reading “Sleep and technology”

Our future with gadgets and technology

Let’s think about the future, and specifically about connected devices.

Say you have a smart coffee maker – it’s tied into your alarm clock and knows to make your coffee just how you like it for when you get downstairs.

It’s smart enough to know that you didn’t get enough sleep because you were up late, and it used a stronger roast than your typical beans.

You also don’t wake up feeling like a zombie because your alarm has been monitoring your sleep cycles and wakes you up at the optimum time, i.e. not in the middle of REM sleep.

What a way to start the day huh?

But let’s take it a step further. Let’s say your doctor recently diagnosed you with a heart problem and told you that you shouldn’t drink too much of your dark nectar of the gods. Should your coffee maker, knowing this, give you that third cup of coffee? Knowing that it could contribute to your heart problems and possibly kill you? Well unless it’s actually a sentient AI that wants to kill you … I don’t know. But I think it’s a fascinating idea that these devices could help protect us by monitoring all these data sources.

Continue reading “Our future with gadgets and technology”