Department of Agriculture & Food WA

Multi-category - Taxonomy & Menus

The new website's primary goal was to be easy to navigate and search. Drupal's core Taxonomy system was a staple for meeting this requirement, allowing a multi level hierarchy, content to be associated with multiple relevant terms, and to be used in Search Filters as well as landing pages. The websites main vocabulary "Topic" covers the main subject area's of DAFWA, and you'll recognise this in the topical areas of the mega menu navigation. The menu also has a section of curated content and links under "Tools & Services" and "About us", which was separated from Taxonomy in the IA.

Landing pages - Search API

The topic landing pages were built using Search API (Solr) with Views and Facets API. This allowed users to filter down by other topics or search, without having to leave the landing page. See example landing pages: Wheat, Beef Cattle and Diseases. We used Search API over ApacheSolr due to the ability to easily create Facets search filters and its integration with Views.

Microsites - Organic Groups

We also needed the ability to have microsites for things like programs, projects, initiatives and partnerships. For this requirement we used the Organic Groups module so that each microsite could have its own custom managed menu, logo and custom sidebars. You can see an example of this on the MyCrop microsite.

Multipage content - Smart Pager

Some of the DAFWA content items (nodes) were potentially very length in the number of pages they contained, e.g. research papers or annual reports. To allow this sort of content to be easier to maintain we used the Smart Pager module so that all the pages of these papers and reports could reside in the one Drupal node. A custom module was also written to generate a table of contents automatically. You can see an example here: Crop Diseases: forcast and management.

Content Publishing Workflow - Workbench

The content publishing workflow needed to support the ability for all staff to create content, Project Managers to review content, and Corporate Communications to approve and publish content. Further more these roles were separated within the department by branch. These two requirements lent themselves to the Workbench Moderation and Workbench Access modules respectively. Some custom developed code was written to improve the usability of the workflow notices and forms, support for email and toolbar notifications and workflow checklists.

Theme & Layout - Zen, Panels, Panelizer, Display Suite

We used Zen as a base theme because of the flexible Zen Grids layout system, out of box responsive features and SCSS support. We also created the majority of our graphics in SVG format to support high DPI screens such as retina displays. On the Drupal side, we used Panels and Panelizer for controlling and customising the landing page and node layouts, and Display Suite for customising node view modes.

Personalisation - Homebox

A lot of work also went into the Dashboard that users can customise (like d.o) to display calendars, articles of interest or weather stations. This was built using a number of custom modules and the homebox module.

Third Party Integrations

A large part of the project also involved integrating with existing third party systems. Thanks to to the existing Drupal LDAP module, integrating with Active Directory was fairly straight forward. We had a lot of struggles trying to get Single Sign On working (being Linux to Windows) but achieved this after a lot of experimentation using the apache mod_kerberos extension.

DAFWA also uses the proprietary DMS solution - Objective. Documents can be created in Objective and once approved, can be flagged for use by the external website. Through the Objective Webtalk API we can capture these flagged documents and pull their meta data and data across for usage on the website.

Migration

A number of existing websites existed in DAFWA already. Most of the content of these had to be re-written but we were still able to write some Migrate module profiles to pull these across and mark them as drafts. The beauty of the Migrate module was that we could re-migrate these again and again whilst development was occurring.

Development workflow and tools

Drupal development work was exported to code using Features and Strongarm. A separate feature existed for each content type and included all components related to that content type such as views for listings, fields, panels and any custom code.

Like most development workflows these days, all developers and designers had their own LAMP or WAMP stack on their own machine. Each time a developer committed and pushed, the git post commit hook would trigger Jenkins to deploy changes to our central development environment where non-developers could review and test new features. Developers optionally worked on their own branch, but to have changes show up in the central development environment, the work had to be merged into "develop" following the well known branching model from nvie.com.