This page is for questions relating to the Oxford Mosaic service. If you have queries about the toolkit and how to use it to manage your site and edit content, please see the Mosaic Help pages.
See FAQs based on where you are in the website's life-cycle:
Before beginning a website project on Mosaic
The Mosaic service doesn't make guarantees to host sites in perpetuity. However, there are no plans to limit the lifespan of sites on the platform and every effort will be made to host and support sites according to the Service Level Agreement, regardless of the pricing tier they fall under.
The Oxford Mosaic Web Platform is for anyone in the University who requires a website, including:
- Research Groups
- UAS departments
- GLAM units
- Individual academics, including research postgraduates. Undergraduates and taught postgraduates are not eligible.
- Student clubs and societies
- Cross-institutional partnerships
Mosaic is designed to provide a toolkit for publishing public-facing information; it is not managed as a repository suitable for storing Internal or Sensitive content.
On a per-site basis, functionality can be enabled to allow specific pages or files to have their access restricted only to users logged in using Oxford Single Sign-on credentials. This access restriction can be applied so that the content is restricted to all University members or all University staff - there is no further granularity to the access restriction. This feature is provided solely to enable customisation of the site navigation experience of users, to help ensure they see only content relevant to them; it is not to ‘secure’ content. Mosaic is warranted to only be used to store Public content.
Mosaic doesn't provide the granular permissions and security auditing tools used by Intranets. It can, however, be used to create engaging and user-friendly web sites containing public information, providing navigation and signposting to internal information stored in SharePoint, and to link to individual files and folders in a SharePoint repository.
There are different charging levels for the service dependent on page visits, disk space, and total number of pages. An overview of pricing is publicly available on our help pages, and a more detailed breakdown of the cost model is available to members of Oxford University.
We have a few sandbox sites which we can make available on a temporary basis (normally for 6 weeks); however, we would normally recommend that you just request a 'real' site and start building it! There are various ways to manage the release of your site and your content while it's 'under construction' (and for ongoing development); you can:
- make your site visible only to logged-in users
- prevent your site being indexed by search engines
- keep content in draft form until it's ready to publish (and unpublish it again if you change your mind)
- view and share a preview of a page before it's published
- publish content without assigning it a menu link (so it will be published but users can't navigate to it)
If you still feel that you need a test site, please contact us to discuss your requirements.
External design agencies
If you are interested in using an external agency, you can contact the Mosaic Platform team for information about agencies which have experience of designing on the platform.
Support for research groups
IT Services provides a technical consultancy service for research groups, which is dedicated to helping research groups find solutions for disseminating their work. The Research Support team is well versed in Mosaic's capabilities and research groups can contact them (firstname.lastname@example.org) for a consultation on using Mosaic for their web publishing requirements.
See 'Support for Researchers' in the information about Add-on services.
Requesting a Mosaic site
Mosaic sites are requested using the form accessed from the Site Request page.
You need to be a member of the University to request a website on the Oxford Mosaic platform. Requests for a new site should be submitted by the person who will be the Site Owner.
For all types of request - apart from requests which select the 'Student society or sports club' site type - the requestor's Card Status should be one of:
For student society or sports club requests, the requestor's Card Status can be one of:
We understand that governance for the web within University units may not require direct approval from the academic Head or the Head of Finance for the unit, but with Mosaic we are not able to adjust our site setup processes to be tailored to the specific governance arrangements of each unit, as they vary so widely across the University. We have no way of verifying if the approvers proposed are the correct people or not, so we simply require that the academic Head or Head of Finance of the unit are named as the authorisers of requests, as these two roles are common and senior in every department.
All this means is that the Head of Department or Head of Finance (or equivalent roles) should be named as the approver on the site request form. The person named on the form will receive an automated notification of the request once the form is submitted.
The named approver does not need to send the Mosaic team approval via email as approval is assumed to have been provided before the request is submitted; the email notification the named approver receives is just confirmation of the request being submitted from within their unit and is for their visibility.
If the Site Request contains the correct details, we can create the site space for your website quickly - usually within a week. (During holiday periods, the time may be a little longer.)
If we need to query with you the information you have submitted, the process will take longer. For this reason, we strongly suggest you discuss your request with colleagues first and ensure that you have approval from the appropriate authority, according to the web governance rules applying in your part of the University. It will minimise delays if you read the guidance notes on the Site Request form!
We typically create 10 - 20 new website spaces on Mosaic each month.
Building your site
Designing sites in Mosaic is a substantially different process to designing a custom site built on a framework or single-instance CMS. Mosaic has been designed to provide as much design flexibility as possible while ensuring the security and sustainability of both the platform and all the sites on it. The inbuilt theming options are now extensive and we do not anticipate custom CSS being often required. There is also no access to Drupal module or theme administration.
Mosaic provides a number of design features including font and colour configuration, page layout options and in-page widgets. None of these features require specialist technical knowledge to use, though a good understanding of information architecture best practice, as well as an eye for design are all preferable in order to deliver a professional and effective site.
Find out more about site appearance options in the documentation for Site Theme.
Custom CSS falls outside the scope of our support. This means we’re unable to help further with setup or troubleshooting. Additionally, with the use of custom CSS, we can’t guarantee its full compatibility with the styling of your Oxford Mosaic website and users should be aware of the difficulties involved in implementing such customisation successfully, including: incompatibility with Mosaic styles, incorrect rendering on mobile devices, accessibility issues for users with disabilities, and conflicts with future updates to the platform.
Although we aren't able to help further, if you are considering using custom CSS on your site, please bear in mind the following:
- first try to use the site's advanced colour and font management options to set element styles as far as is possible
- custom CSS should only augment the existing site theme (not to force a major override of the theme)
- custom CSS should be added to the source view of a WYSIWYG widget — placed in either: the site's footer (which appears on all pages, and therefore applies the custom styling across the site); or at the bottom of a page's content area (if the styling is intended to be page-specific). This allows for the custom code to be isolated, if necessary
- the Mosaic team continues to not provide support for custom CSS. If any display issues occur on sites using custom CSS in the way described above, comment out the custom CSS to debug the issues — if the display issues persist after commenting out the custom code, contact the Mosaic team
You can add HTML content into the 'Source' view of the text content area of the WYSIWYG widget or the Banner widget. See documentation about embedding third-party content in the WYSIWYG widget. We recommend using the Insert Image or File Icon and Upload from Web option to embed video content although alternatives are available.
Can I import content from an existing website into a Mosaic website? (e.g. from a WordPress, other Drupal, or other CMS site)
No, this is not possible.
There are many different types of websites and systems, and content structures within those sites and systems, which makes it very difficult to provide a content import tool that will work for all of them. With over 300 sites in Mosaic, it's not possible for us to tailor an import tool for each site. Mosaic also uses a version of Drupal that is very customised for use in the University's context, so even providing mappings of content from existing Drupal sites is not straightforward to achieve. Also, importing existing content is not the panacea it may at first appear: even the best import tools map content incorrectly or miss off a significant percentage of content. As well as being costly, in time and funds, to develop the import tool, there is a significant overhead for content editors to quality assess migrated content afterwards. In short, it rarely saves time and is difficult to do well.
In any event, migrating a website to a new system is a golden opportunity to review site content and navigation structures. Content may be out-of-date, redundant, and (typically) too long, with poor menus and link structures. Instead of migrating sites over 'As Is', auditing your content and navigation structures can help to save time in the migration process as well as improve quality of your new site.
There are 3 options for sourcing images for your site:
- Use free picture libraries
- Pay to use images in commercial image banks
- Take your own photos/make your own images, or contract a photographer/designer to produce your own images
Guidance is available on our Source images for your website page.
The Simple feedback form widget is available to all sites by default, and can be added like any other widget.
Webforms on Mosaic use Google reCAPTCHA for spam protection. If a reCAPTCHA is not set up on your site, Simple Feedback form widgets will not be rendered. A reCAPTCHA must be set up by the Site Owner/a Site Administrator. Further details are provided on the reCAPTCHA setup documentation.
More advanced webform functionality is available on request.
It is possible to use a content subtype dedicated to blog content and create a page template for blog articles. This will allow multiple users on your site to create and publish blog articles from a template, which will maintain a consistent look and feel.
If you want to moderate blog authors' work before it is published, you can make sure their accounts use the Site Contributor user role. This will allow them to create content but not allow them to publish it. Instead, a user with a wider range of permissions will need to move the article to a published state.
By adding a listing widget (e.g. Grid listing or List listing widget) to a page on your site and setting it to filter for articles created using your blog content subtype, the articles will be automatically displayed in the listing once they are published.
Mosaic does not include commenting functionality for article content. However, it is possible to use third-party commenting services which support iframe embedding to put a comments section in a WYSIWYG widget.
Unfortunately at the moment we don't have the resources to offer bespoke or one-to-one training sessions; however, we run a free termly drop-in workshop where you can talk to members of the Mosaic team in person about any content editing queries you have. For more information, including how to book, see our training pages.
Preparing to launch your site
A go-live checklist to help you prepare for launching your site is available on the Mosaic Go Live documentation page.
See documentation about setting up custom domains on Mosaic sites.
If an end user requests a domain using 'https' when the domain is not on an SSL Security Certificate, the user's browser will display a security alert. In the example below, the domain 'oxfordmosaic.web.ox.ac.uk' is not on an SSL Certificate so visiting the URL 'https://oxfordmosaic.web.ox.ac.uk/' caused the user's browser to display a security alert. Read the article about https on our Latest section.
If you notice this alert when using your custom domain, the domain is not yet on the Mosaic platform's SSL Certificate. The platform's SSL Certificate is updated to add new domains every two weeks. If you haven't already requested your domain to be added to the certificate, contact the Platform team to ask for it to be added.
You can create a Google Analytics account to provide data about how visitors engage with your Mosaic site and its resources. You can find more information on the documentation about Google Analytics | Oxford Mosaic.
For ongoing Google Analytics support, you can:
Ongoing site management
Logged-in editing vs. viewing pages as a website visitor
Viewing a site as a logged-in editor will be slower than viewing a site as non-logged-in visitor. This is because logged-in editing directly accesses the server resources for the website; when viewing sites as a non-logged-in visitor, pages are requested from the server cache, which provides quick access to recently visited pages.
If your editing screens appear to be substantially slow to load, there are several factors that could contribute to this.
Some editing activities require more processing memory than others and can temporarily reduce the amount of available memory for other editing tasks. If editing is happening elsewhere on the site at the same time (either by you editing in additional open browser tabs or by another user), this is likely to impact performance across the site.
Large amounts of statically-generated content
The amount of statically generated content on the page has a noticeable impact on the loading speed of the edit screen: static content includes Banner widgets; Grids, Lists, Carousels, and Slideshows set to use the 'Static' content source; and images in Image Galleries. Unlike widgets set to 'filtered' and 'selected' content sources (which use references to other pages on the site), 'static' content requires all of the text and image content for each static item to be rendered on the edit screen. This is can be relatively resource-intensive.
Rendering large images in a page's edit screen can be resource-instensive. Multiple large images in use on a page can therefore have an impact on the loading of the edit screen.
Local network performance
Slow loading of screens may be due to slow performance of your local network. To test this: try visiting your site as a non-logged-in user to compare with expected non-logged-in performance; or, if you use a portable device, try comparing performance when working in a different location.
Note that ethernet cable network connections are generally faster than WiFi connections.
The web browser that is being used
Mosaic is supported for use on modern browsers and we recommend ensuring that you're using an up to date version of your browser.
Number and type of tasks running in the browser
If a browser is running a large number of tasks or several resource-intensive tasks while you are working on your site, this may impact editing performance.
There is only one Site Owner per site. To transfer site ownership, use the change request form linked to from either: the Site Settings > Site Theme tab; or from the site's /user (Login) page.
There is only one Site Owner per site. This person takes ongoing overall responsibility for the site and is the primary contact person for it. They may be contacted by the Oxford Mosaic or Information Security teams on any important matters affecting the Mosaic service. The Site Owner must be a member of the University and a member of the site's Owning Unit. See the Service Level Agreement for details of the responsibilities of website owners.
There are additional responsibilities for content on websites associated with the University. Read the University's Rules for Websites for more information.
See the SLA for details of the responsibilities of the Mosaic Platform team.
A Site Owner/Administrator can add a new user by going to the Site Settings > Users tab > 'Add' user screen.
The roles assigned to each user can also be adjusted in that screen, as well as the access for users who have left be removed.
To allow non-University members to be Content Editors on your site, check the ability to add non-SSO (external) users is enabled for your site (see Site Settings > Users tab).
Once the ability to add external users is enabled on a Mosaic Site, a Site Owner/Administrator can add a new external user by going to the Site Settings > Users tab > 'Add' user screen.
Check the site is visible to search engines
Ensure the site can be indexed by search engines using the visibility setting which controls the robots.txt file. See the Site Settings > Visibility tab > 'Hide site from search engines' documentation.
Is the site not appearing in results or is it very low in the search rankings?
To confirm whether the site is not appearing at all in the search results or whether it is appearing very low down the search rankings:
- copy a unique string of text from your site, and use it to perform a web search
- scroll through the results of the search (you may need to visit multiple pages of results) to verify whether the site is included in results or is low in the rankings
The site is not in the rankings
If the site is not in the search rankings at all, go to the Site Settings > Visibility tab to check whether it is visible to search engines.
If the site is not in the search rankings and it is set to be visible to search engines (Site Settings > Visibility tab), consider asking search engines to re-index the site (see the 'Search engine indexing' section below).
The site is low in the rankings
If the site is low in the search rankings, consider Search Engine Optimisation principles to help raise its profile (see the 'Search Engine Optimisation' section below).
Search engine indexing
Although search engines frequently crawl websites in order to index them, you can manually ask them to re-index your site. There is guidance on our Go Live checklist about how to ask Google to re-index your site. Other search engines offer a similar service.
Search Engine Optimisation
General Search Engine Optimisation (SEO) principles should be considered for any publicly-visible website and information about these is widely available on the internet. As managing SEO is primarily a content matter, it falls outside the remit of Mosaic support and is a responsibility of the website owner.
The Mosaic platform provides a non-technical interface to make technical operations - such as controlling the robots.txt file, adding descriptions into the <meta> tag, etc. - so that site owners and content editors can make the necessary changes to optimise search behaviour. See below for some basic principles which we recommend considering.
Ensure your site is cross-linked with relevant external content
Ensure there are links to your site from relevant pages on high profile sites, e.g. if you manage a research group website, ensure there are relevant links to your site from your parent department's website.
Provide page descriptions
Each page in Mosaic has a 'Description' field (in page editing mode, towards the bottom of the 'Details' screen). The 'Description' field is intended for a brief summary of the page's content. The text in this field is written into the <meta> tag of the page's source code - i.e. the description text only appears in the page's HTML markup, not on the rendered page.
The page description may be used by search engines to display a snippet about the page in search results. It might be helpful to the rankings to add descriptions for at least the most prominent pages on your site.
Prevent splitting search rankings
Mosaic websites which use custom domains will have 2 or 3 active domains in operation (the '[prefix].web.ox.ac.uk' address + up to 2 custom domains). Prevent splitting search rankings between multiple domains by making sure any links from other sites to your site use URLs containing the main, public-facing domain. If some in-bound links use the [prefix].web.ox.ac.uk or non-primary custom domain instead, this will dilute the amount of links using the primary domain and reduce its relevance in the search rankings.
Mosaic does not provide a web archiving service. However, content versioning and Platform-level backups are included in the service.
Mosaic preserves the last 10 versions of a published page, and the last 10 versions of a draft (so this could be up to 20 historical versions in total for a given page). Content editors can view old versions and revert to them. The period of time covered by these versions depends on when the individual pieces were edited/saved/published, and it is not possible to use content versioning to 'roll back' a whole site or section of a site to a specific point in time.
These are intended to secure the platform against technical failure and maintain service continuity. Backups are taken regularly but these do not provide individual sites or users with the ability to restore to a specific arbitrary point in time, or to retrieve/restore specific pieces of content.
External archiving service
If you need to take backups to maintain a longer-term archive of your content over time, e.g. for reasons of legal compliance, we recommend contacting the Bodleian Libraries' Web Archive service (https://www.bodleian.ox.ac.uk/beam/webarchive), which you can email at email@example.com.
See our information about cached content and updating pages.
The Mosaic notifications are sent to everyone who has a user role on a Mosaic website. If you are no longer involved with a Mosaic website, please ask the website's Owner or one of its Site Administrators to remove your user account.
Once your user account is removed from the website, Mosaic notifications will no longer be sent to your email address.
Site Owners can request site deactivation by using the "Request deactivation of site" button available in Site Settings > Site Details. You can go direct to Site Details by using: [prefix].web.ox.ac.uk/admin/config/oxdrupal/site-settings.
Further details about the process are provided in the site deactivation documentation.
For further information, please refer to the site deactivation and reactivation process.
Charging and billing
An overview is provided on our pricing pages.
For more detailed information, please see our cost model.
You can view figures for your site's usage and current charging tier by visiting Site Settings > Site details. There is a button next to Billing information for View your current usage and tier level.
You can find an explanation about the site usage report in the site details documentation.
Usage levels are reviewed each year. Fees are charged annually in advance, based on the level of site usage in the previous financial year, adjusted for any change in the charge tier when usage has moved up or down to a new charging tier in the final quarter of the year (1 May to 31 July).
The last opportunity to adjust usage in order to manage future charges is 30 April.
The financial year begins on 1 August.
A site’s status, in terms of whether it is live or not, does not have a bearing on its charging liability.
Action on reaching first charging tier
At the next billing point after the site becomes chargeable, the Site Owner is asked to provide a cost centre and the finance contact email address of the person who will approve charges for the site.
General ledger vs project codes
A general ledger code is preferred.
If a project code is supplied, the code will be re-used each year the site remains chargeable. A general ledger code would have to be provided when the project ends.
We do not provide internal invoices.
External units, such as colleges, will be invoiced.
A Site Owner will be sent an email alert when a site's usage has exceeded its current charging tier. The warning explains the site will be liable for additional charges if the level of usage is not adjusted. The email includes links to view your current usage and tier level and the cost model.
If the change of usage is intentional, no action will be required. The charging tier will be adjusted at the next billing point on 1 August.
If the change was not intentional, you have until 30 April to make adjustments to your site's usage.
We accept requests for development work. Before deciding to build new functionality, we evaluate it against its wider benefit to the platform and whether the requirement can be satisfied through another, already supported method.
It's also worth noting that all the sites on Mosaic share the same codebase, so any functionality developed for one site will be available to sites across the platform.
We accept requests for new features. Before deciding whether to add the requested feature to the team's backlog of work, new feature requests are logged on a list of potential enhancements. This list is reviewed by the platform team once a month and evaluated it against its wider benefit to the platform.
If you are making a request for a new feature or some custom development work (see above) and you've found a Drupal module which you think will meet some or all of your requirements, then please do pass this information on with your request! However please also bear in mind the following:
- All the sites on Mosaic share the same codebase, so there's no way to install a module on your site without it affecting the whole platform
- Mosaic is already a heavily customised instance of Drupal, and every new module added increases our maintenance overheads (installing security updates/patches, testing for interactions and incompatibilities with other modules and updates)
As with all requests for new functionality, we would evaluate it against its wider benefit to the platform and whether the requirement can be satisfied through another, already supported method.