WordPress policy

• Purpose

  WordPress enables University staff and students to quickly create a website or blog and configure and administer it without needing specialist programming knowledge. Due to the highly configurable nature of WordPress, it is essential that there are standards and procedures to ensure that:

  • WordPress (core, themes and plugins) is kept secure.
  • WordPress sites support University business such as teaching and research.
  • There is a good user-centred experience. 
  • Content is up to date and complies with copyright, consumer protection legislation (CPL), General Data Protection Regulation (GDPR) and other legal requirements.
  • There is an efficient process for supporting WordPress sites and owners.

• Scope

  This policy applies to University of St Andrews WordPress sites hosted with WP Engine. All new WordPress sites are expected to be hosted with WP Engine. Existing sites on the University of St Andrews network will be migrated on a case-by-case basis as standalone sites, or integrated into the multisite instance (wp.st-andrews.ac.uk).

  This policy is also subject to WP Engine’s terms of service:

  1. WP Engine service level agreement
  2. WP Engine terms of service.

• Applying for a site

  Any current member of staff or student may apply for a WordPress site by completing the online form through UniDesk. When applying for a site, the user will be asked for the following information:

  • name of the site owner and their University email address
  • name of the deputy owner and their University email address
  • title of the site
  • URL of the site
  • overall purpose of site and how it will meet the needs of users who visit it
  • when the site needs to be set up
  • when the site needs to be archived
  • any additional information such as custom functionality required.

  Applications will be reviewed by the Digital Communications team and assessed against the following criteria. The team can help applicants with alternative communication channels, hosting options or platforms if their request is not suitable for the University’s WordPress account.

  Site owners

  The site owner must be a current member of staff or a current student. Other users – including bank workers, retired staff members, honorary staff members or alumni – will not be allowed to be site owners of WordPress sites.

  Title of site

  The title of the site must comply with the University's house style and be as short as possible. Digital Communications will work with site administrators to ensure that a site name meets their aims and objectives. 

  URL of site

  The URL must comply with the links policy.

  University usernames must not be included in the URL.

  Conference sites must not include the year of the conference in the URL. The URL is easier to reuse if it is not dated.

  The Digital Communications team has the right to reject site URLs if they are not user-centred, include dates, or they are too similar to an existing site URL.

  Externally registered URL

  There may be cases where a site needs a different URL from the default format provided by the University. For example, academic collaborations between different institutions may require a site to have a URL that is not institution specific. In such cases, the site owner is responsible for registering the domain name with an external domain name registrar and notifying IT Services. The cost of registering the domain will sit with the site owner and not with IT Services or Digital Communications. Please contact digital communications to discuss custom domains. 

  There are three options for linking the domain name to the WordPress site. These are:

  1. Redirect
  2. Framed redirect
  3. Domain mapping.

  The domain name owner may configure a redirect from the domain name registrar to be either a ‘forwarding redirect’ or a ‘framed redirect’. If a forwarding redirect is used, the URL of the website shown in a web browser will change from the originating URL to the WordPress URL on the st-andrews.ac.uk domain.

  A framed redirect means that the originating URL is displayed in the web browser i.e. the user does not know that the URL is on the University WordPress site. The disadvantage of a framed redirect is that it is not possible to direct users to a sub-level part of the site. Therefore, the Digital Communications team recommend using forwarding redirects in most cases. If a site owner wishes to use a framed redirect, they should email the Digital Communications team with a rationale as to why this is required.

  A third approach is to use domain mapping, which is used for the following situations:

  1. There is an existing site elsewhere and it needs to be transferred to WordPress but the URL needs to be kept.
  2. There is a need to point multiple domains to a primary hosting account.
  3. There is a need to direct a URL to a sub-level page of the site.

  Applications for domain mapping must be agreed with IT Services.

  Purpose of site

  The site must have a genuine user-centred focus and purpose. The following sites will be allowed:

  • blogs of University Schools, departments, units or teams
  • conferences
  • core University business, including teaching and research
  • lecture series
  • research centres
  • research groups
  • research or teaching institutes
  • research projects
  • sports clubs affiliated with Saints Sport
  • student societies affiliated with the Students’ Association
  • workshops.

  The following sites will not be allowed:

  • sites for personal use
  • course-specific sites (for example, teaching materials for modules). The University Moodle or MMS systems should be used for teaching materials.
  • password-protected sites for minutes, documents, etc. If documents need to be password protected for internal use, these should be provided using OneDrive or SharePoint.
  • individual staff sites (research and teaching). A member of staff should use Pure to store details of their research activities. It is preferable that a staff member has their site hosted externally so if they leave the University their information is not removed.

  New individual staff sites

  Members of staff who wish to create a personal website to share their research or their teaching must not use the University WordPress installation. This is to protect the digital assets of staff in the event that they leave the University. 

  Existing individual staff sites

  Staff with existing WordPress sites on the University WordPress installation may wish to consider moving their sites to another host. The Digital Communications team can assist with providing an export of the site. Alternatively, the member may continue to have their site hosted with the University on the understanding that in the event that they leave the University or retire, they will no longer have access to amend their site if they no longer have a University computer account. These sites will be archived, and the Digital Communications team will offer to export the site so it may be moved elsewhere when that staff member leaves the University.

  Lifespan of a site

  If a site is created and no content is added within three months of the start date, the site owner and deputy will be contacted to enquire whether the site is still required. If there is no response after 20 working days, the site will be archived for 20 working days and then deleted.

  Sites will be archived under the following conditions. In each case, an email will be sent to all site owners and deputies a month before the deadline date in order to give them an opportunity to retain their site.

  Event site

  A site used to give details of an event such as a workshop will be archived six months after the end date of the event or the expiry date specified in the application for the site.

  Conference site

  When conference sites are created, the site owner will be asked if this is an annual conference or a one-off conference. The lifespan of a site will depend on which of these options is selected.

  One-off conferences will be treated as events, and the conference website will be archived six months after the last day of the conference.

  Annual conferences will remain live year round, but the site owner will be contacted six months after the last date of the previous conference to ask if the conference will run the following year. If the conference will not run the next year, the site will be archived at this point. Archived sites can be reinstated if the conference is confirmed as running again in the future. If the conference will run the next year, site owners must add a message to the site stating that the conference will run the following year.

  Project site

  A site used to report on the purpose and progress of a project will be archived 12 months after the the project has closed. Any associated project documentation that is not in the public domain must be stored elsewhere (for example, OneDrive).

  Some research projects require a site to persist as part of their funding agreement. In such cases, the site will be converted to static HTML and a redirect applied to send visitors to the archived site hosted on a subdomain. If this is not an acceptable solution for any specific project website, Digital Communications will work with site administrators to find a solution. 

  Sports clubs

  A sports club site will be archived if it has not been updated within 12 months of the last site update or if it is no longer affiliated with Saints Sport. The Sports Centre marketing and business development manager (staff) at the Sports Centre must be given access to all sports club sites to allow central oversight.

  Student societies

  A student society site will be archived if not updated within 12 months of last site update or if a society does not reaffiliate with the Students’ Association. The director of student development and activities ([email protected]) must be given access using this email address to provide central oversight of all student society sites.

  General sites

  All other sites will be archived if not updated within 12 months of the last site update.

  Archiving sites

  Archiving a site means that it will no longer be available to be updated via the WordPress interface, and some audiences may no longer be able view the site. The site owner has a number of options when a site is to be archived; they will be asked three questions:

  1. Do you wish to host the site externally? (For example, sites that are no longer affiliated with the University, Students’ Association or Saint Sport.)
     
     If site owners wish to move their site to an external host, Digital Communications will export the site (including any associated assets) so it may be moved to another host. If it is moved to another host, their site will be permanently deleted from the st-andrews.ac.uk domain.
     
     
  2. Does the site need to persist in the public domain? (For example, sites where a condition of funding is that the site would persist as publicly available.)
     
     If a site owner wishes for the site to remain in the public domain, they must give a rationale to Digital Communications. Sites that are to remain in the public domain must meet a clear user need or a requirement of funding. Sites which are archived but remain in the public domain will be converted into static HTML and redirects applied to send traffic from the original URL to the archive. A notice will be placed on the home page of the site to state that the site is longer updated.
     
     
  3. Is there a chance that the site will need to be reinstated in the future?
     If there is a chance that a site needs to be archived, but then reinstated at a later date, it will be marked as archived in WordPress and moved to a password-protected subdomain. This means that only staff at the University will be able to view it, but it can be easily reinstated at a later date.

  If the answer to all three above questions is no, then the archived site will be converted into static HTML and moved to a password-restricted section where University staff and students may still view the site but won’t be able to modify it using the WordPress interface. Digital Communications will retain the ability to make changes to any site, including those that have been archived.

• Users

  Digital Communications will have administrator level access to all WordPress sites hosted with WP Engine.

  There must be a minimum of two site administrators identified in order to set up a new WordPress site. Both of these people must be either current staff or students. Administrators must use a University of St Andrews email address; non-University email addresses will not be accepted.

  All WordPress site administrators are responsible for the users given access to their site. They must ensure that other users do not violate any of the terms and conditions in this policy. All administrators of a WordPress site must use a University email account.

  If an administrator leaves the University, it is their responsibility, or the responsibility of the second site administrator, to find someone to replace them. All sites should have two site administrators. If a site is found to have no site administrators, it will be automatically archived. There may be a process for a central team to sponsor a site in the absence of administrators, but this must be agreed by Digital Communications. 

  If the site has a demonstrable collaboration between different institutions, other types of users—that is subscribers, contributors, authors and editors—may be external to the University, and therefore may use a non-University email address.

  When a user who has contributed content to a site leaves the University, their user role will be changed to subscriber. This will ensure the attribution for their content is kept. If the user has created no content, then the user will simply be removed from the site.

• Content

  Content on WordPress sites must comply with the following guidelines:

  • Corporate Communications reserves the right to remove or archive any content from a WordPress site if it is seen to be a risk to the reputation or security of the University. Any decision to remove content will be agreed by the director of Corporate Communications. 
    
    
  • All WordPress sites on the central installation must show an up-to-date version of the University logo in either the header or the footer.
    
    
  • No personal data may be published unless these are necessary to support the wider purpose of a site. Where personal data is being published, the owner of the site may need to ensure the individuals concerned are made aware that their personal data is going to be used, along with the legal basis for publishing personal data.
    
    
  • The WP Engine platform is only usable for hosting public information (as per the information classification policy). Therefore, password-protected pages must not be created. If content needs to be restricted to certain audiences, it must be published through another route, such as OneDrive, MMS, Moodle, etc.
    
    
  • Sites on which content is no longer being updated will be archived. In some instances, sites may be archived more quickly than as detailed in this policy; for example, if the purpose of the site has been met, or when a member of staff leaves the University and the project or purpose for the WordPress site has to move with them.
    
    
  • All WordPress sites must not be used to store, display or transmit text or images that could be considered offensive such as pornographic, racially abusive or libellous material.
    
    
  • All WordPress authors and editors must be aware of the possibilities for copyright infringement. Making copyrighted video or audio material available, or reproducing images or text from other sources, may be a breach of copyright law and liable to legal action. Find out more about copyright at the University. 
    
    
  • Details of course fees, entry requirements, course content or other information that is covered by consumer protection legislation must not be added to WordPress sites; instead, link to the original sources.
    
    
  • It is permissible to embed video and audio from third parties, where such content allows this. The third party applications or service may need to be whitelisted to be accepted by the WP Engine firewall - email [email protected] with the request. Standard platforms such as YouTube and SoundCloud have already been whitelisted. Requests to whitelist new platforms will be responded to within one business day. Live video streaming is not allowed.
    
    
  • Where a WordPress site is considered part of core University business, it must comply with the University house style.
    
    
  • If you are planning on producing research outputs such as reports, articles or working papers, we recommend you contact the open access team ([email protected]) for advice to ensure you have considered factors such as metadata, persistent identifiers and long-term preservation.

• Security

  Keeping WordPress secure is of primary importance. The need to keep sites secure will override other requirements for functionality, appearance or content. The University and WP Engine will perform scans of the system as required to ensure that there are no potential vulnerabilities.

  Core WordPress

  Security or maintenance updates

  The option to defer an update of multisite or standalone sites in WP Engine will not be provided. The procedure for updating WordPress installations on WP Engine requires that automated update procedure tests are first carried out to make sure a site is working correctly before an update. A backup will be taken before the update.

  Once the update is applied, the automated process reloads the site and tests are performed to ensure everything is working normally. If the install is not working correctly, it is immediately reverted to the previous version.

  Functional updates

  Functional updates add features and options to WordPress core. WP Engine will first test the new version before making it available. For multisite installations, Digital Communications is responsible for coordinating the test on a staging server before seeking Change Advisory Board (CAB) approval from IT Services to update the production instance.

  Currently, the University has a small number of standalone WordPress sites. The Digital Communications team aims to move all standalone WordPress sites into the central multisite. In the meantime, for standalone instances of WordPress, site administrators have the option to test the new version on a staging instance before applying the update to the live site. The Digital Communications team will have oversight of all the standalone instances on WP Engine to ensure that administrators know how to perform the updates and to ensure that all sites are on the same version of WordPress.

  It is possible to defer an update for up to 60 days to allow sufficient time to test the sites against the new version of WordPress.

  Plugins

  Plugins allow users to easily add extra functionality to WordPress sites. Plugins are provided by third party or in-house developers. If a new version of a plugin becomes available, the following process should be followed:

  1. Test the updated plugin on a separate test instance of WordPress that is identical to the production instance. Once it has passed checks to ensure it does not compromise the functionality of the sites, a backup of the live site will be made before it is updated. CAB approval does not need to be sought for updates to plugins.
  2. A record of plugins and their versions will be updated accordingly by the Digital Communications team.

  If a third party plugin is no longer actively developed or supported, a decision must be made about whether to remove the plugin or replace it with an alternative.

  Themes

  WordPress themes control the appearance of sites; they may also contain features that affect the functionality of a site. It is important that themes are kept up to date. If a theme needs to be updated, the following process should be followed:

  1. Updated theme will be tested first on a separate test instance of WordPress that is identical to the production instance. Once it has passed checks to ensure it does not compromise the functionality of the sites, a backup of the live site will be made before it is updated. CAB approval does not need to be sought for updates to themes.
  2. A record of themes and their versions will be updated accordingly by the Digital Communications team.

  Size of site

  By default, the maximum site upload space quota for a site will be 500MB; this may be increased on a case-by-case basis. The default maximum allowed upload size for a single file will be 50MB; this may be increased on request up to 200MB. Contact [email protected] to upload files larger than 200MB.

  WordPress memory limit

  The default WordPress memory limit is 40MB for a single site or 64MB for a multisite. These values may be increased on request via [email protected] to a maximum of 512MB.

  Service level agreement

  If a routine University scan reports an issue with a WordPress site, it will be resolved according to the following criteria:

  • Critical - fix as soon as possible
  • High - 4.5 working days
  • Medium - 9 working days
  • Low - 2 weeks

• Redirects

  From WordPress site to external site

  A temporary redirect may be used where the site has been moved to a different host. The redirect will be kept for six months. A permanent redirect of a site to an external site will not be permitted.

  From external site to WP site

  See section on applying for a site.

• Design

  WordPress themes control the appearance of sites; they may also contain features that affect the functionality of a site.

  The number of themes made available to site owners must be kept to a minimum. New WordPress sites will be expected to use a theme that is based on the digital pattern library (DPL). In due course, it is expected that existing sites will adopt a theme based on the DPL.

  In-house custom themes must be version controlled within a Git repository that is available to the Digital Communications team for testing before being applied to the production instance of WordPress.

  If a third party theme is no longer actively developed or supported, a decision will be made on which should be used as an alternative.

• Additional functionality

  Plugins allow users to easily add extra functionality to WordPress sites. Plugins are provided by third party or in-house developers.

  Plugins are managed by the Digital Communications team to ensure they are tested, kept up to date and that the functionality is not being duplicated by a similar plugin.

  New plugins may only be added where there is a good case for it to be added and if it does not duplicate the functionality of an existing plugin.

  Where possible, plugins should be sourced from wordpress.org. Plugins must be compatible with the current version of WordPress core.

  Plugins developed in-house must be version controlled within a Git repository that is available to the Digital Communications team for testing before being applied to the production instance of WordPress.

• Support

  General support

  All requests for help should be sent to [email protected]. The support call will be directed to the appropriate team who will reply within the terms of IT Services service level agreement. Where appropriate, assistance will be sought from WP Engine to resolve an issue.

  It is the owner’s responsibility to maintain content on their site. If assistance is required to add or edit content, the owner may raise a support call to seek help.

  Training

  There is provision for basic training for using WordPress. If you require assistance, you should raise a support call by emailing [email protected].

  Backup

  WordPress sites are backed up by WP Engine on a daily basis at around 1.30pm. Restoring older versions in the event of data loss or improper content can be manually initiated by the Digital Communications team via the WP Engine interface. The backup contains all the WordPress core files, themes, plugins and database. Backups are kept by WP Engine for 30 days before being deleted.

  Certain files are excluded from the backup. These exclusions mainly include directories and files from caching plugins and backups.

• Transition between current and future state

  WordPress sites are currently hosted on the University network in a number of locations. For example:

  1. WordPress multisite (wp.st-andrews.ac.uk)
  2. Arts computing server
  3. secondary accounts (www.st-andrews.ac.uk/account_name).

  In the future, all WordPress sites will be hosted with WP Engine unless there are good reasons to continue hosting a WordPress site on the University network. If in doubt, ask for advice by submitting a support call to [email protected].

  The overall objective is to standardise, simplify and consolidate the way WordPress is managed. Due to the complexity of our current WordPress sites, it will take time to ensure that all sites comply with this policy. Therefore, a pragmatic approach needs to be taken to ensure minimum delay in moving sites to WP Engine.

  WordPress multisite (wp.st-andrews.ac.uk)

  Requests for new sites will be accepted before and after the migration in accordance with the guidelines in this policy. 

  Current sites that do not comply with the guidelines in this policy will be reviewed on a per case basis, to improve them or remove them from the multisite.

  Arts computing server

  New sites will need to be created in the multisite instance on WP Engine unless there is a particular requirement to have a separate installation on WP Engine or on a University server. Current sites will be migrated on a per case basis, with preference to having sites hosted in a multisite. This migration can only take place after the migration of wp.st-andrews.ac.uk to WP Engine. Completion will depend on the amount of work required to move the themes and plugins of these sites.

  Secondary accounts

  New sites will need to be created in the multisite instance on WP Engine unless there is a particular requirement to have a separate installation. Current sites will be migrated on a per case basis, with preference to having sites hosted in a multisite after the migration of wp.st-andrews.ac.uk.