watermark

Helping a supportive organisation become streamlined with a rebuilt Drupal site

Introduction

STEM Learning aims to achieve a world-leading education for young people. Specifically in science, technology, engineering and mathematics.

As such, STEM supports teachers, technicians and support staff. This means providing high-quality continuing professional development (CPD), resources and student enrichment opportunities.

Before 2015, the various services were delivered via different websites. Meaning, users had a disjointed experience. STEM Learning issued a tender to create a single website and a new digital brand. So the ultimate aim was to combine services to improve user experience.

Code Enigma worked with the internal team at STEM Learning. Consequently, we created a new digital identity together. First, we created a single website containing all the key functionalities previously spread across multiple sites. Then we migrated data from those sites into the new site.

Why Drupal?

No preferred CMS was stated. However, there was a list of over 300 required features. These included various integrations with external systems, like events management and video platforms.

Additionally, the project had complex data migration requirements. Due to the range of data types from different websites combining into a new single site.

Firstly, using Drupal meant we could guarantee all the requirements could be met. Secondly, that this could be done in a responsive design. Also, so they would have a platform that could continue to be extended. Finally, we guaranteed that Drupal could support a busy online community of teachers.

Project requirements, goals and outcome 

The primary goal was to produce a website that is a STEM teacher's essential resource. Firstly, this involved amalgamating features spread across four separate legacy sites. Secondly, the creation of a new digital identity.

The new site had to contain almost all the legacy content. Namely, over 12,000 learning resources, 50,000 files, and 200,000 users. Besides migrating the users it was necessary to migrate their history. Including comments, forum memberships and bookmarks.

Specific requirements:

  • Multimedia learning resource publication
  • Course bookings and payments
  • Special interest groups
  • Forums
  • Comments
  • Tagged lists
  • Microsites
  • Customisable landing pages
  • Personalised dashboards

The project started in March 2015 and launched in December 2015. Now, it provides STEM Learning team with a single platform for supporting teachers.

Post-launch and Ongoing development 

Our relationship with STEM Learning did not end with the deployment of their new website. Additionally, they continue to develop and improve their digital offer. So, our developers still work with STEM to deliver new website functionalities.

Reporting

STEM needed ad-hoc report generation. Due to the need to track resource downloads and user registrations. And all within given time periods. Particularly, user registrations needed daily reports. Finally, the results needed to be exported to an external service.

We identified the requirements together. As a result, this helped determine the number of individual reports to create. Following this, we built several unique reports with different criteria for each report.

Spam monitoring 

We did deliver functionality for special interest groups and user comments. Following this, spammers, unfortunately, targeted the STEM website comments. Thus, there was a need for spam moderation.

We built custom dashboards which integrated with an external spam filtering tool. With these, STEM could do several things. Firstly, to see what had been automatically caught by the filter. Secondly, mark any false positives in the list. Finally, capture any spam not caught.

STEM Directory The STEM Directory was briefed as a database of opportunities offered by STEM businesses. Either for bringing into the classroom or real world.

We needed to devise a new workflow for directory activities. Due to the fact they needed moderation before going live. Along with this, a moderation area was created for easy publishing. Additionally, email notifications for the moderators and publishers were implemented.

A custom module was created to enable this to be delivered.

IA restructure 

As the STEM Learning offer grew, they identified changes in their audience. In this case, it expanded beyond the initial teachers. After review, STEM discovered which audiences to cater for. As a result, we refreshed the site's Information Architecture. In that we changed their sitemap and created several new pages to enable them to add their content.

 

Key modules/theme/distribution used:

  • Panelizer
  • Wysiwyg
  • Entity API
  • Panels
  • Facet API
  • Search API
  • Rules
  • Better Formats
  • Clientside Validation
  • Commerce
  • Shortcode
  • Flag
  • Message
  • Organic groups
  • Scheduler 

Why these were chosen: 

Content Creation

Normal users of the site should be allowed to create content by and for themselves. Meaning, the user interface for content creation had to be simple and small. Therefore modules like Better Formats and Clientside Validation were used. Firstly, this was to simplify the interface. Secondly, to provide a better experience when using forms.

Then modules like Protected Node and Scheduler were used. These allow editors to create a password-protected node and basic scheduling of content publication.

Following this, Wysiwyg, Insert, Oembed, Shortcode and Shortcode Wysiwyg modules were chosen to enrich the content creation experience. As such, it became easy to embed external contents within articles and site pages.

Finally, there was a lot of logic behind the scenes. Particularly for several content types that controlled on a node-level basis. Like field permissions efficiently limiting access to certain fields for specific roles.

Community Groups & Newsletters

They needed four types of group (with some variations of public and private). Also, each group needed roles and permissions. Organic Groups was the foundation to make all this possible.

As for newsletters and group content notifications, the Flag module allowed preferences per user. This was applied to each group (immediate notifications, daily digests, or weekly digests). After that, content alerts were built on top of this single flag type. The Message Stack and Digest controlled processing of contents to in message digests.

Microsites and landing pages creation tools

A key requirement was to allow site editors to create landing pages and microsites. Panels was the main structural module used. We did this to control organisation of sections and pages. Then they would be organised and provide a foundation to build custom landing pages on.

Panelizer allowed for different nodes to firstly have different layouts selected by editors. Secondly, to use a number of custom widgets. These were built as ctools content_types, and as instances of fieldable panel panes.

This was done to embed:

  • Twitter feeds
  • Search boxes to redirect to pages with pre-filtered options
  • Latest contents from selected groups
  • Blocks of multimedia content

Migration and integration with 3rd-party APIs

Migrate is instrumental for the site operation on a daily basis. Things like course information (and other details) updates happen daily on a 3rd-party backend. Custom migration scripts retrieve these updates or additions every few minutes.

Regarding the course booking (arguably commerce) side of the project; "groups" of interests. Rather than a forum.

Performance

The site is content-heavy. So, views, panel pages, etc, and some basic modules help performance. The most important ones being entitycache and memcache. The number of current nodes and users is 500k respectively. Plus a fair amount of custom entities.

It required a few custom tweaks, but Drupal coped very well with the amount of data. We’re proud to mention two custom modules we created to cope with this

Node Access Rebuild Progressive. A utility module providing an alternative mean of rebuilding the Content Access table.

Selective Watchdog Backend. A module allowing filtering of watchdog entries for backends, based on type and/or severity. Typical use would be having all entries logged to syslog for performance and some logged to the database for debugging and/or filtering.

Community contributions:

Ckeditor Insert

Semantic Views

File Compressor field

Get in touch today and tell us more about what you need