New Royal Academy of Dance Website – Core Website Functionality (Part 4)

The Base Website Theme

As one of the key objectives for the new Royal Academy of Dance website was to provide more flexibility for content authors to customise the layouts and look & feel of individual pages, it made sense to fully embrace the new WordPress Site Editor. We therefore created a new Block Theme to control the overall site appearance, instead of implementing a more traditional theme (as used by WordPress historically for this purpose).

Predefined Styling Options

The first step was to define all of the base colours, fonts, font sizes, and standard spacing measurements within the theme.json file; as well as the default configuration of various built-in content blocks. These would be used throughout the website, and helped to ensure design consistency – so it was important to get this right! Once this theme.json file was set up, it was then possible for content creators to customise individual blocks using the various options shown in the Block Editor:

The defined font sizes were set up to utilise WordPress’s built-in support for fluid typography (which uses clamping under the hood), to ensure that each font size scales proportionally, depending on the size of the screen or device being used to access the website. The default body text font size was made a bit larger than it was on the previous website, to improve accessibility for visually impaired users.

Additional Custom Styling

We then implemented some additional custom styling to provide more fine-grained control over the appearance of the website and individual content blocks than the built-in Block Editor or theme.json file can provide. This styling was implemented within SASS stylesheets – helping to making the styling more modular and less likely to conflict with the styling of other components upon the site, among other benefits. For consistency and to make it easier to make future changes to the default styling, CSS custom properties such as var(--wp--preset--color--primary) were used to reference the colour, sizing & spacing options defined within the theme.json file.

Although the WP Block Editor is very powerful and flexible, out of the box it does not provide a great deal of control over the way in which content can adapt so that it looks good when it gets displayed on different-sized mobile, tablet and desktop devices. Although WordPress solves this to a certain extent via the clever usage of Intrinsic Design to allow content to adapt automatically without requiring explicit customisation, this cannot work in all circumstances.

To overcome this, we considered using a 3rd-party solution to provide blocks with additional responsive configuration options – however we were concerned about the risk of additional ongoing maintenance overheads, increased complexity (both for developers and for content authors), technical debt, and divergence from core WP standards that could arise via this approach.

Instead we went for a simpler solution: Use the built-in WordPress block capabilities wherever possible, but implement a relatively small amount of custom styling in those fairly rare situations where more fine-grained control was needed to achieve the desired look and feel. The ability to add custom CSS classes to any block within the editor came in handy here.

Custom Patterns

While the built-in blocks do provide a lot of control and flexibility, we also wanted to make it as easy as possible for content authors to quickly build out pages using pre-defined layouts, which they could then use as a base to make any additional customisations that they desired. We therefore implemented over 50 custom patterns – essentially these were ‘starter kits’ that could quickly be inserted into the sections of each page; the content within each pattern can then be adjusted based on the relevant page, as well as any further layout tweaks:

To make it even easier to set up new pages, we combined multiple patterns & blocks into more than 15 Starter Patterns that defined the default layout & content structure of entire pages; a pop-up similar to the one shown below thus appears whenever a new page gets created:

In addition, it is possible to set up Synced Patterns in cases where the content & appearance of the relevant blocks needs to remain 100% identical upon every page where they are inserted.

Of course authors can also create new pages ‘from scratch’ if desired – but the above features certainly make the process easier.

Custom Blocks

The above functionality made it possible to add a lot of content onto the website. However the blocks that are built into WordPress itself do not include all of the capabilities that would ultimately be required for this site. We therefore needed to implement new custom blocks from scratch, to fill in these gaps – particularly for those ‘dynamic’ blocks that needed to retrieve content from elsewhere upon the website.

Our Approach

To implement these new custom blocks, we considered three potential approaches:

• Option 1: Create the blocks using the React JavaScript library (and/or custom PHP rendering logic) – similar to the blocks that are built into WordPress itself.
• Option 2: Use the ACF Blocks feature available within the 3rd-party Advanced Custom Fields plugin as a starting point to develop the custom blocks.
• Option 3: A combination of both of the above approaches, depending on the features needed within each individual block.

We took into account some of the following factors before making a final decision:

• The amount of flexibility that we would have over the relevant block UI controls, functionality & appearance.
• How closely the resulting blocks would follow standard WordPress conventions.
• Any potential opportunities to re-use existing code.
• Any additional overhead associated with using different approaches & conventions for different blocks.
• Implications with regard to the website loading speed & performance.
• The level of reliance upon any 3rd-party vendor to continue supporting the solution moving forward.
• How easily any technical issues can be debugged.
• The learning curve required for future developers to build new blocks & adjust existing ones.
• The amount of likely effort that would be required to build each block.
• The amount of ongoing future maintenance required to ensure that the blocks continue to work as expected.

Although this was a tough decision, we ultimately decided to go for Option 1. Although this would require a bit more effort to implement each block, and a slightly greater initial learning curve for future developers who need to work on the site; it is more in line with the approach that WordPress itself uses, as well as increasing flexibility – so this approach is more future-proof, as the platform evolves moving forward.

Examples of Our Custom Blocks

Flexible Group

This block was similar to the Group block built into WordPress, but included additional controls, such as the ability to add content that overlaps other content on the page.

Content Listing & Filtering Blocks

On this website, standard Posts are used for news articles, Pages were used for most content pages, and Custom Post Types are used for managing Events, Programmes and People upon the site. In addition, various custom Taxonomies were set up to allow this content to be categorised in various ways.

A common requirement was to display dynamic listings of this content (e.g. recent news articles, upcoming events, etc) elsewhere on the site. In most cases we used the built-in Query Loop block as a base for this functionality. This provided quite a bit of flexibility for authors to customise the appearance and content within each of the inner blocks within each listing, whilst also retrieving the relevant content dynamically from the relevant pages.

Some of these listings needed to include additional built-in filtering & sorting functionality. For example, within the event listings, only those events that had not already finished should be shown, and by default the events should be ordered based on the start date – so that events that are due to take place in the near future are shown first. We achieved this by hooking into the query_loop_block_query_vars filter, to customise the parameters that get passed into the WP_Query object.

To ensure these changes were also reflected in the preview of these listings shown within the Block Editor, we hooked into the rest_{post_type}_query filter in a similar way, to adjust the records retrieved by the WP REST API.

Certain pages needed more sophisticated capabilities, such as the News and Events listing pages. On these pages, normal website visitors need to be able to search for specific posts/events, as well as filter the results based on various other criteria. To achieve this, we implemented custom blocks for these filter options. These custom blocks were designed to work in conjunction with the separate Query Loop blocks on these pages, using similar (albeit more sophisticated) mechanisms as the ones described above to override the built-in behaviour of the query being sent to the underlying database.

To complicate matters, certain details such as event dates are stored as post metadata, and it was also important to respect any additional filter options that have been configured via the site admin area, as well as those filter options specified by the site visitor. Therefore the parameters passed into the WP_Query object are quite complex in some cases, sometimes involving multiple nested meta_query AND & OR conditions.

Carousels

Carousels are used in a number of places on the website – both for static content and to display dynamic listings. These use the Slick JS library; with dynamic listings utilising Query Loop blocks as above.

To ensure that this script only loads on those pages that actually include carousel blocks (and thus to reduce website loading times), and to initialise it with all the correct parameters, we implemented some deep customisations to adjust the inner behaviour of the Query Loop block by implementing a custom block_type_metadata_settings filter in conjunction with some custom render callback functions to override the built-in WordPress behaviour.

Content Tabs & Concertinas

Some of the content on the website is presented in tabs, where the content is revealed by clicking on the relevant tab:

Similarly, there are concertinas with sections that can be expanded to reveal the content within that section:

In both cases, Group blocks are used to group the content to be displayed in each tab or concertina section, with some frontend JavaScript code that traverses the page DOM to find blocks on the page that match the relevant patterns, and auto-initialises the appropriate JQuery UI widgets for these elements (JQuery UI is used here because it is stable and widely used library that is bundled within WordPress itself, avoiding the need to add extra dependencies).

Again, a similar mechanism to the one implemented for carousels (as described above) is used to ensure this JS code only loads on pages that actually include content tab or concertina blocks.

Event Details

A number of custom blocks were implemented for usage upon event pages. These provide a straightforward content management experience for authors, as we implemented controls to allow content to either be entered directly within the Block Editor, or additional settings to be customised using controls such as date pickers.

Behind the scenes, the data added to these blocks are stored within post meta, to allow this data to easily be displayed within listings elsewhere on the site. This also allowed the relevant data to be used in conjunction with the filter/search options available to users, as described above.

Featured Event Block

The Royal Academy of Dance requested a block that would allow a specified event to be ‘featured’ on a page. They required the ability to be able to easily select the event that they wanted to feature on that page, whilst also being able to customise the inner content and appearance of the block as required.

To achieve these aims, we implemented a custom block variation to extend the default Query Loop block. This made it possible to add a ‘find-as-you-type’ control, to allow the relevant event to be quickly selected. The Query Loop could then take care of retrieving the relevant event content, with the inner blocks being customisable, similar to the listing & filtering blocks described above.

Find out more in the fifth part to our technical series: Managing Content for Multiple Countries »