• Getting Started
  • Writing for UQ Drupal
  • Configuring site title
  • Site Editor Training
  • Planning your website
  • Administrator view
  • Alert boxes
  • Content Writing
  • Building a homepage
  • Writing for the Web
  • Site Coordinator Training
  • Banners
  • User types
  • Legacy system support section
  • Accessibility
  • Blocks
  • UQ School Template Training
  • Logging in
  • Administration
  • Brand Colours
  • Views
  • Design & Build
  • Images for the web
  • Buttons
  • Display Suite
  • UQ Base theme: Style Guide
  • Equal height elements
  • Search Engine Optimisation
  • Image Styles
  • For Developers
  • DS Inception
  • Forms
  • Drupal Glossary
  • Creating a sandbox
  • Icons
  • How to create banners
  • Training
  • List with lead
  • Google Analytics
  • UQ School Theme: Style Guide
  • Panels
  • UQ Base Regions
  • Utility classes
  • UQ Base theme
  • Quicktabs
  • Webforms
  • Tables
  • Toggle
  • Typography
  • UQ News RSS feeds
  • Block grid
  • Demo form
  • Date and Time
  • Grid
  • Menus
  • Name space standards
  • Theme settings
  • URL patterns
  • Central data
  • Maintenance mode
  • Site search
  • Developer Virtual Machine
  • Developer Contribution Workflow
  • UQ Base theme updates
  • Modules available for use in UQ Drupal
  • Migration Classes
  • DS Inception V3
  • Automated Tests
  • Developer Contribution Workflow

    UQ Drupal CMS

    Preamble and Intended Audience

    The UQ Drupal CMS is a customised build of Drupal, providing an standardised enterprise platform for web content management throughout The University of Queensland.

    The intended audience for this document is any developer of a web site for any organisational unit, research group, individual or other entity at UQ.  It is important for all developers to understand the current stage of development of the environment and any processes, policies, and restrictions in place.  If you have any questions or comments please direct them to the CMS Project manager at:


    Please also read the UQ policy that states which Organisational Unit’s (if they have a web presence) must comply with both a requirement to use the CMS and to use the standard themes. 

    The UQ CMS currently is only able to host sites that use standard UQ themes.

    Deployment Overview

    The CMS draws from multiple repositories, covering theming, sites, profiles, feature sets and modules, all of which are brought together through a build system to facilitate a controlled deployment process. UQ Drupal database imports are not permitted as an appropriate method of content deployment. 

    Code Deployment process

    There are four code deployment environments within the CMS, three of which are on UQ infrastructure:

    1. Dev – the location for development work, using the developer VM which can be found here: 
      • https://drupal.uq.edu.au/guide/developer-virtual-machine This area is not for content creation
    2. Test – the location for functional and QA testing.  Sites in this environment may include features that are not yet ready for deployment to a production environment.  This environment requires the UQ VPN for access. This area is not for content creation.
      • This environment uses the test branch for deployment
    3. Stage – Conceptually a mirror of the production environment and the location of user acceptance testing, integration, and performance testing.  There should not be any additional site building behaviour in this environment, other than content creation.  This environment requires the UQ VPN for access.
      • This environment uses the master branch for deployment.
    4. Production – the live site presented to the public.
      • This environment uses tags on the master branch for deployment.

    UQ Drupal CMS code deployment uses a build process to facilitate building each environment with the appropriate setup of repositories allowing all the websites to run on a single codebase.

    These repositories are stored in the ITS Gitlab, access to which is requested by emailing uqdrupal@uq.edu.au.

    Test and Stage

    To enable each environment to be updated as desired each repository uses the following process:

    1. Fork the repository where the changes are required, in the ITS Gitlab.
    2. Create a branch within that fork.
    3. Commit work changes to the branch.
    4. Push committed changes back to the ITS Gitlab.
    5. Create a merge request on the original repository -
      • to test (for demonstrating features which have not been fully signed off by the user/client), or
      • to master (for features which have been fully signed off on by the user/client and , whether for the stage or production environments).
    6. The merge request is then put through automated tests (with success or failure being indicated on the merge request), and will be checked by one of the repository owners before it is approved.  An outline of the tests including relevant code standards can be found here:


    Merge requests must pass all tests before being accepted into master.

    1. Once the code is accepted the UQ CMS team approves the merge request and an automated process will deploy changes to the relevant infrastructure.


    In order to deploy code changes to the production infrastructure a request should be logged with ITS via email to:


    indicating a desire to pull these changes to production, along with a description of the changes themselves.

    The UQ CMS team will then create a tag on the master branch and the changes will be scheduled for a production push

    Each change requires a new email request and UQ CMS team tag.

    Contributed Modules

    The UQ CMS has a restricted ability to host additional modules on a per site basis. ITS must be notified of the modules intended to be used prior to any site development. This must be done via email to:


    If the module is accepted for deployment in the UQ CMS, acceptance notification will be by email. Please be aware that requests are moderated and your request for a module or feature may be declined.

    The modules available to developers using the UQ CMS are defined here:


    If you would like to suggest a generally useful module for inclusion in the UQ CMS environment please email uqdrupal@uq.edu.au outlining the rationale for its inclusion.

    Content Deployment Process

    There are two environments for content deployment within the CMS:

    1. Stage – anything that is part of the process of being developed, for example, a new section to a website or a new content type.
    2. Production – content is public.

    Aside from normal workflow behaviour that occurs on the production environment, sometimes new content types or sections of the website need to be developed.

    When this occurs, a copy of the production website will be moved by request to the staging infrastructure, where development of that content or structure can begin.

    From this point onwards content should be added to, or edited on, both the staging and production versions of the site.  Any content not replicated on production will be overwritten when the updated stage version is moved to production.


    As an alternative to editing both stage and production, a request to “freeze” a production site can be made by emailing uqdrupal@uq.edu.au

    As the deployment process involves migrating content from the staging site to the live production environment it is recommended that test or dummy content is not used.

    UQ Drupal database imports are not permitted as an appropriate method of content deployment. If content is not created on staging as detailed above content should be migrated through the use of migrate classes. 

    Standard UQ Drupal CMS migration classes will be provided to simplify this process, and a more detailed documentation on how to perform these tasks is available soon at



    If you have any questions about this process please contact the UQ CMS team at:


    Previous (Developer Virtual Machine)Next (UQ Base theme updates)