I spent pretty much all of this week working on the new versioning system for the Books and Borrowing project, which I have now managed to complete.  Last week I made some good progress on the redevelopment of the API to enable data queries to be limited by version, and this week I was able to complete the work.  With a fully working new API running on my laptop, I considered updating the live system as the next task, but decided against this.  Updating the live system would have meant regenerating all of the data, and I realised that this would mean the new ‘version 1.1’ data that is already being worked on in the CMS would therefore be fully integrated into the front-end.  This is something we don’t want to happen yet as Matt and Katie are still working with the data and need it to reflect the state it was in at the official end of the project.

Instead, I began the process of creating a new version of the front-end that would connect to the new API and would be able to target and display specific versions of the data.  I decided to track the selected version throughout the front-end by means of both session variables and URLs.  Session variables on their own could be used to track the chosen version, but we also needed to include the version number in the URL in order to enable users to cite / share / bookmark specific versions.  This meant that every single URL that is generated throughout the site needed to incorporate the version number, including WordPress navigation menu items and other WordPress pages.

Adding in session tracking throughout WordPress brought some difficulties.  My session data was somehow getting overwritten as I moved between pages, with WordPress session data getting added in and replacing some of the variables I had set.  This took some time to get to the bottom of, and it turned out that WordPress’s emoji system was causing the problems.  I found a guide to disabling this system here: https://smartwp.com/disable-emojis-wordpress/ and once I’d followed these steps my session variables worked as I’d intended.

For most users the front-end will not appear to be any different.  It is now set up to default to the most recently published version of the data (including all earlier versions too) and none of the page URLs have changed.  The only thing that is different is the ‘cite’ popup, which now references the current version.  It also includes a link to this version in the URLs that appear, as the following screenshot demonstrates:

This is to ensure that the citation will always reference the version of the data the person cited.  If we didn’t include the current live version in the citation URL then the link may lead to different results if/when we publish a new version of the data.

I also updated the footer of every page to include the current live version of the data, as you can see in the following screenshot:

I also included a link in the footer to the new ‘Versions and changes page, which you can see below:

This still has some placeholder text and then lists all of the live versions of the data, including the version number, a description and the date of publication.  One version will always be selected (in blue and with a tick).  If you press on ‘Version 1.0’ this then sets the entire site to use this version of the data – everything including lists of libraries, facts and figures, registers, pages, borrowing records, search results and on this day items will be limited to data created as part of this version (or earlier, if applicable).

When an earlier version is selected, every page of the site has the version number in the URL, for example ‘/libraries/version-1.0’ and the selected version is tracked throughout the site.  To make it obvious to users that they are not looking at the most recent version of the database a warning is displayed on the screen, as shown below:

As with the ‘top’ link this box stays fixed in the bottom corner of the screen.  Pressing the ‘return to the most recent version’ button takes you to the homepage with the most recent version reinstated.

Independently of all of this, I’ve also updated the search results to add in a version filter, as shown in the following screenshot:

So for example, if you’re viewing the current version of the data (1.1) you can see how many borrowing records were created as part of this version as opposed to the earlier version, and filter the results if you wish.  Note that if you’ve set the site to use version 1.0 of the data then the 1.1 search results wouldn’t display and the 1.1 filter option won’t show up.

It’s taken a huge amount of effort to get all of this in place, updating pretty much every part of the Books and Borrowing system, but it’s now thankfully all in place.  The only thing left to do is to actually add all of this to the live site, which I was intending to do next week.  However, Matt and Katie are still doing research using the live site at the moment and I therefore need to hold off until they have completed this work.  This is because whilst I work on the updates the live site will temporarily include data from all versions, which will obviously affect the data they extract.  I’m probably going to have to hold off going live with the updates until August, as I’ll be on holiday and then at a conference between now and then.

Also this week I attended the launch of the Iona place-names resource on Monday evening, and it was great to see the resource (see https://iona-placenames.glasgow.ac.uk/map) go live after working on it over the past few years.  The Berwickshire place-names team also launched their published volume at the event, which was also great to be a part of.

Also this week we finalised the archiving of the old Cognitive Toponymy website, and the archived site is now available here: https://conifer.rhizome.org/UoGLibrary/cogtop/20250430094955/https://digital-humanities.glasgow.ac.uk/cogtop/