This policy covers all WordPress sites hosted within the University's WordPress multisite installation. All sites within the multisite are found on the domain wp.st-andrews.ac.uk.
For academics and researchers who require a site for a research centre, institute or project, you may wish to contact email@example.com for advice and support.
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.
This policy applies to University of St Andrews WordPress sites hosted with WP Engine. The expectation is that new WordPress sites will 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:
3. Applying for a site
Any current member of staff or student may apply for a WordPress site by completing the online form on the WordPress multisite (wp.st-andrews.ac.uk). When applying for a site, the user will be asked for the following information:
- name of site owner and their University email address;
- name of 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.
3.1 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.
3.2 Title of site
The title of the site must comply with the house style and be kept as short as possible. Digital communications will work with site administrators to ensure that a site name meets their aims and objectives.
3.3 URL of site
The URL must comply with the URL policy.
University usernames must not be included in the URL. Conference sites must not include the year of the conference in the URL of the site as it makes the URL easier to reuse if it is not date specific.
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.
3.3.1 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:
- Framed redirect
- 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:
- There is an existing site elsewhere and it needs to be transferred to WordPress but the URL needs to be kept.
- There is a need to point multiple domains to a primary hosting account.
- 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.
3.4 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
- 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
The following sites will not be allowed:
- sites for personal use (see 3.4.1);
- course-specific sites e.g. 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 disseminated 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.
3.4.1 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.
Sites on the University WordPress installation must be administered only via single sign on, which ensures that users are required to have a University account. Once staff have left St Andrews and no longer have a University account, they will be unable to administer their site. This means that the site would need to be archived or deleted by the digital communications team, and the staff-member would lose all of the content they had been hosting.
Due to this, we do not allow individual staff sites to be hosted on the University WordPress installation. Digital communications does support staff in creating their own individual WordPress website via the training course ‘Building your own personal website’ which any staff member can book onto via PDMS.
3.4.2 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 and access their site if they no longer have a University computer account. These site will be archived and an export of the site offered so it may be moved elsewhere when that staff member leaves the University.
3.5 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.
3.5.1 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.
3.5.2 Conference site
When conference sites are created, the site owner must 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.
3.5.2 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, e.g. 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 (see section 3.6). If this is not an acceptable solution for any specific project website, digital communications will work with site administrators to find a solution.
3.5.4 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 sport club sites to allow central oversight.
3.5.5 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 (firstname.lastname@example.org) must be given access using this email address to provide central oversight of all student society sites.
3.5.6 General sites
All other sites will be archived if not updated within 12 months of the last site update.
3.6 Archiving sites
Archiving a site means that it will no longer to 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:
- 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.
- 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 publically 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 it is longer updated.
- 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.
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 adminisatrators of a WordPress site must be using 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.
Providing the site has a demonstrable collaboration between different institutions, other types of users—that is subscribers, contributor, 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 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). Therefore, password protected pages must not be created. If content needs to be restricted to certain audiences it must be published via 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/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@example.com with the request. Standard platforms such as YouTube, Vimeo 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 to part of core University business it must comply with the University house style.
- It may be permissible to bring content from an external source such as a database or RSS feed into a WordPress site providing that the content complies with privacy and copyright regulations. The WP Engine firewall firewall may need to be configured to allow third party applications or services - email firstname.lastname@example.org with the request.
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.
6.1 Core WordPress
6.1.1 Security/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 then 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.
6.1.2 Functional updates
This type of update adds 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.
At this point, we have a small number of standalone WordPress sites. We aim to move all standalone WordPress sites into the central multisite, as detailed in section 11. 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 site(s) against the new version of WordPress.
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:
- 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 site(s) 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.
- A record of plugins and their versions will be updated accordingly.
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.
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:
- 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 site(s) 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.
- A record of themes and their versions will be updated accordingly.
6.4 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. Files larger than this must be uploaded via SFTP.
6.5 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 to a maximum of 512MB.
7.1 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 6 months. A permanent redirect of a site to an external site will not be permitted.
7.2 From external site to WP site
See section 3.3.1 (externally registered URL).
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.
9. 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.
10.1 General support
All requests for help should be sent to email@example.com. The support call will be directed to the appropriate team who will reply within the terms of IT Services SLA (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, a support call may be raised to seek help.
There are is provision for basic training for using WordPress. If assistance is required, a support call must be raised by emailing firstname.lastname@example.org.
WordPress sites are backed up by WP Engine on a daily basis at around 1.30 pm. 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 and 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.
11. Transition between current and future state
WordPress sites are currently hosted on the University network in a number of locations. For example:
- WordPress multisite (wp.st-andrews.ac.uk);
- Arts computing server;
- Secondary accounts (www.st-andrews.ac.uk/~account_name).
The future state will see all WordPress sites 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@example.com.
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 the minimum of delay in moving sites to WP Engine.
11.1 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. It is anticipated the migration will take place in March 2018.
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.
11.2 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.
11.3 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 install. Current sites will be migrated on a per case basis, with preference to having sites hosted in a multi site after the migration of wp.st-andrews.ac.uk.
It is anticipated the migration of sites from secondary accounts will be completed by December 2018.