We are excited to have developers building on the UQ Drupal platform. As we progress, we hope to make this easier for you and invite your feedback and questions. 

To get started, please read the following information:


*Please note any configuration that can be exported to a feature, should be exported to a feature. 
A feature is a Drupal module that provides a collection of Drupal entities which taken together satisfy a certain use case. The list of available features components will change depending on what modules are enabled on a site and which modules have features support. This may be such components as Content Types, Roles, Taxonomies and Views. 

How is UQ Drupal Different from Drupal 7?

UQ Drupal has many custom enhancements that differ from a traditional Drupal install at every layer, from the back-end infrastructure architecture to the way content is displayed. A UQ-Drupal site comes preconfigured with a UQ theme, integrations with UQ-wide Single Sign On and much more.

The platform is patched and maintained centrally, so there is no need to perform updates on sites developed using UQ-Drupal and hosted on the central ITS service.

Software stack

  • NGINX - PHP via PHP-FPM - Drupal 7
  • MySQL/Galera 
  • Riak
  • Apache SOLR
  • AllegroGraph (triplestore)

These technologies may be replaced in a local development instance, e,g:

  • Replace Galera with vanilla MySQL
  • Use the Filesystem module under Storage API instead of Riak
  • There's a test IDP for SAML or EAIT KVD
  • UQ Drupal Dev team runs functional devel sites in 256M of RAM in our zone

Code best Practices

The UQ Web Development group have adopted Drupal development best practices  and a “Code Driven Development” approach to support the long term maintainability, reusability and sustainability of features. 

These principles are the basis for the short review process or based on the customised UQ experience of the development team. 


UQ Drupal Dev team runs multiple physical boxes that may all run completely independently of each other if the need arises. Database and assets are replicated in a multi-master arrangement.


File storage occurs via Storage API using a custom module to provide RIAK container support. The choice of technology here (RIAK) is irrelevant, but all content storage and retrieval needs to happen through Storage API. This means selection of third party modules is made with this consideration in mind. The UQ Drupal Dev team provides a custom file browsing module (fork of KCFinder) that integrates with Storage API. They also provide a custom image/file picker that integrates with Field UI and filefield sources.

Theme, Profile & Feature

Sites that exist within UQ branding must use the provided UQ Standard theme and be based on the provided UQ Minimal install profile. Base permissions & roles are provided by the UQ core feature, and may not be altered. Custom roles may be created when necessary, however.  

3rd party modules

You may use any of the modules available from the centrally provided pool. Additional 3rd party modules will be considered on a request-by-request basis, but arbitrary modules may not be added to a UQ-Drupal site. This is to guarantee stability, security & performance of the platform.

Central data

A custom module has been developed which allows for installation and maintenance of common content types and taxonomies. These content types & taxonomies are maintained centrally, and updates to them will automatically propagate to consuming sites. They should always be used rather than creating localised structures where possible. Content created using centralised data structures may also be shared amongst other UQ-Drupal sites. 

Drupal Sandbox

Start playing with UQ Drupal now by generating a sandbox site. Sandbox sites are available to anyone with a UQ staff login.

Create a sandbox site

Discussion list

Join the active discussion mailing list for developers currently using or planning on using Drupal. Topics cover everything from discussing module choices, posting module code for review, to theming and templates discussion. Access can be requested via https://lists.eait.uq.edu.au/mailman/listinfo/uq-drupal-discuss.

Feedback and suggestions

If you run into any problems or have a feature request, please or submit a ticket to >help@its.uq.edu.au

If you would like to share your questions or help answer some, please post in the forum

Legacy system support section
Drupal Template: 
UQ Base Template

In this section

Central data
Drupal Template: 
UQ Base Template

To make the most of our data; improving quality and reducing duplication, UQ is moving towards a central data model for things like news, events, study programs, people, research publications. This is built on centrally defined and managed content types in Drupal which draw on data from the many systems UQ has like LDAP, UQ Researchers, eSpace, UQ News, SI-net, etc

Central data is stored in a triplestore and can be consumed by UQ Drupal sites. At appropriate levels, data can be pushed back into the triplestore to update and add to it.

This is work in progress which will be expanded on over time.

Using central data

Central content types and taxonomies can be installed through the Central Things Manager module. This requires Site Coordinator or Administrator access to use.

  1. Go to Central Things Manager
  2. Click on the Install Things tab
  3. Select the content types and taxonomies you intend to use on the site
  4. Click the Install Things button and wait for the process to complete. NOTE: If you refresh or click the button again before it finishes the process may fail.

Content types

Centrally managed content types come with a consistent set of fields and a default display so these types of content can be used across UQ's webspace.

Taxonomy vocabularies

  • UQ Organisations - automatically updated vocabulary of UQ org units fed from the central authorative source via ODS.
  • UQ News Topics
Developer Contribution Workflow
Drupal Template: 
UQ Base Template

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:


Maintenance mode

Maintenance mode allows a site to be available on a public url but requires users to login in order to see the site. This way it cannot be accessed by unauthorised parties or indexed by search engines until it is taken out of Maintenance mode.

Enabling/disabling this function is restricted to Administrator and Super Administrator roles.

All user roles can use the site while in maintenance mode.


To enable maintenance mode for your website:

  1. Go to Configuration > Maintenance mode.
  2. Select the Put site into maintenance mode check box.
  3. Edit the Maintenance mode message that Drupal Gardens displays to site visitors while your website is offline.
  4. Click Save configuration.

Your website displays the maintenance mode message for all site visitors, including anonymous site visitors and search engines.


To allow all site visitors access to your website, clear the Put site into maintenance mode check box on the Maintenance mode page, and then click Save configuration.

Modules available for use in UQ Drupal

Last updated: 22 April 2015


In order to maximize maintainability for the large number of UQ sites, we are providing a set of modules that cover the majority of use cases. These modules are listed below.

For sites where required functionality is not possible with the defined set of modules, there is the possibility of adding other modules to either the generally available set of UQ enterprise wide modules, or restricted to the specific site on which it is to be used.


For every site that deviates from the use standard features available globally, developers must create Drupal features for all of the custom content types, roles, permission sets, and other Drupal structures.

Our ongoing maintenance requires a Feature Revert on all sites. In the case of Feature Revert on all features of breaking a site, developers will be required to be fix any issues beforea site is accepted into our system.

The standard method for creating a feature, is to put data structures as well as visual layouts that should not change into the feature, with defaults for settings, variables and others into the hook_install() into the feature itself. This will allow at least the base to be built, and defaults put in place, but allow site builders to customize without halting deployment processes, both for themselves and for us.

Requesting Modules or Features

These may be requested from uqdrupal@uq.edu.au.

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 to begin a discussion with the CMS team.

The CMS team will check the functionality already exits, or is in planning.

Before a module can be added, the proposed functionality will be checked for suitablilty to the wider UQ audience, security and accessiblilty issues. The module must be maintained and at a stable release (no alpha versions).


List of Modules

Modules required for all UQ Sites:

  • simplesamlphp_auth - this is a customized version.
  • storage, storage_wrappers and storage_riak - For clustered file handling.
  • uq_date_formats
  • robotstxt

Newly Added Modules April 2015

  • fieldable_panels_panes
  • uuid
  • paragraphs
  • chosen
  • geolocation
  • ip_geoloc
  • diff

Generally available modules:

  • cck_select_other
  • chosen
  • ckeditor
  • context
  • context_entity_field
  • crumbs
  • ctools
  • date, date_api, date_popup
  • email
  • entity
  • entityreference
  • features
  • features_extra
  • field_formatter_class
  • field_formatter_settings
  • field_group
  • field_hidden
  • field_permissions
  • google_analytics
  • image_focus
  • jquery_update
  • libraries
  • link
  • menu_attributes
  • menu_block
  • metatag
  • migrate
  • migrate_extras
  • module_filter
  • panels
  • panels_everywhere
  • paragraphs
  • pathauto
  • pathologic
  • publish_button
  • publishcontent
  • quicktabs
  • r4032login
  • readonlymode
  • realname
  • redirect
  • rules
  • simple_dialog
  • simplified_menu_admin
  • strongarm
  • term_reference_tree
  • token
  • views
  • views_accordion
  • Workbench
  • Workbench Access
  • Workbench Moderation
  • wysiwyg
  • wysiwyg_filter

Modules currently under review:

  • block_classes
  • image_facedetect
  • select2
  • serviceview
  • webform_access_csv
  • webform_storage
  • webform_userfields
  • webform
  • webform_layout
  • webform_report
  • webform_term_opts
  • entityform
  • entity2text
  • recaptcha
  • captcha
  • honeypot
  • uqsubcontent
  • google_cse
  • gss
  • search_api_elasticsearch
  • uq_image_caption_formatter
  • fitvids
  • smart_trim
  • disable_messages
  • ajax_links_api
  • date_ical
  • content_access
  • linkit
  • lightbox2
  • colorbox
  • flexslider
  • flexslider_views_slideshow
  • views_slideshow
  • slick
  • feeds
  • views_embed_field
  • mimemail
  • mailsystem
  • search_autocomplete
  • facetapi
  • facetapi_bonus
  • facetapi_pretty_paths
  • flag
  • session_api


  • uq_feeds_block
  • uqckeditor_settings
  • central_things
  • ds_inception
  • espace
  • facetapi_ui
  • filefield_sources_filething
  • filefield_sources_filething_remote
  • filething
  • ldap_mapping
  • quicktabs_zurb_foundation
  • select2
  • staff_directory
  • staticuri
  • uq_base_field_groups
  • uq_field_collection_block_grid
  • uq_help
  • uq_taxonomy
  • uqredirect
  • uqthings
  • uqthings_gmap
  • nice_menus
  • search_api_solr
  • addressfield
  • menutree
  • insert
  • om_maximenu
  • taxonomy_display
  • term_reference_filter_by_views
  • taxonomy_manager
  • menu_css_names
  • menu-editor
  • disable_term_node_listings
  • tvi
  • profileplus
  • taxonomy_csv
  • restws
  • apc
  • cer
  • domain
  • domain_access
  • domain_blocks
  • domain_views
  • easyrdf
  • edit_profile
  • field_collection
  • field_collection_tabs
  • filefield_sources
  • kcfinder
  • ldap
  • physical
  • rdfx
  • remote_stream_wrapper
  • sparql
  • timefield
  • views_php


This list is subject to occaisonal  updates, please review regularly. 







    Site search

    Site search is provided via the Google Search Appliance (GSA), located at uq.edu.au/search. The search field on sites passes the search paramater to the GSA and results are displayed on uq.edu.au/search.

    Adding the search field

    Newly created sites will have the search field enabled by default. For older sites:

    Go to Structure > Blocks and add the UQ Google Search block to the Search region.

    Adding sites to the index

    Any site on the uq.edu.au domain is automatically included in the GSA index. That includes alias sites like uq.edu.au/about, and subdomain sites like its.uq.edu.au.

    Non-UQ domain sites must be added manually to the index. These should be submitted via the ITS Helpdesk itsupportdesk@its.uq.edu.au

    It usually takes 24 hours for new sites and new content to show up in the index.

    What is indexed?

    All public web pages, readable documents like .doc and .pdf, and images will be indexed.

    Web pages and documents requireing authentication to access are not indexed. This includes content within intranets.

    My site doesn't list first in the search results

    The GSA uses Google's algorithms so content is ranked based on relevance of content. If your page doesn't rank first then you either need to improve the content on that page or find it via different keywords.

    We do not apply bias to the results.

    UQ Base theme updates
    Drupal Template: 
    UQ Base Template

    Fixes, tweaks and enhancements


    The UQ Base theme has been needing some love for a while now. Some bugs have been around for a while needing to be squashed, and some new ones have been introduced over time with changes in other parts of the Drupal platform. We've also move on with our thinking of what we want the theme to do. This patch is also as much a refactoring of our code for easier maintence as it is bug fixing.

    These changes shouldn't require any config changes on your behalf. If you have custom styling on your site then you may notice some conflicts so please test anything you've customised. We can't support any customisations you or a third party might have made.


    They now display better on mobile. The caption also should no longer sit at the bottom of the page for the Tall Banner.

    You should still only have 1 banner view on a page though, as they multiples will interfere with each other.

    List with Lead

    Lots of fixes were required here due to changes in other components that adversely affected them. They now all display neatly and the .outline and .reversed styles are available again. Add these classes to the Wrapper Classes field under Custom View Options.

    Applying style classes to list with lead view


    Small style changes here to bring the default and .basic styles inline. Mostly this was code reformatting with little visual or functional change on the front-end.


    Paragraphs were displaying at a different size to plain text within table cells. This was difficult for users to control without editing the source code as pasted content generally wrapped in <p> tags. Font sizes are now consistent, yay!

    Vertical menu

    The old accordion style side menu has always been a bit chunky and overbearing against the content of the page. We've introduced a new style using the .vertical-menu class to replace the .accordion-menu. The change over process is manual though as we are not removing the accordion-menu styles just yet.

    The vertical-menu also comes with a .vertical-menu.vertical-menu--shaded variant.

    Vertical menu example vertical menu shaded example

    Webforms (to be deprecated late 2015)

    The Webform module doesn't give much (any) control over design of a form. Styles on fields are intended to be wrapped in layout divs using the Foundation grid, but that just isn't possible through Webforms. We've included a Webform specific set of styles to address this in order to solve some of the more pressing issues like drop down fields that span full width and make date selectors look awful. You can also display labels inline now. The prefix and suffix fields also display inline now and don't just look like additional labels.

    Labels are now the default bold again, and you can set the width of fields as you please. This might mean you will need to put more effort into aligning forms with inline labels, but at least the control to do so is there.

    Webform with inline labels

    The Webform module is a bit of a thorn for us though; it doesn't do as much as we'd like, as well as being misused. The Checkbox system is still the best option for building forms that don't require direct integration with a Drupal site. Webform's future in UQ Drupal is being reviewed.

    Menu and search

    For desktop users, top level menu items with children now have an indicator arrow. The active item gradient is gone with just a flat colour in its place.

    On mobile the search field was missing its icon and wrapped to 2 lines. This is fixed.

    Fixed mobile search display

    The mobile menu is better but not perfect. Child items are now indented to show the heirarchy clearly, and the active item is not open all the time so its a bit less cluttered.

    The issue where clicking a menu item that has children only opens and closes the children but prevents you going to that page persists. It requires a complete overhaul of the menu to resolve which we haven't had time for.

    Unpublished page notice

    Previously if you were a site editor and went to an unpublished page you couldn't tell from looking at it that it was unpublished. Unauthenticated users of course wouldn't see it at all. Editors now get a very clear, very red, (Not published) notice at the top of the page.

    Example of unpublished notice on page

    Header and footer

    The obvious change is the gradient is gone. We're moving towards a flat, modern feel and not to mention the gradient wasn't actually the correct brand purple. Otherwise the header hasn't changed but displays a bit better on mobile.

    The footer needed some code refactoring, which happily resulted in a better mobile view. We're sporting the correct Go8 logo now which I'm sure they are pleased with, and the UQ Answers button is now a text link for accessibility purposes. Yay WCAG.

    Text overlapping images

    On some pages, text was overlapping the image on the right hand side. This was due to floated images inside a floated container coming from different settings. This has been fixed so text won't overlap, multiple images will stack neatly, and on mobile images will switch to full width rather than taking only 50% of the page.

    Text overlapping images before and after fix


    They're now flat. Just bringing them inline with the header/footer/menu flattening, but the still function the same and look like buttons.

    Print view

    Previously if you printed a page you couldn't tell where linked text actually linked to. Links like 'Download the form' became completely useless. We now print the link url after the link text.

    urls printed after the link text

    Automated Tests

    Automated testing is applied on every merge request, to ensure the quality of code, and reliability of the functionality of the system.

    While not currently not yet implemented, the testing processes that will be taking place are:

    • coder style checking
    • simpletest
    • phpunit

    These tests can run for an extended period of time -- with our target to be within 30 minutes of initial merge request.

    Merge requests that fail any one of these tests will be sent back to the developer to fix.