Opening

Salsa Digital was recently selected to work with Acquia on one of the firstpublic govCMS projects, a platform migration from a proprietary CMS to the govCMS platform for the Civil Aviation Safety Authority (CASA).

For those not aware, govCMS is a brand new offering from the Federal Department of Finance and Acquia for providing website Content Management as a service to all Government Departments.

Following up from my first govCMS build blog, and the first govCMS build outside of the govCMS team, this article aims to provide a bit of insight into the service and how it works.

Starting off with a bit about what govCMS is and the benefits of govCMS, the article then moves into the structure of a govCMS site and how departmental users will interact with it. We then move on to some planning considerations for vendors, take a brief look under the hood to see how it all fits together and finally a little bit on security.

Much of this article explains the basic out of the box functionality of a govCMS site, however the real power in govCMS is in its extensibility; it can be modified to meet the needs of most departments and future versions will be even more flexible.

What is govCMS?

Before ‘the what’ comes ‘the why’. The Federal Department of Finance (DoF) noticed the similarities between the many requests for finance for departmental websites; although the requirements were similar, each department chose separate vendors using different platforms and hosting infrastructure. This meant the Government was not leveraging the size and quantity of its digital assets to realize the savings that were available at scale.

The solution was a tender process to select a single vendor to supply Federal Government websites. Acquia won the tender, hosting all govCMS sites on their Platform as a Service (PaaS) system, utilising the Drupal Content Management System (CMS). Acquia worked with the DoF to create a new Drupal distribution called govCMS, based on the aGov project. The govCMS Drupal distribution combined with Acquia PaaS hosting has created the govCMS Software as a Service (Saas) program.

By utilising a single system, govCMS aims to simplify Government ICT and eliminate duplicated activities across agencies. The single platform and build process will also help to create a standard and consistent Government website theme, increasing the usability of Government as a whole through good UX and familiarity for users as they visit different Government websites.

Drupal is becoming a standard for many large organisations and governments across the world, including sites such as data.gov.uk and whitehouse.gov making it a logical choice for the Australian Government. Drupal is an open source CMS, its selection also supports the Federal Government Open Source Software Policy; the full govCMS distribution is also open source and is available on both the Drupal website and on GitHub. govCMS is hosted on the Acquia Cloud Site Factory Platform, reflecting the Government’s commitment to open source and the use of shared, cloud-based services.

Unfortunately the govCMS website still has a watch this space under case studies, however you can read a brief blog about Salsa’s first govCMS build here.

Benefits of govCMS?

Reduced Costs

One of the major benefits of govCMS is the reduction in cost from business as usual. This falls into a number of areas such as hosting costs, security management and maintenance, software patching and maintenance, testing and development.

Currently almost every department has separate website hosting and build costs, for some departments many of their internal web assets are built, developed, designed and charged separately. govCMS simplifies that cost into a single provider and hosting platform on the Acquia Cloud Site Factory PaaS Service. As resource usage increases the platform as a whole can be upgraded to the benefit of all govCMS sites. This also simplifies the procurement process, the govCMS service is operated and provided by the Department of Finance so there is no need for a lengthy and expensive tender process; all of the boxes have already been ticked and approved, so a new Department can just get on with building their site.

Government Standards Compliance

Complying with Federal Government security standards can be an onerous process; each department engaging a software vendor to create a custom implementation for compliance with the standard is an extremely time consuming and costly process. govCMS has completed the Information Security Registered Assessors Program process to ensure compliance with all Government security standards. This compliance automatically flows through to every govCMS site. A major advantage

is that when a security flaw is discovered it is patched in govCMS where every govCMS website immediately receives the benefit. This means no scoping, no change request exercises, no individual builds per vendor. The govCMS team constantly monitors the security landscape to ensure the security of all sites. Further support is provided by the Drupal open source community, govCMS benefits from from the work of Drupal teams in governments and organisations across the world who report the issues they have found and the remediation for them.

Software maintenance

Software maintenance, bug fixing and patching is already performed at a global level ensuring immediate benefits to the entire govCMS network. Acquia has a large team of over 600 of the best and brightest in the Drupal community to ensure the govCMS product remains efficient, performant and stable. The Acquia board are made up of a number of the core drupal committers, including Dries Buytaert - CTO and Co-founder and the original creator of Drupal. This expertise, combined with the govCMS team at the Department of Finance ensures the govCMS product is always of the highest quality. All of this patching is provided within the standard annual fee of the govCMS platform, significantly reducing the total cost of any Government web project. The Acquia team also provide 24 by 7 support of the govCMS platform at the application and hardware level.

Security Compliance

Following any software security update, bug fix or functional change regression testing is required to ensure their are no issues with the site following the changes. Once again govCMS takes care of this process through automated testing across the network of sites using Behat. Behat is an open source behavior-driven development framework allowing users to write human-readable sentences that describe a feature of your application and how it should work. Behat then provides automated testing of all of the defined features providing faster testing whilst ensuring code quality and maintaining stability.

Responsive - tablet and mobile ready

Usage statistics for mobile phones are showing a steady move from desktop to mobile phone. It is imperative that websites have a great user experience not just on desktop but also on Mobile and Tablet Devices. One of the many useful features of Drupal is the Theme system which allows for base themes to provide the basic template user interface, which can then be used by sub-themes, where developers only need to override certain sections to create a customised look and feel, whilst retaining the advanced functionality of the base theme.

The base themes that come with the govCMS distribution are Responsive by default and provide the tools a development team require to quickly produce custom themes based on these standard templates. These standard base themes also create a standard look and feel, which can assist in creating a familiar interface for the Australian public when they view Government websites, thereby providing a more user friendly experience when dealing with the whole of government. You can read more on the govCMS theme development process here.

Accessibility Compliance - WCAG AA 2.0

Another consideration for all Government websites in compliance with Web Content Accessibility Guidelines (WCAG) AA 2.0 standards. These standards assist in ensuring a website is user friendly for users with web accessibility issues and users using accessible web browsers. The base themes in govCMS are built with full WCAG AA 2.0 compliance in mind. govCMS also provides all of the tools a user needs to be able to comply with the standard. Much of the standard is concerned with content related issues, items such as alt and title tags on images. govCMS provides the tools to add these accessible elements either via fields on content pages, or via the What You See Is What You Get (WYSIWYG) editor.

Data Retention

Finally govCMS also provides compliance with the National Archives of Australia standards, including 7 years retention on backups. There are numerous benefits to govCMS, but I think this is enough to give you an idea, time to get into more detail!

govCMS Implementation Types

The long term goal for govCMS is to have a single central platform for all Government websites, providing all services using a common user experience. The govCMS platform already is quite flexible, however it’s good to remember that it’s still a beta product. The platform allows for three different types of projects, Type 1 - fully compliant with govCMS, Type 2 - mostly compliant with govCMS with some customisation required, and Type 3 - a completely bespoke build with govCMS providing the framework.

Type 1 - Fully compliant Out of the Box

Type 1 sites can be built with the options provided in govCMS Out Of The Box (OOTB). The majority of Government sites fit within the Type 1 mould, meaning a fairly basic build process for the vendor and the Department.

Type 2 - Mostly compliant

Type 2 sites comply mostly with the OOTB govCMS platform, however they require some custom development work in order to achieve all of the requirements. When a Type 2 site is requested by a department, the govCMS team, including the DoF and Acquia, will analyse the requirements to see if a more generic implementation can be created so that the customisation can then be made available to other govCMS platform customers.

For example, a department requires integration with a new Email Marketing software service. The govCMS team will investigate the requirement to see exactly what may be required by other departments and build a generic module providing the configuration options for any department to easily setup the service integration on their own site through the User Interface (UI). This module can then be added to the core govCMS platform for use by all customers. For the next department requiring integration with this service, this feature will now be a part of a Type 1 build. The continuous improvement process will further reduce costs to departments who purchase govCMS later, as well as existing govCMS clients who may have wanted the extra feature but didn’t want to spend the extra money during their initial build.

All new customisations that go into Type 2 for inclusion into the govCMS base installation will be first approved by the govCMS team. The design and build of these customisations may be built by an external vendor, however the design will be a collaborative effort with the vendor, Acquia and the DoF.

Type 3 - Bespoke Functionality

Type 3 is a completely bespoke build which does not fit the govCMS platform and would require too much customisation to be useful to other departments in the network. In this case, govCMS can still be used as a base, however a development team will then add customised code in order to meet the organisation's requirements. Type 3 builds cannot be hosted within the govCMS Acquia Cloud Site Factory environment and will be provisioned and hosted separately within the broader Acquia network. There is a new service about to be publically annouced taht will enable these Type 3 sites to sit within the govCMS network, keep you eyes on the govCMS website for more details.

govCMS Site Structure

The following content types are enabled by default and they come with accompanying views and view blocks for a standard content display.

Basic OOTB IA

Blog Articles are a fairly straightforward blog content type. The view resides at /news-media/blog, making the blog a subsection to News and Media within the default Information Architecture (IA). A Latest Blogs block is also provided on the homepage in the default theme to provide direct access to the latest information on the site to site visitors.

govCMS Event

On Events, cost and contact fields are included, however these aren’t linked to a registration or payment process. I was somewhat surprised to find the Location field is using a standard long text field rather than something more specific. Neither the Address field nor Location modules were installed by default, which limited the available options. During the development of the clientwebsite, we arranged for the addition of the Address field module in order to meet some requirements of the project. govCMS is still in beta, so now that the module is in place it will be interesting to see if the Location field is updated to a fully functional address field, potentially even providing google maps integration. Events are similarly housed within the News and Media section of the site.

GovCMS Media Release

Media Releases provide an image, date of publication and a file field to allow the user to download the full media release document. Out of the box govCMS is using the drupal default file widget, which I thought was a little odd given the Media module is installed and used for all image fields. Although the user still has access to upload the new Media Release document, they don’t have access to the File Entity repository to allow selection of a document that has already been uploaded. This also means the user experience isn’t consistent within the system as a whole. Obviously this is simple to change in the UI if required and one I would image many govCMS sites will make.

There’s nothing special about the News Article content type, it is generic enough to be everything that most Departments will need. The addition of the tags field will allow the view to include filtering if required, however this isn’t enabled by default. The main page of the News and Media section is blank by default, however it does reference Bean blocks for News and Media, Events, Media Releases and Blog. These Bean blocks need to be created before they will fill the page.

govCMS Promotions

The Promotions content type is a handy idea. It provides a small footer teaser on the homepage that provides a brief description and image related to content that content producers would like to highlight, for example an old Media Release that has fallen off the front page of the Media Release view.

govCMS Publications

PPublications are a standard requirement for many Government Departments in order to provide detailed information back to the general public. The structure is essentially the same as a Media Release with the addition of a Tags field.

govCMS Slider Ordering

The Slide content type provides a slider on the home page. Draggable Views is put to good use here to provide a simple User Interface (UI) for editing the order of the slides in the slideshow. The slideshow view is a simple HTML list with a pager and not an automated slideshow; I’m assuming this is for accessibility reasons. It is possible to have accessible sliders, so this is another area where I’m interested to see if this features gets added in later version of govCMS. TheViews slideshow module isn’t installed, so it would need to be a theme implementation unless one of the less popular slider modules is selected.

govCMS Slider

The Standard page is a reimagining of the Basic Page from a normal Drupal installation. The addition of a document and an image field provide a little more flexibility than the Title and What You See Is What You Get (WYSIWYG) editor body field of the standard Drupal Basic Page.

Everyone who uses Drupal knows the Webform module. The OOTB functionality of the module is provided here; the only addition being the Webform Clear module. Webform Clear automatically deletes webform data as soon as it’s been emailed. Not storing user data is a fairly standard requirement on many Federal Government websites and was a good addition to govCMS.

govCMS for Department Users

For users and site builders who are used to Drupal, you’re not going to notice too much, except maybe the administration menu, which is a good replica of the Drupal 8 menu. For me, personally, I’m a big fan of drop down menus, I find the single layer menu system is a bit slow and clunky. However I do understand that for many users the plethora of configuration options that are on display with the drop down menu can be a little daunting.

There are 4 OOTB roles in govCMS: Content Editor, Content Approver, Site Editor and Site Builder. These roles can all be modified on each site build, however the OOTB permissions are pretty sensible.

1. Content Editor

The Content Editor role is the basic role used by general staff creating content on the website. This role has no access to configuration and only the ability to create content. This role cannot publish content to the Live site and only has the ability to create content in the Draft state, then set it to the Needs Review state for approval. The role does have the ability to create and edit blocks within the site, allowing them to skip the workflow process for any block sections within the site. There are no block sections that are immediately available to Content Editors; the Content Editors are also restricted from using the Contextual Menuslinks, giving them no links within the UI to edit, so their ability to edit relies on them knowing the exact url to a block in order to edit it. Creating new blocks is available on the My Workbench page, however the role has no access to manage the block locations and is therefore unable to place the blocks within the site, making the ability to work around the workflow more theoretical rather than practical.

2. Content Approver

The Content Approver is a similar role with no access to configuration. The purpose of the Content Approver role is to review content created by the Content Editors and publish it to the live site. Content Approvers aren’t restricted from creating content, so this can be used as a more general utility role for users who are approved to directly publish live content to the site without approval. The content workflow remains the same, all content can only be created as either Draft or Needs Review and still requires a user to move the content to the Published state. Neither the editor or approver roles can edit Menu items which I see as a bit of an issue, however given the issues around workflow it doesn’t really surprise and it does highlight a bit of an issue around revisioning and workflow for menu items (new module anyone?). That said, Content Approvers do have the permission to publish content, so restricting them from the menu does seem a little odd.

3. Site Editor

The Site Editor role is the most powerful role that Department users will have access to. It provides a high degree of autonomy to each Department, whilst ensuring users don’t have enough access to be really dangerous. Site Editors have the ability to manage blocks and menus, which is the key role to give the Department full control over its website. Site Builders can also manage the Contact forms on the site, of which there is only one OOTB.

govCMS Panels Link

The real power (and danger) is in the ability of Site Editors to manage Panels. The home page and news and media pages rely on panels, a Site Editor can simply click on the Customize this page link at the bottom of these pages and move content items around the page using the Panels simple drag and drop interface.

govCMS Panel Drag and Drop

Similarly the Change layout link provides the Site Editor the ability to change the layout of the page from govCMS, the default layout to one, two or three columns layout with the click of a button.

Site Editors have the ability to manage Taxonomies within the site to assist in Categorising content. There is no ability to manage Content Types, meaning that adding new vocabularies is not entirely useful, however managing terms within the taxonomies created during the site build can be a useful activity.

The Site Editor has the ability to manage the appearance of the site by managing Theme settings. The changes that can be made are quite minor such as changes to the favicons, adding or removing items such as menus, site name or logo, however these can be handy ways for a Department to take control of parts of the look and feel of their site without involving developers.

Site Editors have access to the People menu item, allowing full control over adding, editing and deleting users from the system. The Role Delegation module is used to allow Site Editors to create users with any Role up to Site Builder, which I think is a bit of an error. If a user can create an account with a high level of access than their own, then they effectively have the same access as that higher role. Given the focus on security for govCMS, I’m sure this one will be picked up and fixed quite quickly.

4. Site Builder

The Site Builder role is the highest level of access outside of the govCMS team. This role is usually reserved for the development team. You can read more about this role a little further down in the Developer access section below.

Drupal Reports

Site Editors and Site Builders also have access to some of the Drupal reports, including broken links, event log, google analytics, user actions and view plugins. The important ones here are the Broken Links, Google and User reports. A module named Linkchecker runs once a month by default to analyse all of the content on the site and check for any broken links to other web pages. The report allows users to see what links are broken and go directly to the edit page and fix them.

govCMS Link Checker

The event log can be quite useful when the site is experiencing errors. Although most errors reported here aren’t going to be of much use to the Site Editor as they’ll have little ability to fix them. They will provide them with better information to pass on to a developer to give them a head start on diagnosing and fixing issues quickly.

govCMS User Actions Report

The user actions report lists actions taken by users on the site. This can be very useful for a Site Editor when trying to track down why a content related issue has occurred. It will allow them to narrow down who may have caused the issue, hopefully allowing them to find a resolution in less time.

The Workbench and Workbench Moderation modules are included by default with a standard OOTB implementation. This is a necessity in most Government Departments, where highly sensitive information can be published, requiring a workflow process that can ensure all content is properly reviewed prior to release to the general public. The implementation in govCMS includes the three OOTB states:

govCMS Workbench

1. Draft for newly created documents;
2. Needs review indicating the content needs review by more senior staff. This state is usually the highest level a content editor can set on a piece of content; and
3. Published, usually reserved for Content approvers within the department.

This process allows for a larger number of content producers to create new content on the site, whilst providing the approval workflow required to ensure the quality and accuracy of the final content.

Workbenchprovides some handy admin screens to simplify this process. There is aWorkbenchmenu item within the main admin menu. The landing page provides a list of content that the current user has created or contributed to. The Create content tab provides access to a menu where the user can select the type of content they wish to create.

govCMS My Drafts

Two views are also provided. The My Drafts view shows all of the content that is in the Draft status, where the current user is the owner of the current revision of the node. This is a quick access view for the current user to see what pages they are working on, make any further edits and, or process them through to the Needs Review status. By restricting the to only Draft documents for the current user, it ensures the view isn’t overloaded on content heavy sites.

govCMS Needs Review

The Needs Review view provides the same details and function for the Needs Review Status. The main difference being the view is not restricted to the current user. This allows Content Approvers to view all nodes that are currently in the Needs Review status and move them through the process to the Published status; or alternatively move them back to Draft for further work.

Planning an govCMS site build

The main thing to get used to for developers is that you have no access to module code, only the theme, so template hooks are as good as it gets. This leads to a second issue, configuration management. In a standard Drupal build many developers use the Features modules to manage configuration between environments. In govCMS it’s all UI, so you better have a good think about your documentation.

The module list is pretty robust, so most requirements can be met with the available modules. During our recent migration of a government clientwebsite from it’s old CMS to govCMS we found a few holes in the required functionality. Luckily for us govCMS is still in it’s beta phase, and between the Acquia and DoF govCMS teams we were able to add in a few useful modules such as Address Field and Feeds Tamper; I’ll go though a few of the modules a little later.

A little issue to remember is that govCMS is using ClamAV, so it’ll save you a hassle when you’re trying to quickly test file uploads if you install and configure it on your local or vagrant or what ever tool you use for local development.

Data migration becomes the other issue when working with govCMS. WIthout the migrate module or the ability to write custom migrations, the available options within the ACSF environment are quite limited.

In order to maintain security the Paranoia module is included, which blocks running any PHP within the UI. So while exporting Views and Feeds configuration is possible, there’s no ability to import. Luckily there’s a way around these restrictions, in the form of a very helpful team at Acquia.

Developer Access

Something that can be hard to get used to in govCMS is the Site Builder role being the highest level role provided outside of the govCMS team; any external vendors such as Salsa Digital (and most likely you if you’re reading this) will be provided with this role for their developers. This is essentially the admin role within govCMS. On top of the Site Editor role the Site Builder has access to manage Block types (BEANS), Content Types, Crumbs and Display Suite as well as configuration for Image Styles.

For all of the developers out there you’ll see some notable omissions from the permissions you would normally have access to, the Modules page being the most obvious. There is also no access to the permissions or roles pages, so there is no access to increase your roles abilities.

Performance management is also restricted, this one is for good reason. The govCMS Acquia Cloud Site Factory environment is tuned very specifically to run govCMS and the govCMS team need complete control over performance settings. Logging and errors is also restricted, I imaging this is also to ensure performance and maintenance of control within the govCMS team. If you’re like me, not having this level of control may well be an issue; being with govCMS is all about finding your inner zen as a developer, and letting go, Ommmmm govShanti.

With all of the restrictions, it does seem a little odd that all developers on the site must be Acquia Certified; building in govCMS is essentially a Site Builder task. Given that the govCMS project is in it’s beta phase there is still a role for developers in identifying issues, developing ways around the them, suggesting and developing patches or the suggesting the addition of extra modules.

The other reason to have developers on the job, is that although the ACSF environment is so restrictive, during the client project build, Salsa performed most of it’s work in a standard Acquia professional site, providing full access to code, the database, everything, ahh, I can feel Nirvana coming to me. Performing a full site migration from a questionable data structure into Drupal with only Feeds Tamper is just not practical which the govCMS team clearly understand.

Migration

We installed theMigratemodule and Salsa created the custom migration classes we needed to get the data where we needed it. This separate environment allowed Salsa to conduct what was really a standard Drupal site migration, ensuring there were no real roadblocks to meeting the business requirements for the move.

Although we didn’t add any additional features, we did use our custom migration module to store ourFeedsandViewsconfig in code, simplifying the process of moving between environments.

For the remaining configuration, Content Types, Beans etc, we used Confluence. All govCMS projects will be run Agile, Acquia uses Jira as their project management tool of choice, with Confluence providing the knowledge repository.

All of the QA was conducted in the Acquia Professional environment, making it quick and easy to get through each Sprint and ensure the project ran smoothly. At the end of the project the site was Forklifted into the govCMS ACSF environment, including all of the QA’d data and configuration from the Acquia Professional environment. The entire process was managed seamlessly by the govCMS team, ensuring the migration process went smoothly. A minor point here, but I’m not quite sure it’s a forklift given the infrastructure, codebase and configuration is completely different in ACSF, it’s really just a db and file dump into the new environment, but that’s just splitting hairs over syntac I guess.

govCMS, Under the hood

Modules

Views is obviously top of the list on most Drupal sites and it’s put to good use in govCMS. The homepage, Publications and pages with the News and Media area are made up ofViews. As with almost every Drupal build I’ve done, the client website also required a number of views to build out the required functionality.

The Beans, Block Entities Aren’t Nodes, module provides the ability to create custom blocks that are Drupal entities, providing fieldable blocks to use where required. In my opinion, along with views this is one of the most handy modules in the list of drupal projects. Beans are used for a number of blocks around the site, they make up the majority of content on the News and Media landing page.

Panels and Display Suite are used to create the home and news and media pages. I tend to use Context more often, but to be honest it’s most out of habit than anything else. The combination ofViews,Beans,Display SuiteandPanelsis what allows govCMS to be so flexible with look and feel without using any custom modules and using a minimal amount of work in the custom theme.

govCMS Contact Us Form

The Drupal core Contact Form module is used for the main default Contact Us and Feedback form. I’ve never quite understood the need for this module when either Webforms of Entity forms are installed on a Drupal site. It seems to offer a very low functionality version of these forms with little flexibility. There’s nothing specifically wrong with it, it get’s the job done. But when you haveWebformsinstalled and enabled, I still think it’s an odd choice to use it.

TheFile Entitymodule is installed in many site these days because of the improvements it provides over Drupal core file management. With the large amount of documents theFile Entityis quite vital I think, the UI it provides for finding and working with FIles is just what Government Departments need. There are some outstanding issues around Private file security and theFile Entitymodule, however they’ve been patched and fixed in govCMS, obviously security is a major issue on the project.

govCMS Quicktabs

QuickTabs is a module i haven’t used before, I haven’t ever had need for the functionality, but it’s a neat little module. It provide a UI for users to add a tabbed block content as a block. The UI is very simple and easy to use and adds an extra level of flexibility for Site Editors without the need for engaging a developer.

Even though we had access to theMigrationmodule in the Acquia Professional environment, we still utilisedFeedsfor a couple of the smaller and easier CSV migrations.Feeds Tamperactually makes theFeedsmodule quite powerful and it can be a much quicker way to get an import going than migrations when the requirements are relatively simple.

Custom Modules

There are 14 govCMS Custom Modules, they are all quite small and provide some very necessary functionality, mainly covering the compliance requirements of Government website.

Extra permissions are created by the custom modules for the Appearance page in Drupal to provide more fine grained control, which which is not in standard Drupal, although the business case is not there in most sites. The sites are also set to Sydney time by default during installation.

The custom modules also include an example content module that allows a department to create a new govCMS installation including content to get a better idea of how the site will look once it’s complete. This includes a useful feature that blocks users from editing or creating content while it’s enabled. The user needs to disable the content, which will then automatically be removed, before they can begin using the site.

The base permissions, search, social links, menu blocks and the password policy and a few other settings are defined in custom modules rather than in features. I quite like this method as these are options that are likely to be altered during a new site build. Having settings like this in in Features that can’t be edited would make me a bit nervous, as someone could accidentally reset these settings by reverting a feature.

There is an option to display the Long text summary field by default, this is usually hidden and requires the user to click the Show link to show it. This is a good feature as the Meta tag description uses this summary text, so if it’s not filled in this meta tag will also be blank, which doesn’t quite comply with the Government meta tag standards.

One of the other useful items in the User Actions view which is defined in one of the custom modules. It provides a list of all of the actions taken by each user on the site. This includes creating and updating content, logging in, etc. This is a handy feature for tracking where a content issue was created to allow for it to be quickly and easily rectified.

Patches

As you’d expect the govCMS project is defined in a makefile and there are a number of good patches added to enable govCMS to do what is required. This isn’t a full list, but I’ve pulled out a few items that I think are key to govCMS.

https://www.drupal.org/node/1772316 allows govCMS to change the installation profile requirements. There are a few changes around resources such as xdebug max requests settings.

https://www.drupal.org/node/1470656 provides a check to ensure the same file isn’t passed over multiple times in the same request during a registry rebuild. The govCMS installation process runs over the registry rebuild a number of times, so this issue becomes a real problem during site installation without this patch.

https://www.drupal.org/node/111702 sets the from address to the site email rather than the users email address to comply with security settings from many ISPs that will block php sent email if they don’t come from the main email address. A Sender Policy Framework TXT record can also assist with this issue, but that sits outside of the control of the website code.

OOTBClam AVscans files on nodes, the https://www.drupal.org/node/1630604 patch ensure that all files such as User pictures etc are also scanned on upload, which is key to ensuring the security of the site.

https://www.drupal.org/node/1970362 ensures full compliance with Dublin core by including the "scheme", "lang" and "dir" attributes

https://www.drupal.org/node/2151013 adds the autocomplete attribute to the password field on the user login form to ensure compliance with all browser; some browsers do not support the attritube on the form itself.

A reasonably common issue that is seen with the redirects module is that horrible error message “Oops, looks like this request tried to create an infinite loop. We do not allow such things here. We are a professional website!”. The https://www.drupal.org/node/1796596 patch aims to avoid that issue by disabling incorrect redirects to ensure they aren’t available in the site in the first place.

When you have a good look through you can see that a lot of work has been put into the stability and security of the govCMS platform. I’ve taken a few lessons away for myself on some configuration and patches that I may start including on my non govCMS sites.

Security

The security setup is the main thing a developer is going to notice in govCMS, partially because it’s a bit of a pain to setup on your local. ClamAV is not something I have installed on my Vagrant boxes by default and I didn’t notice until I was trying to upload files that it’s a requirement of the platform. The ClamAV module provides integration with ClamAV to scan all files as they’re uploaded to the site. This provides an extra settings for allows file types.

The Paranoia module is another one that some developers may find annoying, personally I think it forces a number of protections that should be in place on most Drupal sites anyway. PHP should never be allowed through the UI in my opinion, there should always be a better way to solve issues in production. The only exceptions here areFeaturesand theViewsandFeedsimports. Drupal 8 is just around the corner which should help with these config issues, but in the mean time the options aren’t great outside of php in the UI.

The Login security module provides an extra level of security around tracking and managing logins and is an improvement from Drupal core. The configuration for this module isn’t available to anyone outside of the govCMS team as it’s blocked for the Site Builder role.

The User protect module adds in an extra layer of permissions around how a user can manage users on the site. The following checkboxes are provided which prevent editing of any of the following when checked, Username, E-mail address, Password, Status changes, Roles, Cancellation, OpenID identities (both adding and deleting) or All edits. These settings can be applied at the role level or even for individual users, which makes it quite flexible. LikeLogin security, this configuration isn’t available to Site Builders, which I think is a shame as it could be quite a handy tool for many site builds.

govCMS uses Honeypot instead of Catpcha, which is the superior option in my opinion. It isn’t going to be as good at blocking as Captcha or reCaptcha, but the user experience is much better and it does provide a good level of protection.

The Security Kit module provides access to a number of security hardening options through adding site headers such as Cross-site Scripting, Cross-site Request Forgery and Clickjacking. The Site Builder role doesn’t have access to the settings in this module either. I presume this would require consultation with the govCMS team if the bootstrap js and css files were to be included in a theme to ensure they aren’t blocked by Cross Site Scripting headers.

Session expiration is handled via config in the Session cookie lifetimemodule. This allows for per site control over this setting. Because govCMS is in a single codebase, this is better controlled in site configuration rather than attempting to control it through a series of lines in a common htaccess file.

The Shield module provides a UI for creating http authentication. This was used on the client site build for all of the sites in the Acquia Professional environment. This provides the basic security required to block general visitors to the sites while they’re under development. This also blocks crawling from spiders such as googlebot.

The Username Enumeration Prevention module is quite simple. It replaces the default message on the Forgot password form so that the message for a username that does exist is the same as for a username that doesn’t exist. By default Drupal has one message when the username entered into this form exists, informing the user that an email has been sent and a separate message stating that the user doesn’t exist if the name doesn’t exist. This ensure that hackers can’t continuously try names in the forgot password form (username enumeration) until they find a username that exists. This prevents the hacker from finding a username and then using that in a brute force attack to try and find a password.

Pros and Cons

So after all of that here are my basic list of pros and cons, let’s start with the cons

Cons

1. The menu system, for me this is a real hassle, having no ability to enable a dropdown menu system is a real pain while site building (secretly I enabled this on my local dev box);

2. dissecting govCMS2.png

   

   govCMS comes with a number of features, which makes sense in order to build out a basic site. Given there is no ability to change these features it gives me little dangerous moments as I think about how easy it would be for someone to accidentally revert features and destroy a site;

3. Site Editors can add Site Builder users, which is a flaw as the Site Editor can add a new user account for themselves with a role more powerful than their own. This is a fairly minor configuration change, however I think it should be updated in the default features.

Pros

1. There are a few too many to mention, head back up to the Benefits section :)

2. The Acquia team were a real pleasure to work with, they were quick to react to issues that we came across during our first project which allowed us to keep doing our job

3. It’s in the benefits but I think the increasing functionality provided by the Type 2 sites is a huge benefit. This has the potential to greatly reduce the cost for Whole of Government departments as only one department needs to pay for the functionality. As a taxpayer it makes me happy to think about the savings that can be realised.