Sector(s)
Visit the site
Visit the siteOrganizations Involved
Community contributions
Contribution to various issues on drupal.org with three patches being committed; one to Drupal Commerce core and two to the Commerce Stripe module.
Herts for Learning (HfL) is a not for profit education company, delivering education and business services, resources and products in order to help young people in Hertfordshire and beyond realise their potential.
Zoocha were selected by HFL in January 2017 to redesign and rebuild their website using Drupal 8.
About the project
Goals
The goal of the project was to re-design and re-develop the existing Herts for Learning website, integrating their standalone ecommerce and blog solutions, as well as restructuring how they managed user access to private content and files (which together formed a number of purchasable subscriptions).
Back to topRequirements
The HfL digital team brief also included a number of other requirements, such as:
- More flexible page templates over their existing heavily templated pages
- A fresh look and feel, in keeping with the existing brand guidelines, along with being responsive across a wide array of devices and browsers
- The ability to surface elements of content for anonymous users that had historically been hidden
- A tiered
- user account structure so that specific roles within a subscribing organisation (Multi Academy Trust or School) can access the specific content for their role
Outcomes
The new website launched in November 2017 with the following outcomes:
- More content to attract new customers. All content resources that were previously unavailable to anonymous users were created as individual products making them available to search and be purchased online. Previously subscription content was managed almost entirely within the Organic Groups module and it was therefore difficult to demonstrate to potential customers the breadth of resources and services offered. The new structure also enables HfL to sell resources individually, as well as part of subscriptions/packages.
- Engaging content using component led pages. During the design phase we had worked with the HfL team to create a bank of content components and page layouts, that could be used to build different content experiences. This included multimedia components as well as a number of components that use taxonomy terms to dynamically surface content and products for an easy cross sell.
- Subscription based products and services. The website provides the ability to create and sell subscription based products and services, allowing access to restricted web content and/or files for subscribed users. This was significant because previously all subscriptions were sold and managed offline and was therefore labor intensive. The subscriptions also include auto-renewal (based on recurring payments).
- Multi-tiered accounts. One of the key requirements was to provide education providers (multi academy trusts, schools etc) with the ability to create sub-accounts for their staff/ departments so that permission to access specific products/ content could be accessible to the relevant users in their organisation. The implementation has been future proofed to accommodate for Multi Academy Trust accounts.
Why Drupal was chosen
With Herts for Learning already having experience of Drupal within their organisation via its use on other projects, and team members having familiarity with it from previous roles outside of HfL, Drupal was quickly decided upon internally at HfL before the project brief was put out for tender.
The previous iteration of the project was also largely based upon Drupal 6 (which at the time was rapidly approaching EOL), so it made sense to stick with Drupal as that was a CMS that HfL were already familiar and happy with.
One of the most attractive things about Drupal to HfL was Drupal’s ability to combine content and commerce in a flexible, single platform solution.
The project brief did not specify which version of Drupal the project should be delivered using either, but after evaluating the Drupal 8 project timelines and the status of key module development, a decision was made. Drupal 8 was chosen as the desired CMS so that a greater degree of functionality would be achievable out-of-the-box, along with giving the platform extra longevity over a Drupal 7 based solution.
Technical Specifications
Drupal version:
Key modules/theme/distribution used:
Commerce
At the start of the project (Jan 2017) Drupal Commerce had not reached full release status for Drupal 8, nor had many of the Commerce contrib modules that one would generally rely on during a Drupal Commerce build.
However, despite this risk, the HfL project schedule and Drupal Commerce releases converged at the right time so that a robust, flexible implementation of a complex set of e-commerce requirements could be delivered on time and on budget.
The e-commerce implementation for HfL needed to allow for vastly differing product types, including digital downloads, physical products that need to be delivered, subscription based products, along with taxable and tax exempt products. This meant that the requirements were an ideal fit for Drupal Commerce.
To add to this product type complexity, digital download products needed to be accessible by team members within a purchasing organisation, so this meant that methods of secure digital asset distribution and reporting needed to be designed into the solution.
The custom subscription functionality also presented challenges, whereby during the auto-renewal process a new order would be created, payment would be processed, and access would need to be preserved to those products for all users which previously had it. Prior to launch it was also necessary to migrate all products (maintaining existing SKUs) and users along with their existing subscriptions and purchases to maintain continuity of service for all users.
The payment gateway used on the project was Stripe, whereby the integration was achieved using the Commerce Stripe module. With the Commerce Stripe module being in its relative Drupal 8 infancy at the time in the project when it was being integrated, we had the opportunity to contribute towards its development with a couple of bug fixes for issues that we encountered during the development.
Paragraphs
The Paragraphs module is becoming a mainstay of functionality on modern Drupal sites where editorial teams are demanding ever increasing flexibility over how they assemble pages on their sites.
The HfL Implementation of the Paragraphs module saw the need to create over 20 different Paragraph component types to satisfy the requirements of the project. This allows pages that look drastically different from one another to be self-served by the HfL team. For example:
https://www.hertsforlearning.co.uk/leadership-and-management/school-improvement-services
https://www.hertsforlearning.co.uk/teaching-and-learning
When properly implemented, usage, and the need for traditional WYSIWYG type functionality is minimised to only small portions of the content on a given page. The net effect of this is that pages created by client teams work much more effectively cross-browser, and across a range of common devices.
Search API
With search functionality being such a critically important feature of the HfL site, given the breadth and depth of content on the site, the Search API module was chosen as the primary application interface with Apache Solr.
The Search API module allowed us to dynamically expose search facets based on the search term used, and rank the search results based on a relevancy scoring dictated by the client.
What the module also allowed us to do was categorise the search results into primary content types (Resources, Blogs, Events etc), and then filter by a hierarchical set of taxonomy terms and vocabularies.
Flag
Advanced usage of the Flag module was incorporated into the project for controlling access to, and the subscription expiry of digital products. This functionality was achieved using the Flag API.
This is not a typical use of the Flag module as it is much more common to see it being used to provide basic bookmarking type abilities on a site, but the application of its feature set in this setting demonstrates the advanced capabilities of the module that can be called upon when its API is fully understood.
Features
As with any large Drupal site that has a broad cross section of content types and entities to manage, Features helps out massively when it comes to encapsulating the configuration of the site, along with any associated functionality into small, easily maintainable modules.
On this project, each Feature relates to a component on the site, e.g. hfl_commerce or hfl_user so that it is easy to recognise when browsing the code what everything does. Having generic Features like views or content_types gets very unwieldy and difficult to maintain.
Back to top
