Reviewing Webspark 2 Sites Migrated to Acquia

This document is for:

Content administrators/site owners who are reviewing their site after it has been migrated from Pantheon to Acquia.

Intro

Your site has been migrated from Pantheon to Acquia. As a part of this process there have been changes to the code structure and permissions on your site to make it work in the new Acquia multisite environment. If your site was not on the latest Webspark 2 release (Webspark 2.15), it has also been updated by developers at Acquia as a part of the move. At this stage, you will be sent a link to the site in a non-live Acquia environment for you to review.

The developers 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 migrated/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 the migration and update.

Checking your content

How to check:

Visually: Compare the Acquia test site to the live site side-by-side:

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

Your site may have undergone some Webspark 2 updates in the process of being migrated. If so, 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 releases that were 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

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

Note: The database you are editing when making content edits in the Acquia test environment will eventually become your live database, do not make any changes you don't intend to keep.

Specific things to check:

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

Permissions

There are global permissions changes made when moving sites from Pantheon to Acquia. For more information about these changes, see the Acquia FAQ.

Browse the site as an anonymous user and ensure that content is still visible as it is on the live (Pantheon) site.

Log in, and ensure you still have similar ability to see and edit content in the administrative interface as you did in Pantheon.

Sitemap

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

Email

If your site is configured to send emails, you will need to confirm emails are sending from the new Acquia environment.

The way that you test your email is different depending on how your email is configured in Drupal.

Through the SMTP authentication support module:
- Visit /admin/config/system/smtp while logged in as an admin to see how your email is configured.
- At the bottom of the page listed below, there is a form to "Send test email" to yourself. Save the page and confirm you receive the test email.
Through the MailSystem Module without SMTP module:
- Visit /admin/config/system/mailsystem to see how your email is configured.
- There is no way through the UI to send a test email for sites that are set up through the MailSystem module without also using the SMTP module.
- If your site has forms on it that generate emails on submission, submit a test submission of the form and confirm you receive the test email. Note: This database will eventually become your new live database, so you may want to delete or clean up any test submissions you create here.

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

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 about 20 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.

Degree Pages and RFI Forms

If the "ASU Degrees and RFI" module is enabled on your site, you should check the appearance and functionality of the degree pages and RFI forms on your site.

You can tell if the ASU Degrees and RFI module is enabled by visiting /admin/structure/types and seeing if the "Degree listing page" and "Degree detail page" content types exist. If not, you are not using the degree pages or RFI forms and do not need to review them.

If you are using the RFI forms, one way to test them is to go to admin/content and use the content type filter to view all of your Degree listing pages. From these pages you can click through to the degree detail pages as well. You can compare these visually and functionality-wise against the Pantheon version of your site to see if there are any discrepancies.

Review Checklist

	Visual check (comparing to live/Pantheon site)	Functional check (creating/editing content)
sitemap.xml		N/A
Email	N/A
Content types
Views		N/A
Webforms
RFI/Degrees		N/A