Squiz Matrix site go live checklist

(Ryan Archer) #1

I am currently reviewing what documentation we have in regards to performing a 'pre-flight' check before a Squiz Matrix website goes live. We have some good notes in our Wiki but it's fairly brief (it is referred to as a minimum checklist):

 

  • Details - Is the Site Name correct? Are the Index, Not Found Page and Archived Asset fields all pointing to appropriate pages?
  • URLs - Has one or more URL (i.e. domain or host name) been applied to the site?
  • Public access - Once the appropriate URLs have been applied to the site, have the domain names been added by IT to the external DNS (and not just the internal DNS)?
  • Permissions - Has Public Read Permission been granted, to the Web Site asset and to all its child assets that need it?
  • Workflow - Has any Workflow Schema been removed from the Web Site asset after being applied and cascaded down to all of its child assets that need it?
  • Metadata Schemas - Have all appropriate Metadata Scheams been applied to the Web Site asset and cascaded to all of its child assets that need it?
  • Metadata - Have all appropriate Metadata fields been populated with genuine content on the Web Site asset and all appropriate child assets?
  • Linking - The Web Site asset and most of its child assets, particularly pages, should have Linking Type 1; have all those assets or pages that are not to appear in system-generated navigation menus been set to have Linking Type 2?
  • Settings - Has the Web Site asset and all of its children been given appropriate Designs or Design Customisations for the Frontend and for Login pages?
  • Lookup Settings - This is where Paint Layouts (a special type of Matrix "sub-template" allowing for extra functionality when laying out pages) are applied to assets (pages, asset listings etc.). Usually Paint Layouts are NOT applied to Web Site assets, but mainly to pages within websites. Have appropriate Paint Layouts been applied to appropriate pages in the site.

 

I just think more could be added to it. Does anyone in the community have a generic Squiz Matrix based website pre-flight checklist that they use? @Bart, does Squiz admin support have a recommended approach?

(Nic Hubbard) #2

Make sure to view your website when logged out of Matrix. We all get used to being logged in and viewing pages. So make sure you test the entire site as a public user. This has bitten us before.

(Anthony Ponomarenko) #3

An incognito window in your favourite browser is very useful when testing

(Tbaatar) #4

Make sure;

 

- media asset and design assets have public permission before going live.

- triggers work with live assets

- asset listing or any dynamic listing work with live assets

- setup robot.txt, Google sitemap, website sitemap and analytics installed

 

also

 

- replace placeholder stock images with purchased images

- receipent emails for form submissions is set to the correct department/people

(Bart Banda) #5

The checklists that Squiz production uses differ from project to project based on what's involved, but here are some generic ones they use:

 

- Grammar and spelling are correct (homepage, main pages)

- Any temporary assets have been removed

- Development urls have been removed

- Any superflous redirects or remaps have been removed.

- Designs, content and configuration assets have been changed to live status. Ensure any exceptions to publishing have been noted and potentially archived to avoid accidental publishing.

- Permissions have been reviewed for all assets. The site has been browsed as the public user to ensure all permissions are correct.

- Any assets that should not be publicly visible have public deny access applied (Users and user groups)

- Any triggers required to be functional have been enabled and tested or dev ones disabled

- Error and system logs checked for any issues

- Any paint layouts have been applied correctly, particularly if a new URL has been applied. Confirm the paint layouts are applied on the new urls.

- If the new url is not yet switched in DNS a local host file entry has been used to check that the site browses as expected on the new url 

- DNS change (if required) has been scheduled 

- 

 

 

Also, here are some others I can think of:

 

- Run broken links report (good to use an external one as well to run it in a context of a user visiting your site)

- Check /_performance on the home page and some key pages and landing pages to ensure they are optimised and not unnecessary dev or test assets are still being used

- Run an accessibility report on the homepage and on your key pages (

- Run google page speed and pingdom speed tests (

- Check and review caching settings and make sure you've got proper cache clearing triggers set up

- Send your page out to internal people to test

(Douglas (@finnatic at @waikato)) #6

+1 for the Google Page Speed test.  Easily done via the web and useful to identify problems with site setup and server responsiveness - but both may be better done mid development and not left towards late in development when changes may be difficult to achieve without rework.

 

If you're using a responsive or adaptive design, testing on a range of actual devices or with Chrome set to a specific device is also worthwhile - although Page Speed will do some mobile testing for you.

(Ryan Archer) #7

I like using the Varvy tool for checking pageSpeed https://varvy.com/pagespeed/. It appears to be based on Page Insights but I just like it's straightforward and frank approach.

(Tbaatar) #8

Be sure to create Remap list for any URL changes, and also monitor Google Web Developer Console for any errors, and extract the not found page and create a remap to the relevant page/section.

#9

Cross browser and device testing via tools such as browser stack ( but generally this is at the design testing stage anyway but it’s good for sign off)

Great list!


We always make sure we have people trained before a site is launched - so make sure your editors are aware.


Also if you have using edit+ make sure the node is configured in the API.


If you have subdomain make sure these is applied to your web services folder as well - including your designs etc ( depends how you configured)


If using online forms make sure force secure is checked.


Double check you have the appropriate protocols applied to your site asset.


Another thing for your schemas make sure if there are any customizations or nested helpers - that they are live and publically readable