finger pointing at a laptop screen

Reviewing Webspark 2 Quarterly Updates

This document is for:

Content administrators/site owners who do not consider themselves developers and who have hired a developer to deploy quarterly updates.

Intro

Webspark 2 receives quarterly code updates that will need to be applied and deployed by someone with dev expertise in Pantheon. Once those updates are applied, your developer will send you a link to the site in a non-live Pantheon environment for you to review.

The developer will have ensured that there are no back-end problems with the code update on your site. But in addition to those code-checks done by the developer, you as the site owner will need to review the updated site before the updates are deployed to production. There are two main reasons why it is important for a content administrator/site owner to also review the site after updates:

  • Visual bugs can occur that are not code errors and don’t leave a trace in the logs. A developer who is not familiar with the content of your site will be unable to spot visual/front-end bugs the way a content administrator/site owner will. 
  • Content creators and editors are the best people to test their usual process for content creation and editing.

The purpose of this document is to give you a handy guide for some pieces of your website to check when you are reviewing these quarterly updates.

Checking your content

How to check:

Visually: Compare the updated site to the live site side-by-side:

Compare pages on your updated site with the same pages on the live, un-updated site. The updated version should, in general, be visually identical to the un-updated version.

Sometimes updates will introduce intentional visual changes to existing content, for example to keep up with updates to Unity. If this is the case, it may be explained in the release notes for the Webspark 2 release that was applied to your site. If you are unsure if a change is intentional it can’t hurt to mention it to the developer who asked you to review, any change is worth investigating! 

Functionally: Test the function of your site

Log in as an admin user on the updated site. Perform some of your most common site-editing tasks, for example:

  • Edit existing content and/or media
  • Create new content and/or media
  • Add or remove users

You don’t need to worry about messing up your content while testing your site–the database in the test environment is not going to be moved along with the code updates to the live environment.

 

Specific things to check:

If your site is small, it may be feasible for you to check every page of your updated site and compare it to the live version. If your site is larger, here are a few key areas to check your site.

Sitemap

Should exist at /sitemap.xml in the test environment, and its contents should be the same as /sitemap.xml in production.

Content Types

Out of the box, Webspark 2 comes with only two content types: Basic Page and Article. If your site has additional content types, it’s a good idea to check a piece of content of each custom content type to make sure it is still displaying correctly.

 

How to check your content types:
  • Log into your site as an admin user.
  • Visit /admin/content. In the “content type” select box you can see a list of the content types being used on your site (see screenshot). The example in the screenshot provided has 5 content types. Three of them are custom to this site and warrant extra review.
  • Select a content type and hit “filter.” 
  • Click on the filtered content to review a piece of content of each custom type, both visually (comparing to live/unupdated site) and functionally (editing content as you usually do). 
A screenshot of the content editing screen in Drupal 9
A screenshot of the content editing screen in Drupal 9

Views

The views module allows administrators and site builders to create, manage, and display lists of content

Visit /admin/structure/views on your site to see a list of the views on your site. Every Webspark 2 site includes 19 views by default, and most of these are administrative views that only show content to logged-in users (like you!). You do not need to review these views when you are reviewing an update.

If you have custom views that show on the front-end of the site (for example, a list of recent news or blog articles) you will want to review them visually when you review the update to ensure the results that are being shown on views are comparable to your live/unupdated site.

Webforms

Visit /admin/structure/webform to see if your site has any Webforms (every site has a contact webform by default which you can ignore if it has zero “results”, meaning it is probably not placed anywhere on the site where users could submit it).  By clicking on the title of the form from /admin/structure/webform you can view the form and submit a test submission.

 

Review Checklist

 

Visual check 

(comparing to live site)

Functional check

(creating/editing content)

sitemap.xml   N/A
Content types    
Views   N/A
Webforms