Many local authorities have flocked to the Drupal platform to build out their council website over the last ten years - around 72 active and mostly on Drupal 7 and 9. The issue comes from everybody doing it slightly differently as they worked with an agency and came up with their own brand and style.
The LocalGov Drupal project aims to change this by “being a publicly owned asset that delivers a better digital experience for citizens, improves service outcomes, and saves money”. This provides the basics for free, and allows a council to spend their money on the good stuff. It’s estimated that using LocalGov Drupal will reduce the cost of building a new council website by up to 80% (depending on the extras a council wishes to add) - this is probably more for the smaller councils with minimal basic content publishing requirements.
So how do you get access to the platform to test the LocalGov Drupal system, and what functionality is included for free as standard?
In this guide, we provide an overview of the LocalGov Drupal platform, including the set-up process, features and functionality and what’s missing that you need to add yourself.
Getting set-up
The codebase is available from GitHub and the easiest way to install it locally to trial it is through the command line which downloads the codebase ready to roll.
$ composer create-project localgovdrupal/localgov-project MY_COUNCIL_NAME
Spinning up a local development environment using Lando is supported as standard in the LocalGov Drupal repository, I used the alternative DDEV, which worked equally well because I already had it installed.
Set-up is completed through the web browser wizard by selecting the “LocalGov” installation profile when presented with the choices. Within minutes you’re greeted with an empty council website waiting for your first move.
What first?
Those new to the Drupal CMS may wish to familiarise themselves with the default user guide linked from the page - but the sheer amount of content there might be a little overwhelming!
The main purpose of a council website is to publish information for its citizens and reduce the amount of inbound email and phone calls by streamlining efficiencies through embracing an online self-service function to empower its users.
The typical site information architecture is structured into groups of service content that are delivered in a variety of styles.
The initial distribution install activates three basic definitions of content that can be assembled into a basic council site. There’s a selection of other types available by enabling the additional modules to extend the platform.
Service landing pages
Councils typically divide content into common topics around services such as reporting things, tax payments, parking, planning permission, recycling, councillors, and community news.
Each of these “service” groups are then broken down into many activities which are displayed as a title and summary which link off to the dedicated service page.
In addition to the service pages displayed as a grid on the landing page, there’s a concept of “common tasks” represented as buttons along the top which are colour coded by action and information types. Each button can be linked to another CMS-managed page or a direct URL to a hosted service or downloadable file.
Service page
The bulk of the site content sits on service pages consisting of a basic structure: title, summary, body text with the mysterious ability to add additional components but no explanation as to what they are.
Buttons
The top of a service page can be decorated in the same way as the service landing pages with colour-coded task buttons that link off to pages, downloads or other websites such as application form processes hosted elsewhere.
The requirement to manually specify a parent page feels like it could get messy to manage moving content around in the future - but having the facility there is nice to help with breadcrumbs. Having to also link the same service page as a child page of a service sub-landing page did seem a little counterproductive though.
Related content
Similarly, there are options for two types of related content on a page; topics and links. With the default theme, both types of content are rendered in the same way on the right-hand side of the main content, separated by a heading.
Related links can be a mixture of internal pages and external website URLs that are hand-curated by the page's content editor.
To make the links list appear, you must ensure the “Replace automatically generated links” switch is in the “on” (checked) position.
The Related Topics list is automatically generated by listing any other “service landing” and “guide overview” pages in the CMS that have been tagged the same in the “Popular topics” list.
Directories
Listing things is a popular way to offer large amounts of information for browsing, searching and filtering. The Directory Channel concept provides a landing page pre-configured with a standard layout for search and facet filters, alongside a browsable list of directory venues.
The optional map displays all or filtered venue results at the top of a directory channel. Venues belong to a primary directory, and can also be added to other directory channels too - such as a school being listed under Schools, Community Centres, Polling stations and SEND provision directories.
Directory channels also have the ability to be bundled under a services content architecture so that a site visitor finds the right information at the right point of their journey.
Additional types of content can also be organised into directory channels for more advanced requirements needing specific data fields on forms and filters to narrow down the list of results.
With the great wealth of information that can be collected in a directory, the platform allows sharing this in an open structured way known as Open Referral. This means people can get the information they need more quickly and easily, and helps to create joined-up local communities and services. However, currently, there is no importer available to consume Open Referral content from other sites into LocalGov Drupal.
Guides
To ensure larger amounts of information are delivered in chunks that the widest number of citizens can understand and digest - the concept of information Guides are available.
A Guide “Overview” acts as a starting point for a journey of related content with next and previous navigation at the bottom of each Guide Page. The chapters in the Guide are, by default, displayed across the top of the pages for quickly jumping to the right section.
Guide Pages are fairly basic formatted text with no ability to embed different types of page layouts and content. This keeps the pages clear for the reader.
Subsites
Subsites allow you to create a more unique page on the site with its own look and feel, and its own internal navigation. A perfect example of this is the homepage which surfaces a number of services and content as well as showing off imagery and branding that reflects the local authority.
Another use case for this type of content is the rapid creation of mini-campaign sites. Internal navigation of the subsite is shown by default down the right-hand side and links off to editor-curated subpages. The display order of the links is managed on the subsite overview edit form.
Subsite overview
Creating a visually interesting homepage for a department or service can be achieved with the Subsite Overview page builder. Using the provided tools, you can drop in text, images, fact boxes, quotes and more across a selection of column layouts.
A developer can also define colour themes which are selectable when a content author is creating a new Subsite overview page.
The selection of page components that can be placed on your subsite page is extensible through the use of additional custom modules created by a developer.
Subsites include an optional nested navigation menu linking off to all the Subsite pages - which also have the capability of embedding the page layouts and components to create something unique for the reader.
Managing Content Accuracy
Approvals
Content authored on the site by non-editors is passed through a default editorial workflow which includes submitting draft content to be reviewed by an editor. At this point, a user with the Editor role has access to an approvals dashboard for reviewing the accuracy of the content before moving its status to published.
The workflow can be enhanced with the addition of further states and people involved if necessary. For example, adding a legal state to check content is compliant before being published.
Reviews
With potentially thousands of pages of information, there's scope for content to become stale and inaccurate over time. Keeping track of when content was published and reviewed by a responsible member of the team can ensure visitors receive up-to-date information and avoid complaints.
Microsites
Taking the subsites' capability to the next level allows reusing the features of LocalGov Drupal for individual microsites whilst still being based on a single codebase installed on a server. This reduces ongoing maintenance and provides a much more straightforward security upgrade process.
Councils are able to run many individual websites as part of their digital estate; each site has its own distinct domain name (or subdomain), visual design, content and users.
An unlimited number of content-rich pages can then be built using the multi-column layout options along with taking advantage of all the other types of content such as events, news and searchable directories of information - in exactly the same way as the LocalGov Drupal platform itself.
The platform
The microsite platform works with a main controller website that is used by an administrator to manage, add and archive individual microsites and their users.
Installation of the controller is separate to a main Local Gov Drupal website and uses a different GitHub repository at https://github.com/localgovdrupal/localgov_microsites - and our usage for this blog post is based on the v2 edition of LocalGov Microsites that is built on Drupal 9. To get up and running on a local machine to try it out use the project template available from the Localgov Microsites GitHub Project.
If your hosting provider has configured a wildcard domain for your microsites then any new site defined in the controller UI will instantly start responding on its own dedicated subdomain. The creation of associated SSL certificates per subdomain is something for your hosting team to consider as it’s not automatic.
Microsites can have their own dedicated domain name but will need your hosting team to assign the domain name as an alias to your controller server - thankfully this is a light-touch job.
If the microsite is for a fixed-term campaign or event the microsite can be shut down at the click of a button from within the controller - removing the need for any immediate IT department assistance. Deleting an archived microsite is not yet supported but can be done by removing both the group and the group domain manually.
Theme design
Basic branding of each microsite is administered through the CMS user interface removing the need for a developer to be involved in most cases. This includes colours, typefaces and page header and footer layout.
For more involved or unique sites a custom Drupal Twig theme can be built and uploaded to the server for a microsite to use.
The included base microsite theme comes with a bash script that automates the process of generating a new custom sub-theme for a developer to get going much quicker with a custom site theme.
Once the new sub-theme is ready a simple deployment to your hosting environment will make it available to select from within the microsite user interface. When building sub-themes you may wish to consider how it could be reused for similar future sites and provide it as a reusable theme instead of a one-off hardcoded one with specific branded site elements.
Separation of content
Every microsite allows individual users to be assigned to the CMS - meaning different teams can be responsible for the content creation and editorial process.
Each microsite begins with a default content page showing off most of the possibilities with the page builder components - this begins as your microsites homepage. Beware that every new microsite starts with the same homepage content and page title - which soon gets confusing if you don’t rename them to something unique when viewing at the controller level.
If you intend to deploy tens or hundreds of microsites over the years you may wish to redefine the default content created for a new microsite to be relevant to your local authority or provide a more helpful starter structure to the page. This can be achieved by defining a new homepage and exporting it back to code, details of how to do this are contained in the readme file.
This is where the advice is to log in to your individual microsites directly to manage the content once the site has been created. This ensures that the only content you are changing belongs to the microsite in question and you don’t accidentally edit the wrong site's homepage or add a news story to the wrong site.
Whilst logged in as a content editor or administrator of the microsite a lovely addition is the built in accessibility checker for your content (including the header and footer). This is activated by clicking the floating icon in the bottom right corner which activates an overlay on your microsite page to highlight issues and recommended solutions all from within the CMS.
Demos
If all this feels like too much, there are a couple of options available to you. The key is not to get overwhelmed by the capabilities available on the platform and instead find what's most suitable for your needs.
The easy option would be to browse the demo site available at https://demo.localgovdrupal.org/ - and experience the types of pages you can build out of the box using the default theme. However, it's important to note that the demo site has limited functionality, as you will not be able to utilise the content editing experience.
If you’d like your own sandbox version of LocalGov Drupal to play around in then Ixis can provide an environment for 30 days.
Getting Involved
As with any open-source project - the more users are involved the better it becomes for everyone, and LocalGov Drupal is no exception. Currently, the project is funded ad-hoc by Local Authorities funding parcels of functionality work and contributing work back to the project repositories hosted on GitHub.
For projects built by an agency and handed over to a council, consideration for the ongoing funding of the LocalGov Drupal project should be accounted for if the council expects to benefit from new features and updates being made available. If a council has internal technical staff then participation in the open-source project is appreciated with some time commitment from them sponsored by the council.
The principles of the Local Digital Declaration for public services have some great points that LocalGov Drupal also follow:
- an open culture that values, incentivises and expects digital ways of working from every member of the project team;
- working in the open;
- sharing our plans and experience;
- working collaboratively with other organisations;
- developing and reusing good practice;
- publishing our work under open-source licences.
The commitment to sharing work is reiterated in the platforms Memorandum of Understanding published on the projects site.
Product Roadmap
So what’s coming up next feature-wise and who decides where the project is going? Is there a risk for a council to be backing a future dead duck?
Addressing the duck situation - there’s minimal risk for a council to go with a site rebuild on LocalGov Drupal because, in the end, it is just the Drupal CMS under the hood. Any competent Drupal developer or agency can pick up the site and continue building on it and providing maintenance and security support for it.
Feature-wise a number of councils are working with their in-house and suppliers to release new functionality - including Forms creation, Microsites, HTML Publications, Solr Advanced Search.
The community maintain a roadmap of features and the working group who is taking responsibility for the delivery.
The roadmap is set by members of the Product Group which includes representatives from several councils and technical suppliers. The makeup of the project governance is covered on the LocalGov Drupal project site and is facilitated through video group meetings and a public LocalGov Drupal Slack community.
Quicker, cheaper, better
The aim of LocalGov Drupal has always been to enable local authorities to build a website quicker, cheaper and better. Whilst councils and government bodies are choosing to use and contribute to it, its objective will continue to be successful.
Choosing to use the LocalGov Drupal platform is an individual business decision which needs to be informed through understanding how a platform can best serve the requirements of a site. Understandably, we’re huge advocates of this platform to save money and mitigate the risk of ‘reinventing the wheel’. While we hope this quick stop guide has helped to demystify the platform, we’re happy to work together for more individual requirements or questions and give you a better insight into the LocalGov Drupal platform.
To discuss LocalGov Drupal in more detail, get in touch with our team today.
Add new comment