Let’s Get Technical — Building a Prototype Environment for LibGuides CMS

by | Nov 30, 2021 | 0 comments

#

Against the Grain Vol. 33#5

By Denise FitzGerald Quintel (Discovery Services Librarian, Middle Tennessee State University) OCID: https://orcid.org/0000-0002-0730-6665

and Isaac Ingram (Web Developer, Middle Tennessee State University) OCID: https://orcid.org/0000-0003-1494-1779

Column Editors:  Kyle Banerjee  (Sr. Implementation Consultant, FOLIO Services)  www.ebsco.com  www.folio.org

and Susan J. Martin  (Chair, Collection Development and Management, Associate Professor, Middle Tennessee State University) 

Abstract

Library employees have long relied on Springshare’s LibGuides to connect with users, share information, and easily create web content, whether experienced designers or new librarians.  LibGuides CMS is a flexible out-of-the-box solution for many libraries.  As the library staff responsible for our main website content, we reached a point where we wanted to push the design and function of our LibGuides CMS content.  Pushing the boundaries of LibGuides CMS proved challenging, as the system does not provide a level of version control we are accustomed to in commonly used CMSes.  After locking ourselves out of the CMS editor with custom code, we recognized the potential risks, and wanted to see if there was a way to test features and functionality, without ever disrupting our live website.  

Introduction

Content Management Systems (CMS) are great options for users to manage online content without needing advanced coding knowledge.  You can build a CMS site quickly, with the content structure automatically in place, or at least relatively easy to place.  The shift from static webpages to content management systems has been steadily growing, with several open-source and hosted options.  In a 2013 survey, the most commonly used CMSes by academic libraries were the open-source choices of Drupal and WordPress and LibGuides CMS, hosted by Springshare.1  While open-source CMS options are free upfront, they require a significant investment of staff time and human resources to implement and maintain.  Upgrading to LibGuides CMS is an added cost to a library’s Springshare subscription but provides ways for libraries to integrate with other apps and websites, such as Learning Tools Interoperability (LTI) for integrating with Learning Management Systems, internal groups that allow for staff intranets, and APIs that work with discovery layers or other search portals.

CMSes, which make for easy content creation, also allow for granular level permissions.  Going beyond a single administrator, CMSes make room for editors, writers, and developers.  Also known as a distributed content model, this allows for multiple content creators within a single system.  With this model, organizations can disseminate content quickly, shared governance provides feelings of ownership to the creators, and can foster inclusiveness in any organization. 

With their distributed content models, CMSes have built-in solutions for potentially problematic situations.  Whether that is an editor gone rogue or JS code that accidentally breaks a site, CMSes like Drupal and WordPress have a way of rolling back edits, often referred to as version or source control.2  LibGuides CMS, albeit not expected to have a complicated development environment, does not provide a way to easily roll back to a previously saved version. 

The Usual Process

Normally, when we want to test any new functionality in LibGuides, we create a brand-new private guide and then add content to the guide using the Rich Text/HTML option.  Guide-specific styling (CSS) and JavaScript (JS) interactive features are then added using the Guide Custom JS/CSS option.  If we reach the 2000-character limit, we will then create a CSS and/or JS file, and upload those at the system level, under Look and Feel.  Springshare will then generate a link tag, which can then drop into our test guide’s Guide Custom JS/CSS option.  

As cumbersome as the workflow is, it is usually successful.  In those times where it is not as successful, the consequences can be unfortunate.  Springshare automatically runs jQuery for their guides and if you happen to forget this, and you accidentally add incompatible JS code, then the entire guide will break.  The only way to get the guide back online is by contacting Springshare who has the super administrator ability to remove your unwelcome code and get your guide back online.  You then continue with writing new code, peppered with fresh anxiety and embarrassment, and hope you don’t mess up again. 

The process to test new functionality in LibGuides CMS is somewhat clumsy and has the potential to take a site offline.  As a unit, we had learned from those pitfalls.  We still wanted to push the design and function of our site, which is when we began working on a way to introduce a level of version control for LibGuides CMS, where we could clone our site content, and prototype without the risk of disrupting our live instance. 

Building a New Process

To establish a development environment for reliable prototyping, we needed a web environment that matched LibGuides’ native appearance and behavior.  This meant building an environment that could replicate both Springshare’s administrative backend behavior and its front-end user interfaces.

Walker Library’s web developer, Isaac Ingram, successfully created a development environment for our LibGuides CMS using the following methods:

Using browser-based web development tools, we first identified the Cascading Style Sheets (CSS) and JS necessary to match that appearance and behavior, respectively.  We copied these required sources to a development system where they will be accessed through a web server.  For this system, we chose to use Vagrant to run a virtual machine with Debian GNU/Linux and the Apache HTTP Server installed. 

Though the required sources do not change frequently, the possibility exists, and they should be updated in that event to ensure the development environment matches production.  Rather than manually copy the latest copies of the sources, we opted to automate the process by installing PHP on the development system and writing a script to compare and download the sources from LibGuides should they change.  Furthermore, in addition to CSS, much of LibGuides’ appearance is controlled through HTML, and we use PHP’s interoperability with Apache to create dynamic pages matching that portion.

With the means to match LibGuides’ appearance and behavior outside the online service, we can prototype advanced HTML, CSS, and JavaScript in a space that protects us from inadvertently disabling the LibGuides CMS editor and live content due to coding mistakes.  Software to manage content and custom code will vary among organizations, and we have chosen the Apache NetBeans integrated development environment.  With NetBeans, we gain source code editing tools, repository management with version control, Vagrant administration, and a convenient means to rapidly preview our work in several web browsers.

• Vagrant, a software tool to customize, share, download, and run virtual machines locally to ensure testing occurs with the target environment and supporting software versions (https://www.vagrantup.com/)

• Apache NetBeans, a development environment that supports several languages (Java, JavaScript, PHP, HTML5, CSS) and provides tools to facilitate coding and common tasks (http://netbeans.apache.org/)

• Custom PHP to synchronize online web assets with a local repository, mimic a basic LibGuides environment, and provide web UI tools to manage guide metadata in the local repository.

It is important to note that the environment we created, although ideal for prototyping, cannot push edits to a live site, like most version control systems.  Our internal process is to add content to the development environment, test, retest, and then copy and paste our compatible code into the live LibGuides environment.  Even without the ability to deploy to our website, prototyping our designs and features is incredibly beneficial to our library’s web presence.  We can easily try out the web suggestions that we receive, quickly test for accessibility, and streamline our workflows, all without the risk of accidentally taking our site offline.  

Endnotes

1. Connell, Ruth Sara.  2013.  “Content Management Systems: Trends in Academic Libraries.”  Information Technology and Libraries 32 (2), 42-55.  https://doi.org/10.6017/ital.v32i2.4632.

2. “What is Version Control?” accessed March 4, 2021, https://www.atlassian.com/git/tutorials/what-is-version-control.

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *

Share This