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:

Features

*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. 
https://www.drupal.org/developing/best-practice
http://www.wunderkraut.com/tags/code-driven-development

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

Redundancy

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.

Storage

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:

                  uqdrupal@uq.edu.au

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: 
    • http://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.

Production

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

                  uqdrupal@uq.edu.au

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:

uqdrupal@uq.edu.au.

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:

                  http://drupal.uq.edu.au/guide/modules

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

http://drupal.uq.edu.au/guide/migration-classes

 

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

                  uqdrupal@uq.edu.au

Developer Virtual Machine

To facilitate being able to develop on the UQ Drupal CMS, a Virtual Machine (VM) has been developed that provides access on machines to the infrastructure, code base and standard behaviour of UQ CMS provisioned installations.

Please note that sites created in the VM will not be migrated onto the UQ Drupal hosting infrastructure.

Requirements

In order to be able to use the developer virtual machine, the following programs are required to be installed on the system:

  • vagrant (v1.7.2+)
  • virtualbox (v4.3.12+)  Download the latest stable 4.3.x build and not the 5.x series.
    • For windows machines with latest security updates, 4.3.34+ is required.

For Windows machines, it is suggested the following programs be installed:

For those needing to interact with repositories from http://git.its.uq.edu.au, a developer SSH key needs to be installed on your system -- the instructions are the same as those for github.com.

Installation

To install the virtual machine, and make it available for use, create an initial directory using either the terminal (Mac), or Git Bash (Windows) -- this will be called VIRTUAL_MACHINE_DIRECTORY in the documentation below.

Within this directory, execute the following commands:

$ vagrant init uq/uq-drupal-devbox https://boxes.devops.its.uq.edu.au/catalog/uq/uq-drupal-devbox

Set the IP address for the VM:

  • Open the Vagrantfile in a text editor.
  • Search for: config.vm.network "private_network"
  • Uncomment this line and set the IP whatever you are using for your VM. Default: 192.168.254.44
    config.vm.network "private_network", ip: "192.168.254.44"

Start the virtual machine:

$ vagrant up

There are some first time setup errors that occur when doing a vagrant up:

  1. chown: cannot access ‘/data/apps/sites/*/files/’: No such file or directory.
  2. Invalid argument supplied for foreach() backend.inc:713 [warning].

This will download and setup the vagrant box for you.

It will be necessary to add to your hosts file (/etc/hosts on linux machines and C:\Windows\system32\drivers\etc\hosts on window machines) the following lines:

192.168.254.44 phpmyadmin.dev.local
192.168.254.44 webgrind.dev.local
192.168.254.44 auth.dev.local

These domains are then accessible via any browser from your machine, and any sites created within the VM will need equivalent entries in the hosts file.

192.168.254.44 example.dev.local
192.168.254.44 example.uq.edu.au

In order to have access to repositories using SSH keys, it is necessary to copy the SSH keys (e.g. id_rsa and id_rsa.pub) generated under the requirements section to the VIRTUAL_MACHINE_DIRECTORY, and then run the following commands:

  • Locate the ssh files on your local machine. You should have an id_* and an id_*.pub file.
  • Copy the files to the root folder of your VIRTUAL_MACHINE_DIRECTORY.
  • Access the VM with the below command:
    $ vagrant ssh
  • Copy the ssh files from your local machine to the VM with the below command:
    $ cp /vagrant/id* ~/.ssh

For Windows machines, SSH key permissions must be secured to allow access to repositories:

$ chmod 600 ~/.ssh/id_rsa
$ chmod 644 ~/.ssh/id_rsa.pub

To be able to utilize git commands within the VM, the following commands need to be executed:

$ vagrant ssh
$ git config --global user.email "youremail@uq.edu.au"
$ git config --global user.name "Your Name"

Virtual Machine Usage

Turn on the VM

$ vagrant up

Turn off the VM

It is essential that the virtual machine be turned off before shutdown of the computer -- this is to ensure any changes to the filesystem or database are correctly saved.

$ vagrant halt

Update the VM

When the virtual machine gives a notice that it is out of date (when running vagrant up), it needs to be updated to the latest version. It is recommended that an archive be performed before regenerating the VM, so it can keep the sites created and being used.

$ vagrant ssh
$ usershell.sh
   Select archive, and follow the prompts.
$ exit
$ vagrant destroy --force
$ vagrant box update
$ vagrant up
$ vagrant ssh
$ usershell.sh

    Select Restore, and follow the prompts.

Warning: The archive and restore process only includes files that have been uploaded to Drupal sites on the developer virtual machine that are stored on the local file system.  Files stored in the local riak storage container are not included.  See Structure | File Storage on your Drupal site for more information about storage containers.

Update the CMS Codebase

$ vagrant ssh
$ usershell.sh
 Select "Update CMS Code"

Create a site

$ vagrant ssh
$ usershell.sh
 Select Add Site, and follow the prompts.

Sites created in this way, are accessible to login via the user/login menu path with the following credentials:

Username: root
Password: root

To execute drush commands on the newly created site, you can run from anywhere in the VM, the following example command:

drush @example.com/blah pm-enable coder

Connecting to the Virtual Machine (Samba)

Access to the code is available through a Samba connection, which is vital to be disconnected before the virtual machine is shutdown.

For Mac OSX:

  • Open Finder.
  • Select Go -> Connect To Server
  • Server address — smb://192.168.254.44/data
  • Connect with Guest Account.

For Windows:

First enable the windows Guest account:

  • Open Control Panel > User Accounts > User Accounts
  • Click Manage User Accounts
  • Go to the Advanced tab and click the 'Advanced' button
  • Click on the Users folder in the left column
  • Right-click on the Guest account and select Properties
  • Untick the 'Account is disabled' option. Click OK.

 

  • Click the Start button and select This PC.
  • Click Computer | Map network drive on the top toolbar
  • Enter the folder name as "\\192.168.254.44\data"
  • Click Finish to connect as Guest.

PHPStorm on Samba

On a Mac OS machine using PHPStorm through the Samba, a few minor settings need to be adjusted:

  1. Disable the Git plugin for the project.
    PHPStorm corrupts the git index, so disabling the git plugin stops this from happening. Instead use the command line to perform the git actions.
  2. Turn off safe writes.
    PHPStorm corrupts some files during saves, as the samba share does not keep up with how quickly PHPStorm performs the "safe" actions. The unsafe actions still successfully safely saves files correctly.

Accessing the databases (PHPMyAdmin)

Access to the databases can either be through the command line using:

$ vagrant ssh
$ mysql -u root
Enter password: root

Or through a browser at http://phpmyadmin.dev.local/.

Username: root
Password: root

Profiling a page (Webgrind)

For those wishing to profile code, xdebug provides a profiler which can be triggered to start by adding to the query string: XDEBUG_PROFILE=1, or by using the Chrome XDebug addon.

Access to the profiled pages is located at http://webgrind.dev.local/.

Debugging with the Virtual Machine (XDebug)

The virtual machine contains xdebug configured for PHPStorm.

Browser based debugging

It is recommended to install an xdebug extension for your browser, to facilitate debugging pages, although it is possible to trigger it on a page by adding XDEBUG_SESSION_START=1 to the query string of the address.

Command line debugging

For debugging drush commands, or behaviours, the following commands must be executed before running drush:

$ export XDEBUG_CONFIG="idekey=PHPSTORM remote_host=192.168.254.1"
$ export PHP_IDE_CONFIG="serverName=_"
$ export DRUPAL_SITE_CONFIG="/data/apps/uq-drupal/drushrc/includes/settings.php"

These are all necessary environment variables to have xdebug correctly notify PHPStorm, with the DRUPAL_SITE_CONFIG allowing the appropriate loading of the sites installed on the VM.

To turn drush debugging off again:

$ unset XDEBUG_CONFIG

For debugging the drupal test runner:

  1. Ensure /data/apps/uq-drupal/drupal/scripts/run-tests.sh is copied to /data/apps/uq-drupal/drupal/scripts/run-tests.php.
    PHPStorm doesn’t seem to correctly allow debugging with the run-tests.sh.

     

  2. From the /data/apps/uq-drupal/drupal directory, run the following command:
    sudo -u nginx -g www XDEBUG_CONFIG="idekey=PHPSTORM remote_host=192.168.254.1" PHP_IDE_CONFIG="serverName=_" DRUPAL_SITE_CONFIG=/data/apps/uq-drupal/drushrc/includes/settings.php php scripts/run-tests.php --url http://example.dev.local {TEST TARGET HERE}.

Alternative IDEs

The IDE key can be changed by modifying /opt/rh/php54/root/etc/php.d/xdebug.ini.

Once modified the php-fpm process must be restarted:

$ sudo service php54-php-fpm restart

Modifying this key will need to be done every time the virtual machine is updated.

Virtual Machine Internals

Code locations

  • /data/apps/uq-drupal-standard/drupal
    The location of the core drupal files for the CMS standard distribution.
  • /data/apps/uq-drupal-legacy/drupal
    The location of the core drupal files for the CMS legacy distribution.
  • /data/apps/sites
    The location of the sites that are generated by the usershell.sh script.
  • /data/apps/phpmyadmin
    The location of the PHPMyAdmin application code base.
  • /data/apps/webgrind
    The location of the Webgrind application code base.
  • /data/xprofile
    The location of the XDEBUG profiler generated files.

Configuration locations

  • /etc/nginx/conf.d
    The configuration directory for sites. Examples of sites with a base_path are located within the default.conf file.
  • /opt/rh/php54/root/etc/php.d
    The configuration directory for PHP. These are the values normally associated with php.ini.
  • /opt/rh/php54/root/etc/php-fpm.d
    The configuration directory for PHP-FPM. These are values associated with the server that executes PHP.
  • /etc/my.cnf.d
    The configuration directory for MySQL galera.

Log locations

  • /var/log
    The primary log location.
  • /var/log/nginx/drupal.log
    The syslog information for correctly setup drupal sites using the syslog module.
  • /var/log/puppet/puppet.log
    The syslog information for incorrectly setup drupal sites using the syslog module. This also contains all syslog entries that haven’t been assigned to a different syslog channel.

Service commands

  • service php54-php-fpm restart
    This restarts the PHP-FPM service, this is required whenever changing any of the php.ini settings.
  • service nginx restart
    This restarts the nginx service, this is required if making changes to the web server hosts.
  • service mysql restart
    This restarts the mysql service, this is required when making changes to the database configuration.
  • service redis restart
    This restarts the redis service, this is required when making changes to the caching of drupal cache tables, or session handling.
  • service riak restart
    This restarts the riak service, this is required when making changes to the shared file handling for drupal.

Frequently Asked Questions

How do I configure putty to use my developer virtual machine ssh key?

Run Puttygen.

Select Conversions | Import key and load the private key from where your vagrant virtual machine is stored.  

e.g. {VIRTUAL_MACHINE_DIRECTORY}/.vagrant/machines/default/virtualbox/private_key

Click Save private key to save your private key to the same directory in .ppk format.

e.g. {VIRTUAL_MACHINE_DIRECTORY}/.vagrant/machines/default/virtualbox/private_key.ppk

In putty, create a new session to your developer virtual machine.

Under Connection | SSH | Auth browse to the .ppk file you created above as your private key file for authentication.

Why am I being prompted for a password for git@git.its.uq.edu.au?

Have you copied your SSH key files to ~/.ssh (and set them to the correct permissions for Windows machines)?

If you have recently updated your developer virtual machine, this step must be done again.

See Installation for further details.  

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.

Enabling

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.

Disabling

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

Modules

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.

Features

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

Deprecated:

  • 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

    9/2/2015

    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.

    Banners

    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


    Toggles

    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.


    Tables

    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


    Buttons

    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.