Skip to main content

Drupalcon 2015

People from across the globe who use, develop, design and support the Drupal platform will be brought together during a full week dedicated to networking, Drupal 8 and sharing and growing Drupal skills.

As we have active hiring plans we’ve decided that this year’s approach should have a focus on meeting people who might want to work for Wunderkraut and getting Drupal 8 out into the world.
As Signature Supporting Partner we wanted as much people as possible to attend the event. We managed to get 77 Wunderkrauts on the plane to Barcelona!  From Belgium alone we have an attendance of 17 people.
The majority of our developers will be participating in sprints (a get-together for focused development work on a Drupal project) giving all they got together with all other contributors at DrupalCon.

We look forward to an active DrupalCon week.  
If you're at DrupalCon and feel like talking to us. Just look for the folks with Wunderkraut carrot t-shirts or give Jo a call at his cell phone +32 476 945 176.

Share

Related Blog Posts

Want to know more?

or call us +32 (0)3 298 69 98

© 2015 Wunderkraut Benelux

Once again Heritage day was a huge succes.

About 400 000 visitors visited Flanders monuments and heritage sites last Sunday.  The Open Monumentendag website received more than double the amount of last year's visitors.

Visitors to the website organised their day out by using the powerful search tool we built that allowed them to search for activities and sights at their desired location.  Not only could they search by location (province, zip code, city name, km range) but also by activity type, keywords, category and accessibility.  Each search request being added as a (removable) filter for finding the perfect activity.

By clicking on the heart icon, next to each activity, a favorite list was drawn up.  Ready for printing and taking along as route map.

Our support team monitored the website making sure visitors had a great digital experience for a good start to the day's activities.

Did you experience the ease of use of the Open Monumentendag website?  Are you curious about the know-how we applied for this project?  Read our Open Monumentendag case.

But in this post I'd like to talk about one of the disadvantages that here at Wunderkraut we pay close attention to.

A consequence of the ability to build features in more than one way is that it's difficult to predict how different people interact (or want to interact) with them. As a result, companies end up delivering solutions to their clients that although seem perfect, turn out, in time, to be less than ideal and sometimes outright counterproductive. 

Great communication with the client and interest in their problems goes a long way towards minimising this effect. But sometimes clients realise that certain implementations are not perfect and could be made better. And when that happens, we are there to listen, adapt and reshape future solutions by taking into account these experiences. 

One such recent example involved the use of a certain WYSIWYG library from our toolkit on a client website. Content editors were initially happy with the implementation before they actually started using it to the full extent. Problems began to emerge, leading to editors spending way more time than they should have performing editing tasks. The client signalled this problem to us which we then proceed to correct by replacing said library. This resulted in our client becoming happier with the solution, much more productive and less frustrated with their experience on their site. 

We learned an important lesson in this process and we started using that new library on other sites as well. Polling our other clients on the performance of the new library revealed that indeed it was a good change to make. 

If your website is running Drupal 6, chances are it’s between 3 and 6 years old now, and once Drupal 8 comes out. Support for Drupal 6 will drop. Luckily the support window has recently been prolonged for another 3 months after Drupal 8 comes out. But still,  that leaves you only a small window of time to migrate to the latest and greatest. But why would you? 

There are many great things about Drupal 8 that will have something for everyone to love, but that should not be the only reason why you would need an upgrade. It is not the tool itself that will magically improve the traffic to your site, neither convert its users to start buying more stuff, it’s how you use the tool.  

So if your site is running Drupal 6 and hasn’t had large improvements in the last years it might be time to investigate if it needs a major overhaul to be up to par with the competition. If that’s the case, think about brand, concept, design, UX and all of that first to understand how your site should work and what it should look like, only then we can understand if a choice needs to be made to go for Drupal 7 or Drupal 8.  

If your site is still running well you might not even need to upgrade! Although community support for Drupal 6 will end a few months after Drupal 8 release, we will continue to support Drupal 6 sites and work with you to fix any security issues we encounter and collaborate with the Drupal Security Team to provide patches.

My rule of thumb is that if your site uses only core Drupal and a small set of contributed modules, it’s ok to build a new website on Drupal 8 once it comes out. But if you have a complex website running on many contributed and custom modules it might be better to wait a few months maybe a year until all becomes stable. 

In combination with the FacetAPI module, which allows you to easily configure a block or a pane with facet links, we created a page displaying search results containing contact type content and a facets block on the left hand side to narrow down those results.

One of the struggles with FacetAPI are the URLs of the individual facets. While Drupal turns the ugly GET 'q' parameter into a clean URLs, FacetAPI just concatenates any extra query parameters which leads to Real Ugly Paths. The FacetAPI Pretty Paths module tries to change that by rewriting those into human friendly URLs.

Our challenge involved altering the paths generated by the facets, but with a slight twist.

Due to the projects architecture, we were forced to replace the full view mode of a node of the bundle type "contact" with a single search result based on the nid of the visited node. This was a cheap way to avoid duplicating functionality and wasting precious time. We used the CTools custom page manager to take over the node/% page and added a variant which is triggered by a selection rule based on the bundle type. The variant itself doesn't use the panels renderer but redirects the visitor to the Solr page passing the nid as an extra argument with the URL. This resulted in a path like this: /contacts?contact=1234.

With this snippet, the contact query parameter is passed to Solr which yields the exact result we need.

/**
 * Implements hook_apachesolr_query_alter().
 */
function myproject_apachesolr_query_alter($query) {
  if (!empty($_GET['contact'])) {
    $query->addFilter('entity_id', $_GET['contact']);
  }
}

The result page with our single search result still contains facets in a sidebar. Moreover, the URLs of those facets looked like this: /contacts?contact=1234&f[0]=im_field_myfield..... Now we faced a new problem. The ?contact=1234 part was conflicting with the rest of the search query. This resulted in an empty result page, whenever our single search result, node 1234, didn't match with the rest of the search query! So, we had to alter the paths of the individual facets, to make them look like this: /contacts?f[0]=im_field_myfield.

This is how I approached the problem.

If you look carefully in the API documentation, you won't find any hooks that allow you to directly alter the URLs of the facets. Gutting the FacetAPI module is quite daunting. I started looking for undocumented hooks, but quickly abandoned that approach. Then, I realised that FacetAPI Pretty Paths actually does what we wanted: alter the paths of the facets to make them look, well, pretty! I just had to figure out how it worked and emulate its behaviour in our own module.

Turns out that most of the facet generating functionality is contained in a set of adaptable, loosely coupled, extensible classes registered as CTools plugin handlers. Great! This means that I just had to find the relevant class and override those methods with our custom logic while extending.

Facet URLs are generated by classes extending the abstract FacetapiUrlProcessor class. The FacetapiUrlProcessorStandard extends and implements the base class and already does all of the heavy lifting, so I decided to take it from there. I just had to create a new class, implement the right methods and register it as a plugin. In the folder of my custom module, I created a new folder plugins/facetapi containing a new file called url_processor_myproject.inc. This is my class:

/**
 * @file
 * A custom URL processor for cancer.
 */

/**
 * Extension of FacetapiUrlProcessor.
 */
class FacetapiUrlProcessorMyProject extends FacetapiUrlProcessorStandard {

  /**
   * Overrides FacetapiUrlProcessorStandard::normalizeParams().
   *
   * Strips the "q" and "page" variables from the params array.
   * Custom: Strips the 'contact' variable from the params array too
   */
  public function normalizeParams(array $params, $filter_key = 'f') {
    return drupal_get_query_parameters($params, array('q', 'page', 'contact'));
  }

}

I registered my new URL Processor by implementing hook_facetapi_url_processors in the myproject.module file.

**
 * Implements hook_facetapi_url_processors().
 */
function myproject_facetapi_url_processors() {
  return array(
    'myproject' => array(
      'handler' => array(
        'label' => t('MyProject'),
        'class' => 'FacetapiUrlProcessorMyProject',
      ),
    ),
  );
}

I also included the .inc file in the myproject.info file:

files[] = plugins/facetapi/url_processor_myproject.inc

Now I had a new registered URL Processor handler. But I still needed to hook it up with the correct Solr searcher on which the FacetAPI relies to generate facets. hook_facetapi_searcher_info_alter allows you to override the searcher definition and tell the searcher to use your new custom URL processor rather than the standard URL processor. This is the implementation in myproject.module:

/**
 * Implements hook_facetapi_search_info().
 */
function myproject_facetapi_searcher_info_alter(array &$searcher_info) {
  foreach ($searcher_info as &$info) {
    $info['url processor'] = 'myproject';
  }
}

After clearing the cache, the correct path was generated per facet. Great! Of course, the paths still don't look pretty and contain those way too visible and way too ugly query parameters. We could enable the FacetAPI Pretty Path module, but by implementing our own URL processor, FacetAPI Pretty Paths will cause a conflict since the searcher uses either one or the other class. Not both. One way to solve this problem would be to extend the FacetapiUrlProcessorPrettyPaths class, since it is derived from the same FacetapiUrlProcessorStandard base class, and override its normalizeParams() method.

But that's another story.

Ressources

Migrate in Drupal 8

Migrate is now included in the Drupal core for making the upgrade path from 6.x and 7.x versions to Drupal 8.

Drupal 8 has two new modules :
Migrate: « Handles migrations »
Migrate Drupal : « Contains migrations from older Drupal versions. »

None of these module have a User Interface.

« Migrate » contains the core framework classes, the destination, source and process plugins schemas and definitions, and at last the migration config entity schema and definition.

« Migrate Drupal » contains implementations of destination, sources and process plugins for Drupal 6 and 7 you can use it or extend it, it's ready to use. But this module doesn't contain the configuration to migrate all you datas from your older Drupal site to Drupal 8.

The core provides templates of migration configuration entity that are located under each module of the core that needs one, under a folder named 'migration_templates' to find all the templates you can use this command in your Drupal 8 site:

To make a Drupal core to core migration, you will find all the infos here : https://www.Drupal.org/node/2257723 there is an UI in progress for upgrading.

A migration framework

Let have a look at each big piece of the migration framework :

Source plugins

Drupal provides an interface and base classes for the migration source plugin :

• SqlBase : Base class for SQL source, you need to extend this class to use it in your migration.
• SourcePluginBase : Base class for every custom source plugin.
• MenuLink: For D6/D7 menu links.
• EmptySource (id:empty): Plugin source that returns an empty row.
• ...

Process plugins

There is the equivalent of the D7 MigrateFieldHandler but this is not reduced to fields or to a particular field type.
Its purpose is to transform a raw value into something acceptable by your new site schema.

The method transform() of the plugin is in charge of transforming your $value or skipping the entire row if needed.
If the source property has multiple values, the transform() will happen on each one.

Drupal provides migration process plugin into each module of the core that needs it (for the core upgrade),
To find out which one and where it is located you can use this command :

Destination plugins

Destination plugins are the classes that handle where your data are saved in the new Drupal 8 sites schemas.

Drupal provides a lot of useful destination classes :

• DestinationBase : Base class for migrate destination classes.
• Entity (id: entity) : Base class for entity destinations.
• Config (id: config) : Class for importing configuration entities.
• EntityBaseFieldOverride (id: entity:base_field_override): Class for importing base field.
• EntityConfigBase : Base class for importing configuration entities.
• EntityImageStyle (id: entity:image_style): Class for importing image_style.
• EntityContentBase (id: entity:%entity_type): The destination class for all content entities lacking a specific class.
• EntityNodeType: (id: entity:node_type): A class for migrate node type.
• EntityFile (id: entity:file): Class for migrate files.
• EntityFieldInstance: Class for migrate field instance.
• EntityFieldStorageConfig: Class for migrate field storage.
• EntityRevision, EntityViewMode, EntityUser, Book...
• And so more…

Builder plugins:

"Builder plugins implement custom logic to generate migration entities from migration templates. For example, a migration may need to be customized based on the data that is present in the source database; such customization is implemented by builders." - doc API

This is used in the user module, the builder create a migration configuration entity based on a migration template and then add fields mapping to the process, based on the data in the source database. (@see /Drupal/user/Plugin/migrate/builder/d7/User)

Id map plugins:

"It creates one map and one message table per migration entity to store the relevant information." - doc API
This is where rollback, update and the map creation are handled.
Drupal provides the Sql plugin (@see /Drupal/migrate/Plugin/migrate/id_map/Sql) based on the core base class PluginBase.

And we are talking only about core from the beginning.
All the examples (That means docs for devs) are in core !

About now :

While there *almost* a simple UI to use migration in Drupal 8 for Drupal to Drupal, Migrate can be used for every kind of data input. The work is in progess for http://Drupal.org/project/migrate_plus to bring an UI and more source plugins, process plugins and examples. There already is the CSV source plugin and a pending patch for the code example. The primary goal of « migrate plus » is to have all the features (UI, Sources, Destinations.. ) of the Drupal 7 version.

Concrete migration

(migration with Drupal 8 are made easy)

I need to migrate some content with image, attached files and categories from custom tables in an external SQL database to Drupal.

To begin shortly :

• Drush 8 (dev master) and console installed.
• Create the custom module (in the code, I assume the module name is “example_migrate”):
  $ Drupal generate:module
  or create the module by yourself, you only need the info.yml file.
• Activate migrate and migrate_plus tools
  $ Drupal module:install migrate_tools
  or
  $ drush en migrate_tools
• What we have in Drupal for the code example :
  • a taxonomy vocabulary : ‘example_content_category’
  • a content type ‘article’
  • some fields: body, field_image, field_attached_files, field_category
• Define in settings.php, the connexion to your external database:

We are going to tell migrate source to use this database target. It happens in each migration configuration file, it’s a configuration property used by the SqlBase source plugin:

This is one of the reasons SqlBase has a wrapper for select query and you need to call it in your source plugin, like $this->select(), instead of building the query with bare hands.

N.B. Each time you add a custom yml file in your custom module you need to uninstall/reinstall the module for the config/install files to imports. In order to avoid that, you can import a single migration config file by copy/paste in the admin/config configuration synchronisation section.

The File migration

The content has images and files to migrate, I suppose in this example that the source database has a unique id for each file in a specific table that hold the file path to migrate.

We need a migration for the file to a Drupal 8 file entity, we write the source plugin for the file migration:

File: src/Plugin/migrate/source/ExampleFile.php

We have the source class and our source fields and each row generate a path to the file on my local disk.

But we need to transform our external file path to a local Drupal public file system URI, for that we need a process plugin. In our case the process plugin will take the external filepath and filename as arguments and return the new Drupal URI.

File: src/Plugin/migrate/process/ExampleFileUri.php

We need another process plugin to transform our source date values to timestamp (created, changed), as the date format is the same across the source database, this plugin will be reused in the content migration for the same purpose:

File: src/Plugin/migrate/process/ExampleDate.php

For the destination we use the core plugin: entity:file.

Now we have to define our migration config entity file, this is where the source, destination and process (field mappings) are defined:

File: config/install/migrate.migration.example_file.yml

We are done for the file migration, you can execute it with the migrate_tools (of the migrate_plus project) drush command:

The Term migration

The content has categories to migrate.
We need to import them as taxonomy term, in this example I suppose the categories didn't have unique ids, it is just a column of the article table with the category name…

First we create the source :

File: src/Plugin/migrate/source/ExampleCategory.php

And we can now create the migration config entity file :

File: config/install/migrate.migration.example_category.yml

This is done, to execute it :

The Content migration

The content from the source has an html content, raw excerpt, image, attached files, categories and the creation/updated date in the format Y-m-d H:i:s

We create the source plugin:

File: src/Plugin/migrate/source/ExampleContent.php

Now we can create the content migration config entity file :

File: config/install/migrate.migration.example_content.yml

Finally, execute it :

Group the migration

Thanks to migrate_plus, you can specify a migration group for your migration.
You need a to create a config entity for that :

File: config/install/migrate_plus.migration_group.example.yml

Then in your migration config yaml file, be sure to have the line migration_group next to the label:

So you can use the command to run the migration together, and the order of execution will depend on the migration dependencies:

I hope that you enjoyed our article.

Best regards,

Delta https://www.drupal.org/u/delta

What is a views display extender

The display extender plugin allow to add additional options or configuration to a views regardless of the type of display (e.g. page, block, ..).

For example, if you wanted to allow site users to add certain metadata to the rendered output of every view display regardless of display type, you could provide this option as a display extender.

What we can do with it

We will see how we implement such a plugin, for the example, we will add some metadata (useless metatags as example) to the document head when the views is displayed.

We will call the display extender plugin HeadMetadata (id: head_metadata) and we will implement it in a module called views_head_metadata.

The implementation

Make our plugin discoverable

Views do not discover display extender plugins with a hook info as usual, for this particular type of plugin, views has a variable in his views.settings configuration object.

You need to add your plugin ID to the variable views.settings.display_extenders (that is a list).

To do so, I will recommend you to implement the hook_install (as well uninstall) in the module install file. To manipulate config object you can look at my previous notes on CMI.

Make the plugin class

As seen in the previous post on Drupal 8 plugins, you need to implement the class in the plugin type namespace, extend the base class for this type of plugin, and add the metadata annotation.

In the case of the display extender plugin, the namespace is Drupal\views_head_metadata\Plugin\views\display_extender, the base class is DisplayExtenderPluginBase, and the metadata annotation are defined in \Drupal\views\Annotation\ViewsDisplayExtender.

The display extender plugins methods are nearly the same that the display plugins, you can think of its like a set of methods to alter the display plugin.

The important methods to understand are :

• defineOptionsAlter(&$options) : Define an array of options your plugins will define and save. Sort of schema of your plugin.
• optionsSummary(&$categories, &$options) : To add a category (the section of the views admin interface) if you want to add one, and define your options settings (in wich category there are, and the value to display as the summary).
• buildOptionsForm(&$form, FormStateInterface $form_state) : Where you construct the form(s) for your plugin, of course linked with a validate and submit method.

Generate the metadata tags in the document head

Now that we have our settings added to every views display, we need to use those to generate the tags in the document head as promised.

To work on the views render we will use the hook for that : hook_views_pre_render($view) and the render array property #attached.

Implement that hook in the .module of our module views_head_metadata, let's see :

Headless websites have taken the industry by storm, promising to deliver unique brand experiences that enable customer loyalty. Using a headless approach for your project allows you to combine technologies that would normally be siloed due to language or server constraints.

Typically when we talk about a headless Drupal architecture, we are referring to using Drupal for its strength as a content management system (CMS), but using a framework like React or Vue to drive the frontend. This separation of concerns allows your teams to focus on using the tools they know best—ultimately delivering a better product.

The single most important metric in commerce implementations is response time. A website’s overall responsiveness can directly affect the conversion rate and the bottom line. According to a study by Porent in 2019, "The highest e-commerce conversion rates occur between 0 and 2 seconds, spanning an average of 8.11% e-commerce conversion rate at less than 1 second, down to a 2.20% e-commerce conversion rate at a 5 second load time." Let's explore why traditional commerce implementations are so slow and why headless might just be the solution.

Why Use Drupal as a Commerce Platform?

Before we consider the frontend, we need a robust, secure backend platform to deliver our data and business logic. One of the many reasons Drupal is a great candidate for headless, or really any CMS build, is its inherent flexibility and security. Drupal's fieldable entities mean you can structure your CMS to fit your data. Drupal is regularly screened for vulnerabilities and has a robust process to identify and fix security issues. This is especially important in commerce implementations where proprietary data is often pulled from a Product Information Management (PIM) system like Akeneo.

Drupal's true power comes in the form of a massive library of community-contributed and maintained modules. A great example of this is the Drupal Commerce suite maintained by Centarro. Drupal Commerce out-of-the-box provides a robust set of entities and plugins that provide a complete commerce experience. Commerce can be further customized by Contrib modules that provide everything from payment processors (like Stripe or Paypal) to shipping integrations (like UPS or FedEx). Community-contributed modules are the cornerstone of the Drupal platform, and the projects we build make them possible.

Customizing Your Drupal Commerce Forms

Why Is Traditional Commerce Slow?

In a traditional Magento or Drupal Commerce implementation, we often create frontend markup on the backend before delivering the page to the user. As we generate this markup, we make calls to various APIs like shipping rate calculators. Once we have this complete HTML document, we send it to the browser. The browser then parses this markup and scans it for additional documents like CSS, Javascript, and images. Once it gathers all of this data, it turns it into an interactable web page. All of these things make the average page load speed roughly 7 seconds on desktop. That's quite the gap between our target of <2 seconds.

To alleviate the work the backend has to do to render a page, we've come up with some pretty clever tricks. One example is using Edge Side Includes (ESIs). ESIs work by loading the majority of page content from cache, then replacing specific placeholders with dynamic calls to the server. Since the server doesn't need to render the complete markup, we can often achieve faster load times. Drupal Core offers BigPipe, a module that similarly renders the majority of a page from cache, then replaces placeholders with dynamic content. Oftentimes these solutions come at a high complexity and frequently cause problems related to caching. They also don't work for content that is highly dynamic like category pages with facets and filters.

How Does Headless Help?

When we implement a headless website, we can think of the frontend as less like a web page and more as an application. A properly designed React (or other JS frontend framework) app can be lightweight and heavily cacheable. On initial page load, we load our entire application into working memory. This means that as a user navigates through the site, they are actually interacting with a single-page application that does not require a page reload to show new content.

The reason we can get away with not reloading the page is that data can be asynchronously fed to the frontend. This means that as a user is browsing the site we can preload resources like images and linked pages. When we can run expensive operations independently of a user's browsing experience, we can make website response times appear to be instantaneous—or more within our targeted 0-2 second range.

How Do We Get There?

On the backend, you still need a robust, secure CMS to feed data to the frontend and handle complex or session actions (add to cart/checkout validation). This is where Drupal is an easy choice. One of the easiest ways to feed data to a frontend is via JSON data. Drupal Core provides the JSON:API module which allows you to easily expose your content as filterable JSON objects. This means you can leverage the strength of the Drupal Community while giving your frontend room to prefetch and asynchronously validate data.

Building a world-class commerce website necessitates a world-class toolset, but even more so a world-class team. Drupal has proven to be a reliable CMS capable of delivering highly custom experiences. When this is paired with a well-built frontend, load times become instantaneous, and conversion rates increase!

Enterprise organizations are increasingly looking at Drupal as a reliable, open source option for developing their online presence—contributing and benefiting from the active community base and potentially taking advantage of cutting-edge, decoupled capabilities.

With over 10 years of Drupal experience and implementations ranging from small to complex, we are often asked to recommend the best approach for building a Drupal site. The answer, as with many questions is, it depends. For some clients, the best choice is to build a traditional, coupled Drupal website. For other clients, it makes sense to build a completely decoupled solution using Drupal as the backend. And for others, the best solution is somewhere in between. Many factors determine which is the best approach for a particular client and their situation.

One important factor in deciding what approach to take is to understand the needs and skills of the people that will use and maintain the system. The two main users to consider are the content creators and others that will work in the system daily and the developers that will build and maintain the system.

View Webinar Recording: Building Enterprise Websites with Drupal: Unleash Your Full Potential

Considering the Content Manager

For the content creators and content managers that work directly in the content management system (CMS), having an easy-to-use content admin system is key. Drupal has increasingly focused on this experience and has provided many features with this in mind. With traditional Drupal, content editors can quickly create pages leveraging the drag-and-drop capabilities of Layout Builder. Inline editing allows content editors to make quick changes to the content without diving deep into the content admin UI. And, content preview is available to review before publishing the content to the website.

All of this is also possible in a decoupled solution, but the developers must build and maintain this functionality or cobble a solution together from existing technologies. If the project requirements already require changes to Drupal's out-of-the-box functionality, building from scratch may be easier.

Considering the Development Team

The development team's skills are also an important consideration. If you have a team that has deep technical knowledge of a technology (or a desire to develop that knowledge), that can have an impact on the recommended approach. For instance, if your team has never themed a Drupal site before, but has experience with React, using a decoupled approach would fit nicely with the team's skills.

Like any framework, it takes time to learn how to theme Drupal sites. If you have a small team that is spread thin or maybe you don't have a team, a coupled approach using Layout Builder or Acquia's Site Studio could give your content editing team the flexibility it needs without requiring much help from a development team.

Considering the Digital Strategy

The overall digital strategy is an important factor to consider as well. Will the platform support a single site or is this a key piece to a multisite, multi-brand digital platform? Is Drupal the only platform involved, or is Drupal a part of a broader digital experience platform (DXP) that includes CRMs, Commerce platforms, a CDP, and other platforms? Whether working with Acquia, the open digital experience platform built on top of Drupal, or connecting into other tools—Drupal is designed to make these connections easy.

Drupal is a great platform to integrate with other platforms. Many integrations are easy to implement by installing a community module. Drupal provides a robust migration system that makes pulling data into Drupal easy to do. Drupal also makes it easy to pull data out of Drupal using REST APIs or GraphQL.

If you are only building one website with the platform and it is primarily for marketing your organization, a traditional Drupal build probably makes sense. The more systems you are integrating and the more channels you want to use the content in, the more sense it makes to build using a decoupled approach.

Considering the Requirements

The requirements are another important factor to consider. Requirements help us define the solution. Just as important as the requirements are how flexible the requirements are. Drupal provides lots of functionality out of the box. When you add the availability of more than 40,000 free community-contributed modules, Drupal can meet many requirements with very little effort.

As you define the requirements, you should compare them to what Drupal can do. And where there is a module that meets most, but not all, of the requirements, decide whether it is possible to change the requirements. The more Drupal satisfies the requirements that you would need to build yourself in a decoupled approach, the better the coupled Drupal approach makes sense. If you find that your requirements will require a lot of customization to Drupal, a progressively decoupled or even fully decoupled approach may make sense.

Considering the Budget and Timeline

Every project has budget and timeline constraints. If you are on a tight timeline (and budget), building a coupled Drupal platform is often a solid choice. Drupal provides so many out-of-the-box features that, with flexible requirements, you can build a website in a very short period of time. For instance, we were able to build a small Drupal site using Site Studio in just a few days. The more expansive your budget and timeline, the more options you have in approach.

The Versatility of Drupal

After you've done the analysis and come up with the best approach, understand that circumstances may change. And, regardless of the approach, because Drupal can handle any of the approaches in the spectrum, you can evolve your approach over time. Because Drupal has been built with an API-first approach, it allows you to change your approach from a coupled Drupal approach to a fully decoupled approach over time. 

Here at Bounteous, our website was originally built with a coupled approach. However, we recently decided to refresh the site. Drupal has allowed us to decouple parts of the site that make sense to decouple but keep the other parts coupled. As needs dictate, we can continue to decouple only the parts that we need to.  

Drupal is a versatile system that can be the centerpiece of your DXP. How you use it will depend on the factors above and others that you find important. Regardless of the approach you take, Drupal is versatile enough to change as your needs change in the future.

In the latest version of Site Studio, Acquia has introduced a game-changing feature that is sure to challenge Drupal Core's Layout Builder as the premier go-to tool for site builders. Site Studio already has a superb component building and editing experience, but now users can add and edit components live on the page.

In this post, we'll go in-depth on this new feature, plus other recent updates to Site Studio.

Visual Page Builder in Acquia Site Studio

On previous iterations of Site Studio, users could edit existing components on the page live via the Page Editor, but the components had to already exist in the layout canvas field. This operated in a similar fashion to other Drupal page builder elements such as panels, layout builder, paragraphs, etc., and only is accessible through contextual links. If a user wanted to add a brand new component to the page, they had to add it via the node edit form. But now, all of that changes.

While the layout canvas is still accessible via the node edit form, content editors can completely assemble a page from the front end, providing an entirely new meaning to the layout canvas field concept. Other than page creation or administrative settings, content editors may have little need to open the node edit form when adding page content. Of course, this all depends on how your site's content types have been architected. Here is a brief tour of the new page builder experience:

When a user is logged in and on a page that utilizes Site Studio and a layout canvas, they will see a new Page Builder button on the admin toolbar.

Enabling page builder mode will allow users to add, edit, move, delete, duplicate, and/or save as component content. Users can also save the entire page layout.

As great as this new experience is, it's also helpful to see consistency in how new components or elements can be added via the left side, off-canvas components drawer, making it seamless. Users don't have to re-learn how to add components, but rather get an improved page building experience.

The component editor itself also behaves the same way whether users are using the page editor, visual page builder, or the layout canvas on the node edit form.

The visual page builder is included as a new submodule within Site Studio and has to be enabled before it can be used.

Pro Tip: Developers should also be aware that anytime you update Site Studio, enable new submodules, and/or create or alter components, it's important that you run the import and rebuild functions. This can be done from the Site Studio UI or via Drush commands. For additional information on how the visual page builder works, visit Acquia's Site Studio documentation.

Site Studio's new visual page builder provides a whole new meaning to "what you see is what you get." The page building experience for content editors has never been better or easier, and this new feature alone should be enough to convince you to use Site Studio on your next project.

Other Site Studio Highlights

While the addition of the Visual Page Builder is kind of a game-changer for Site Studio, the latest release also includes some other smaller but no less important features, including some accessibility enhancements, rel attribute support, and more.

Sync Batch Limit Overrides

On previous builds of Site Studio, admins were limited to importing 10 configuration items at a time via Site Studio Sync to reduce the amount of memory required. Acquia has now exposed a method allowing admins to override the default setting. By adding the following to a Drupal settings file, you can increase the number of configuration items that process per import batch:

$settings['sync_max_entity'] = 20;

This is one of the few items of Site Studio that is controlled by a developer and must be updated in code. Users should also be aware that by increasing this value, more memory will be required and can lead to issues.

Rel Attribute Support

Acquia has also added support for the Rel attribute on the link element. This attribute defines the relationship between the linked resource and the current document. Previously, if users wanted to have Rel attribute options on links, they had to be added by a component builder. Now, when a link uses the type "URL" and the target is set to "New window," a group of checkboxes will automatically appear for the following options:

• nofollow - prevents backlink endorsement, so that search engines don't pass page rank to the linked resource.
• noopener - prevents linked resources from getting partial access to the linking page, something that is otherwise exploitable by malicious websites.
• noreferrer - similar to noopener (especially for older browsers), but also prevents the browser from sending the referring webpage's address.

The new Rel attribute can be found on the Link, container, slide item, and column elements. It should be noted for the SEO conscious, that the use of nofollow will stop search engines from passing page rank endorsements to the linked resource. This is often used in blog comments or forums, as these can be a source of spam or low-quality links.

Google and other search engines require nofollow to be added to sponsored links and advertisements. Additionally, the use of the No referrer toggle can affect analytics because it will report traffic as direct instead of as referred.

Nolink Token Support

One under-the-radar update from Acquia is the ability to use the token on Site Studio menu templates. For any experienced site builders, you probably know about the ability to use the token on menu links to render them as a heading, etc., and without a link attached. It's a great way to add sub-level menu headings.

On previous builds of Site Studio, users were unable to use the token as it would still render as an anchor tag with an empty href. In 6.5, using will result in the menu item rendering with a tag instead. Nothing needs to be done to start using the token, though, your menu styles may need to be updated to account for the usage of tags. Also to note, if a different HTML element has been specified in your Menu Template, that setting will take priority.

Accordion Accessibility Enhancements

Accessibility is a moving target. Keeping a site up-to-date with accessibility enhancements is one of the more important responsibilities we have and Site Studio is no exception.

In this version, Acquia has added some accessibility improvements to the Accordion element for the end-user. The header links will now have an aria-expanded attribute, which toggles between true and false when expanded and collapsed, respectively.

Accordion header links will now use aria-disabled="true" if the parent Accordion tabs container has the Collapsible setting toggled OFF. This is only applied when the item is expanded, to indicate to a screen reader that the panel cannot be collapsed manually.

When the panel is collapsed because a sibling accordion item is expanded, the aria-disabled attribute is removed. Accordion header links now have aria-disabled="true" permanently set if the accordion item has been disabled through Navigation link settings.

Bug Fixes and Other Improvements

The latest build of Site Studio also includes a bug fix that is related to sync package entity dependencies not being removed if they were no longer being used on the entity. Essentially, when a sync package contained entities that have had their dependencies updated, the sync package would contain both the original and the new dependency.

For example, if your component exists in a package, you then update that component's default image, both image files would be included in the sync package rather than just the latest one. Now the old dependencies should no longer appear in that sync package. This could also potentially reduce the size of sync packages in the case where multiple, deprecated dependencies were present.

Font Display Property Options

And last but not least, Acquia has now added a font-display property option to the Font library settings page. This CSS property, when used, will determine how a font face is displayed based on whether and when it is downloaded and ready to use. It is a very small feature update but a useful one; although, only developers really need to worry about implementing it.

Summary

As with any Drupal updates, it's recommended to fully test these new features and fixes (as applicable) on your site's development environment before deploying to production. You should also have a backup of any code or databases before upgrading. Version 6.5 of Site Studio is not backwards compatible.

With the addition of Visual Page Builder, Site Studio is just further cementing itself as an excellent component and page builder tool for Acquia-hosted Drupal applications. The more improvements they make, the harder it is to imagine building a site without it.

For additional information on Site Studio, check out some of our other posts:

If you're reading this, you may have already noticed that we've recently given Bounteous.com a fresh coat of paint. What might be less obvious is that we also took this redesign as an opportunity to slowly begin decoupling the front end of our existing Drupal site. We've considered decoupling in the past but were unable to justify the effort for a full-scale overhaul of our front end given other competing responsibilities. So what changed this time?

Our initial design concepts implied a phased approach. There were effectively only two pages that featured a completely new design and also incorporated a number of new behaviors and animations not present on the existing site. For this first phase, the rest of the site would get a mostly cosmetic overhaul, applying updated global styles to better match the new design introduced elsewhere on the site.

This put us at a similar crossroads. We believed that leveraging a JavaScript framework would greatly benefit our ability to achieve the motion-based interactions implied by our ambitious new designs. But for this phase, introducing a JavaScript framework wasn't really necessary for the rest of the site. In the short term, the cost of decoupling the entire site would greatly delay our ability to ship what was essentially just two new pages. This conclusion led us to a question that in hindsight seems pretty obvious:

Could we start by only decoupling two pages on our existing site?

Initially, we didn't know. But as we started considering this project with the assumption that we could make this change only for these two new pages, it became the difference between taking this step now or continuing to kick a large-scale change to our front-end architecture down the road to some undetermined date.

We eventually landed on an iterative approach to decoupling Bounteous' existing Drupal site with Gatsby; starting with only two pages, but laying the groundwork for any page on the site to be rendered primarily by either React or Twig. What follows is a look at how we did it, what we learned, and what we think this means for the future of our site.

Upcoming Event - DrupalCon North America

An Iterative Approach To Decoupling Your Existing Drupal Site With Gatsby

One Site, Multiple Front Ends

For our JavaScript framework, we selected React, which we were technically already using in some minor ways on the existing site. While it would be possible to do this with a different framework, we found that the large React ecosystem would greatly accelerate our ability to achieve some of the motion-based interactions implied by our new designs. We ended up using both Framer Motion and react-lottie extensively, and they saved us quite a bit of time and effort.

While we had already decided that we'd be building additional React components in support of this new design concept, we also decided that we'd specifically be using Gatsby as our React framework of choice. Gatsby's plugin ecosystem greatly simplified the process of sourcing data from our existing Drupal CMS. Gatsby also opened up the possibility of statically generating portions of our site, which Bounteous.com was well suited for, given that most of our content changes infrequently.

Compared to a client-side approach to decoupling, server-side pre-rendering can have both SEO and performance benefits. As an added bonus, having these pages pre-rendered separately from Drupal also made it easier for React developers to contribute without ever having to set up a local Drupal environment.

Settling on these initial conclusions provided us with the following high-level architecture:

Drupal would be the CMS backend powering content for all of the pages on the site; both traditional CMS rendered pages, and pages rendered statically by the Gatsby build process. In the middle would be what we referred to as our 'front end globals.' These globals would be consumed by each front end and included shared styles, variables that serve as design tokens, along with full React components.

This structure allows us to take a progressive approach to introduce static content to our site. Initially, we'd only be building a small number of pages statically, but as we prove that this workflow can suit our site and our team, we could gradually shift where the line exists between the pre-built and dynamically built portions of our site.

Or alternatively, if we found that this approach didn't meet our needs, we could shift back to having Drupal render the content given that all of the data already exists in the CMS.

Front End Structure

After some consideration, we decided to take a monorepo style approach and have Gatsby, Drupal, and our front-end globals live in a single repository. Since this was a single domain and we had no concrete plans to distribute these components beyond Bounteous.com, we decided that a simplified repository would help streamline the process as we worked toward a tight timeline.

From the front-end perspective, this resulted in three main top-level directories in the repository: /fe-global, /drupal, and /gatsby. For this phase of the project, /fe-global exclusively contained Sass partials containing design tokens and global styles. Drupal and Gatsby would each selectively import from these partials as needed.

On the React side, we initially focused on building functional components with as little internal state as possible. This allowed us to prototype in the browser early, and also would allow us to provide data to these components from various contexts.

Regardless of if the data was being sourced from Gatsby's GraphQL API, directly from Drupal, or even hardcoded, the same component could be used. This also allowed us to use Storybook heavily during this phase of the project in order to get early feedback on these components before data was fully integrated.

On the Drupal side of things, we created new content types for each of our decoupled page templates. We also continued to use paragraphs to represent our components as we had been doing for existing content on the site.

The structure of data from the Paragraphs module initially doesn't seem like a natural fit for decoupled Drupal projects, but with gatsby-source-drupal and a few small utilities (which we'll talk about later), we found this data to be reasonable to deal with. In fact, it ended up giving us a high level of layout control, down to the ability to reorder components on the resulting static pages.

Considering that the majority of our content was still being rendered by Drupal, we still had our traditional Drupal theme. This theme incorporated the partials and tokens from our front-end globals alongside Drupal-specific styles, templates, and JavaScript.

Serving a Subset of Decoupled Pages

One of the very first things we had to prove out to ensure that this approach was feasible was serving a combination of static routes (pre-rendered by Gatsby) alongside dynamic routes handled by Drupal.

As part of our Gatsby build process, we are copying the 'public' directory which represents Gatsby's build asset, into the document root for our Drupal site. For the initial phase of this project, we were able to use a couple of very specific .htaccess rules to serve our two new static routes.

We knew this solution wouldn't scale long term as we introduced more content to our site. Ideally, we'd want to be able to create Decoupled content within Drupal, specify a path alias, and automatically have that route handled statically. We eventually found that we could achieve this via .htaccess as well.

Our rules take advantage of Drupal's URLs not having a "file" component to them. When we call createPages in gatsby-node.js with an alias like /services, gatsby creates that route as /services/index.html. The main .htaccess rule checks if /public//index.html exists and rewrites if it does.

This essentially means that for any request the Gatsby route 'wins' if there is a related file in the 'public' directory (/public/my-alias/index.html, for example,) and all other requests fall back to being handled by Drupal. This has the extra advantage of bypassing Drupal's bootstrap process for all of our static routes.

As focus shifted over to data integration, some adjustments were also necessary to configure the gatsby-source-drupal plugin to meet our needs. The gatsby-source-drupal plugin pulls data from Drupal's JSON:API endpoints and makes this data available to React components via Gatsby's GraphQL API. By default, the plugin imports all data from the source Drupal site. Since for this initial phase Gatsby would only be used to build a small subset of pages, most of this data was unnecessary and also would have the side effect of greatly increasing our build times.

As an initial attempt to solve this problem, we used Drupal's JSON:API Extras module to only expose the resources that our Gatsby build needed to depend on. This helped, but we still eventually needed to enable the file resource, which pretty much immediately sunk our build times.

Gatsby was now importing (and worse yet processing) local versions of years worth of images that we didn't need to support our new content. We eventually found that it was possible to configure gatsby-source-drupal to only import the files referenced by content that was necessary for our builds, but it required a combination of configuration options that wasn't completely obvious from the documentation.

The first step was to add the file resource as a disallowed link type:

// In your gatsby-config.js
module.exports = {
  plugins: [
    {
      resolve: 'gatsby-source-drupal',
      options: {
        baseUrl: ,
        // Disallow the full files endpoint
        disallowedLinkTypes: ['self', 'describedby', 'file--file'],
      },
    },
  ],
}

This alone would result in all files being ignored by the plugin. A little bit further on in the disallowed link types documentation is the following note:

When using includes in your JSON:API calls the included data will automatically become available to query, even if the link types are skipped using disallowedLinkTypes. This enables you to fetch only the data you need at build time, instead of all data of a certain entity type or bundle.

This essentially allows us to re-include specific files if they are referenced by other content. What makes this feature potentially easy to miss is the fact that it uses the plugin's filter option, which typically further restricts the data sourced from the plugin. The resulting configuration ended up looking like this:

// In your gatsby-config.js
module.exports = {
  plugins: [
    {
      resolve: 'gatsby-source-drupal',
      options: {
        baseUrl: ,
        /// Disallow the full files endpoint
        disallowedLinkTypes: ['self', 'describedby', 'file--file'],
        filters: {
          // Use includes so only the files associated with our decoupled content
          // types are included.
          "paragraph--dhp_hero": "include=field_dhp_fg_img",
          "paragraph--dhp_animation_cards": "include=field_dhpac_images",
          "paragraph--featured_post": "include=field_dfp_bg_img",
        },
      },
    },
  ],
}

With this configuration, if a featured post paragraph is used on the homepage, any associated background images (field_dfp_bg_img) will be sourced by Gatsby as well.

Providing Drupal Data to Our React Components

So at this point, we have access to all of the necessary data, and also a set of functional components that aren't yet aware of Drupal's data. We also have content types that can use a number of different paragraph types, in any order. This is great from the perspective of layout flexibility, but less predictable from a data integration standpoint.

To help manage this mapping we created a custom React utility called paragraphsToComponents. Assuming that we have an existing GraphQL query that provides paragraph data to our template component, we could use it like this:

const HomePage = ({ data }) => {
  const paragraphs =
    data.nodeDecoupledHomePage.relationships.field_dhp_components

  const paragraphComponents = useParagraphsToComponents(paragraphs)

  return (
      
      {paragraphComponents.map((paragraph, index) => {
          return (
            

              {paragraph.provider({
                paragraph: paragraph,
                index: index,
              })}
            
          )
        })}
      
  )
}

As we'll see in a second, the utility returns an array of components that can be used to render the related paragraph data. In the template component's render method we iterate through this array and render these paragraphs in order. This allows us to correctly process paragraph data in any order, with little heavy lifting or redundant code in our template components.

The utility itself is defined as follows:

import AboutUsBannerProvider from "../components/paragraphs/provider/AboutUsBannerProvider"
import AnimationProvider from "../components/paragraphs/provider/AnimationProvider"
import CalloutProvider from "../components/paragraphs/provider/CalloutProvider"
// … Additional component imports ...

// The paragraphs above map to these components:
const componentMap = {
  dhp_about_us_banner: AboutUsBannerProvider,
  dhp_animation_cards: AnimationProvider,
  dhp_callout: CalloutProvider,
  // … Additional component mappings ...
}

const paragraphsToComponents = paragraphs => {
  // Create a new array with paragraph data that also specifies the React component
  // we'll use to render it.
  const mappedParagraphs = paragraphs
    // Add a component key that defines the component using the following
    // naming convention: ParagraphTypeProvider
    .map(paragraph => {
      const componentType = paragraph.__typename.replace("paragraph__", "")
      paragraph.provider = componentMap[componentType]
      return paragraph
    })
    // Filter out paragraph types we don't yet have a mapped component for.
    .filter(paragraph => {
      return paragraph.provider !== undefined
    })
  return mappedParagraphs
}

export default paragraphsToComponents

This assumes a particular naming convention for our components: ParagraphTypeProvider where 'ParagragraphType' matches the Paragraph Type name from Drupal.

As you can see in the example below, our Provider components only have one responsibility: providing the appropriate data from Drupal to our functional components.

import React from "react"

import Callout from "../../components/Callout/Callout"
import HeadlineDivider from "../../components/HeadlineDivider/HeadlineDivider"
import { graphql } from "gatsby"

const CalloutProvider = ({ paragraph }) => {
  const heading = paragraph?.field_dhpc_heading?.processed
  const body = paragraph?.field_dhpc_copy?.processed
  const backgroundOption = paragraph.field_dhpc_bg_opts

  if (backgroundOption === "background__waves") {
    return 
  } else {
    return 
  }
}

export default CalloutProvider

export const CalloutFragment = graphql'
  fragment CalloutFragment on paragraph__dhp_callout {
    id
    field_dhpc_bg_opts
    field_dhpc_callout_size
    field_dhpc_copy {
      processed
    }
    field_dhpc_heading {
      processed
    }
  }
'

We're also defining a GraphQL fragment for the data that is required for this component. This gives us a consistent definition of the necessary Callout Paragraph data that can be imported into any other component that needs it.

Getting to this point took a decent amount of time and effort, but once defined it became much easier to integrate future Paragraphs from Drupal by following this pattern.

Shared React Components

There also was an integration problem to solve going from React to Drupal. We needed to syndicate the same header and footer component used by Gatsby to our Drupal pages so that we could provide a consistent look and feel throughout the site, regardless of which front-end technology owned rendering that page. Thankfully, by ensuring that our React components were strictly presentational we were well suited to use these components in a different context.

We approached this by creating an "exports" subdirectory alongside the rest of our React components which contained an exportable version of the header and footer. These essentially functioned as provider components just as we saw with our Gatsby data integration. Initially, these exported components used pre-defined data since they didn't have access to Gatsby's GraphQL API. However, we eventually found a solution to export these components using the same data that is available to our Gatsby build.

As a first step, we created a separate Webpack configuration that used these two components as entry points, and placed the related bundles into a 'dist' directory in the Drupal theme.

On the Drupal side, we used the Component module to help ease this integration. As a simplified successor to the progressively decoupled blocks module, Component allows you to define configuration in a .yml file alongside your JavaScript in order to expose your component to Drupal. In the case of our navigation, we defined the following configuration:

name: Evolution Navbar
description: 'Evolution Navbar'
type: 'block'
js:
  'dist/navbar.bundle.js' : {}
  'dist/vendors~navbar.bundle.js': {}
dependencies:
  - bounteous/react
template: 'evolutionnavbar.html'
form_configuration:
  theme:
    type: select
    title: "Theme"
    options:
      '': 'Dark Theme'
      'theme-light': 'Light Theme'
    default_value: ''

Alongside the following template:

This manages to do quite a lot with a little. Based on this configuration, a new block will be created that uses our evolutionnavbar.html template and loads our component JavaScript and any dependencies as a library. It also exposes a configuration form which in this case allows you to specify a light or dark theme to be used when rendering the component. The values of any form configuration will be added to the template as data attributes, in this case making 'data-theme' available to our component.

With that in place, the code for the navbar React component that we'll be exporting is as follows:

import React from "react"
import ReactDOM from "react-dom"

import { MediaContextProvider } from "../../components/layouts/Media/Media"
import abstracts from "styles/abstracts.scss"

// Grab cached data from disk.
import NavigationProvider from "../../components/provider/menu/NavigationProvider"
import templateData from "../../../public/page-data/template/page-data.json"

const queryHash = templateData.staticQueryHashes[1]
const data = require('../../../public/page-data/sq/d/${queryHash}.json')

const drupalProvider = document.querySelector(".evolutionnavbar")
const config = drupalProvider.dataset

ReactDOM.render(
  ,
  document.getElementById("evolution-navbar")
)

First, we're importing cached menu data from our Gatsby build. This was inspired by the approach outlined in Exporting an embeddable React component from a Gatsby app using Webpack. Sourcing this from a cache using a query hash seems…fragile, but it has been reliable for our needs thus far. This assumes that the Gatsby build runs prior to the Drupal build, which already happened to be the case in this project.

Next, we're selecting the wrapping div in the DOM in order to access all of the data attributes provided by our Drupal block. This allows us to pass the theme option set in the instance of this block as a prop to our navigation component.

Finally, we mount the component into #evolution-navbar which is used in the template that was specified in our block configuration.

This approach could add some overhead as the number of components you're working with increases, but works nicely for our header and footer. It also allows us to easily configure different instances of the component block to be used on different sections of the site. We use this to swap between the dark and light themes of the header, and even specify if the form in our footer should be expanded or collapsed by default.

Looking Ahead

While we're happy with the progress made with this initial release, there is intentionally more evolution to come. We've been working on improving the content editing and deployment process introduced by this new workflow. These changes include configuring Gatsby live preview, and also making enhancements to the build hooks module to allow our content team to trigger Gatsby builds on demand.

As we've continued incorporating more content into our Gatsby build process, we've also run into some pain and confusion around the seemingly arbitrary divide between our React and Twig components. In addition to working to make this distinction clearer to our team, we've also been experimenting with solutions that allow our React and Twig components to be used side by side in more contexts, including syndicating markup and styles from Drupal to be used in Gatsby content as needed.

So far we think this iterative approach can be of benefit to others looking to transition the front end of their existing Drupal platform without requiring the commitment of a large-scale re-architecture.

Taking an iterative approach can instead make it possible to prove that decoupling has clear value and also ensure that changes to the development, content editing, and deployment process fit the needs of your team. We're excited to continue evolving Bounteous.com and hope that you'll follow along.

For even more on this topic, check out Episode #284 of the Talking Drupal Podcast - Iterative Approach to Decoupling and An Iterative Approach To Decoupling Your Existing Drupal Site With Gatsby at DrupalCon North America.

With so many products and services available these days to assist with your website needs, it can be difficult to navigate all the options and determine the right solution for your business.

At Bounteous, we do a lot of work with Drupal and Acquia products and services. Over the past year, we've spent considerable time working with Site Studio, developing training materials for clients, creating resources, and working through various projects. Let us give you a brief tour of Site Studio and why it's perfect for your next project.

What Is Site Studio?

Site Studio, formerly known as Cohesion, is a Drupal product from Acquia that makes it easy to build a component-based website. Site Studio transfers the Front-End theming layer to the UI and gives content editors and marketing managers more control than ever over their sites. It provides a new site-building paradigm that's far more efficient than traditional builds.

The tools and features that come with Site Studio provide an excellent base to start with that allows client-side developers to contribute to a build from Day One. The low-code nature of Site Studio shields content editors from the Drupal backend and allows developers to focus on the overall content editing experience they're creating. It also provides your development team the ability to create elegant, performant, more powerful sites in half the time.

Let's break down the top points that contribute to the above philosophy.

Low-Code

Site Studio is designed to be low-code. This can mean a lot of things for different systems; however, in the context of Drupal, this is an important point to highlight.

Drupal inherently has its own hooks and other functions in place that make it a very powerful but also customizable CMS. However, to be able to use these ideas and functions correctly requires some prowess that a developer who has never touched a Drupal site will most likely not possess.

This is where the low-code nature of Site Studio really shines. New developers do not need to learn hooks, template suggestions, or any of the other Drupalisms that you will find on most sites. By layering Site Studio on top of Drupal, we now have a mechanism that takes care of the heavy lifting that we as developers use to write in custom functions. Site Studio may be low-code, but it is certainly not low on features.

Easily Extendable

Site Studio comes with a myriad of predefined components and styles thanks to the DX8 UI Kit. After initial setup, developers are immediately given access to over 50 different components consisting of sliders, cards, accordions, and more. While this is all great to have at the start of site-building, Site Studio takes it one step further.

Every single component that comes with Site Studio is extendable. Not only does this allow developers without previous Drupal experience to build rich editing experiences—but it also gives a noticeable jump start to most any component the developer is tasked to build.

Need to build a slider but the existing component is missing a field you need? No problem! Extend the existing slider and add your field. All of which takes minutes and no custom code to be written. Site Studio has a ton to offer out-of-the-box, but there is far more you can do with it.

Staying True to Drupal

There's an important synergy to highlight here. Site Studio comes with wonderful and easy-to-use features right out-of-the-box, which is one of the main draws to using it on any project. But at the end of the day, Site Studio is using Drupal as its backend—and we as developers need to be sure things are done correctly and the overall health of the application is kept at the forefront.

The beauty of Site Studio is how it uses features of Drupal developers love and simply extends them rather than rewriting them. By using these strengths that come with Drupal, there's essentially no more complexity in debugging, testing, or deploying sites that use Site Studio. This translates into a developing experience that all developers, both experienced and novice alike, can use together.

Starting With the Backbones of Site Studio

Composer, configuration management, and local environment: these are things a Site Studio implementation will not shake up too much from the stock Drupal setup we already know.

When getting a client resource up to speed, it's important to make sure that these fundamentals are understood and configured correctly from the beginning to ensure the developer is set up to succeed. Let's break down each of these points.

Site Studio - Composer

Composer is still behind the scenes managing all packages and modules just like a stock Drupal site. The only difference here is the inclusion of acquia/cohesion in the composer.json file.

However, for a developer working with Drupal and Composer for the first time, it can be a bit daunting to make a change to the project. The understanding of Composer's inner workings and how it relates to a Site Studio and Drupal implementation is crucial for any developer to contribute to a Site Studio project.

Site Studio - Local Environment

Again, no real changes here when developing with Site Studio. Something we have found that can greatly benefit any developer, whether it be internal or client-side, is to choose a single virtual environment scheme for all Site Studio implementations. Once a standardized system has been sanctioned, you can build custom tooling for said system.

This is a massive save when it comes to time constraints and debug headaches. When using Site Studio, there is a Drush command that updates all Site Studio templates and components. Manually running this one command may seem trivial on the surface—but when added to our automated tools for resetting a local environment, it proved to be one of those little things that was worth more than its weight in code.

Site Studio - Configuration Management

With Site Studio, this is probably the biggest change you will first notice. Just about every setting, component, and template in Site Studio is tracked in configuration. While this is a wonderful part of Drupal 8 that Site Studio utilizes well, it can get a bit confusing when trying to decipher exactly what these YAML files are doing when it comes to a pull request and working alongside other developers.

The best way to handle these config files is to pull down the branch of the pull request and import the config to be sure that everything is showing as expected and there are no errors on import.

What's New in Site Studio

Like with any Drupal Module, continuous development and improvements are essential in keeping your module relevant and in use. Since we first got our hands on Site Studio in early 2020, we've seen a ton of improvements. We started with version 5.7.9 and are now working with version 6.4.0. The following are some of the improvement highlights.

Component Field Repeaters

In version 6.3, Acquia added the Component field repeater feature to Site Studio. This is one of the most essential and important features added to date. Previously, repeater patterns were only available via the Site Studio Views Template builder. Think of this like a For Each loop, a control flow statement for traversing items in a collection.

Without the ability to repeat field items in components (a feature that is common in Drupal Site Building), we had to create a parent/child component relationship using dropzones. This method was okay and got the job done, but there were some limitations with the accordion components. Some of the issues with using this approach were that we could not limit which components could be added to a dropzone nor could we save a component as component content (more on that later).

The only other option was to create components with limited cardinality or item limits. That's okay in some cases, but when considering an accordion component or a carousel, users usually want unlimited. But now with field repeaters, that can be done directly on the component, making Site Studio even more powerful than before.

For example, to build a component using Site Studio's accordion elements, you no longer need to rely on the drop zone and separate components. Users can set a field repeater on the accordion item and repeat as needed. This simplifies the component building experience, making it even more intuitive.

Component Content Improvements

In the newest version of 6.4, Acquia adds two major improvements to component content. For those not familiar, component content is a saved component created on a page that allows users to reuse it on multiple pages but have a singular point of entry in order to update.

Previously, component content could only be created via a layout canvas field and saved from there. This is fine for instances where you create a component that you decide to reuse after the fact, but what about a component that you'd like to go through an approval process before it ever ends up on a page? Now, component content can be created directly from the list of component content which now matches a more standard entity behavior.

In addition to being able to save component content from the Component Content Manager, you can also now save components as component content when using a dropzone element. Previously, components using the dropzone element could not be saved as component content, thus limiting what you could actually save. This was challenging to deal with since, in order to create the effect of a repeating field, we had to rely on dropzones beyond their original intended scope. Now, any component can be saved as component content.

There are plenty of other improvements and fixes. It's clear that Acquia is committed to continuously improving Site Studio, and we would expect nothing less.

Why You Need It for Your Next Project

Creating Drupal websites with Site Studio has never been easier for the content editor or the developer. No matter their experience, anyone can contribute to a Site Studio project. With all the feature-rich aspects that are available today, as well as the ones to come in future updates, we can all see why Site Studio is an important shift into modern application and website development.

Gone are the days when there are hard lines in the sand between content editor and developer. Site Studio is a welcomed tool because it echoes the same mantra that Drupal and the community have had since its inception: let's build something together.

Want to learn more about Site Studio and what it can provide for your client solutions? Check out our article that takes a closer look at Site Studio as well as how we built a site in 10 days.

PHPStorm is one of our favorite Integrated Development Environments (IDE) for building Drupal sites. In addition to its outstanding ability to help any PHP developer's productivity, it offers several Drupal-specific time-saving tools—like the ability to handle code completion for hook declarations and applying Drupal coding standards.

Among the many tabs that border the PHPStorm IDE window is one that offers access to one of the hardest-working components of the Drupal ecosystem...the database!

Many developers only interface with the database via Drush commands, performing database backups, or moving content from the server to their local machine. Given the Drupal database is where all content and active configuration are stored, developers should feel comfortable leveraging the database as a research and diagnostic tool when developing solutions or debugging problems. The database can provide insight into how your data is flowing throughout the system, which can help when debugging errors or when working with a new module that modifies data before saving.

In this guide, we'll show you how to connect to your local Lando environment’s Drupal database from within PHPStorm. If you’re using another local environment like DrupalVM or DDEV, you can use the following steps as a guide for how you can connect these other environments.

Obligatory warning: After you connect to the database, you'll have access to modify or delete data, tables, or the entire database. Be sure you’re not working directly with a live/production database! We suggest using the database tool on a local copy of the database that can be restored if needed.

Step 1 - Allow Lando to Receive Incoming Database Connections

By default, Lando does not allow anything but the Lando app to connect to the database server, so we need to tell Lando that it’s OK for PHPStorm to connect. In the Lando configuration file (either the project-wide .lando.yml, or in the local overrides .lando.local.yml), add the following lines:

services:
  database:
    portforward: 3307

When added to a basic .lando.yml recipe, the file will look like this:

This allows port forwarding on port 3307 to the host 'database', which is the default name of the database container in the drupal8 / drupal9 recipe in Lando. If your database hostname is different, update as needed.

Finally, for this step, rebuild the Lando environment with lando rebuild --yes.

Step 2 - Connect the Database in PHPStorm

Now that Lando has been rebuilt and is running, we can connect PHPStorm to the Drupal database. If it’s not already open, click the database tab to open the database pane.

In the database pane, click the + sign to add a new data source, select MySQL (or MariaDB).

In the new window that opens, enter the server information and credentials to connect:

Since we’re using the default values that come with the Lando drupal8 recipe, we’ve entered:

• Name - a name you want to call this in configuration
• Host - defaults to localhost, you should be able to leave it as is
• Port - 3307 (or the port you assigned in .lando.yml)
• User - drupal8 (or the database username you assigned)
• Password - drupal8 (or the password you assigned)
• Database - drupal8 (or the database name you assigned)

When you click "Test Connection" you should see a green checkmark to verify that it connected successfully.

So, now what?

Step 3 - Use the Database!

The database pane should show you a tree of the database tables in your Drupal database. When you connect to the database, a console tab will open up in the main editor window. You can also browse the data in a table by double-clicking on the table name in the database tab. In the image below, we’ve opened the table block_content and have the data as a table in the main editor window.

Why Use this Database Tool Over Others

The database tool within PHPStorm has most of the features of JetBrains’s DataGrip IDE. There are too many features to cover, but here are three of our favorites:

Feature 1 - Viewing the Data in a Table

This seems pretty mundane, but scanning through data tables can help you visually pick up patterns about your data. The column headers allow you to sort by one or more columns to help you review the data in the table. You can also drag to rearrange the columns to make viewing the data easier for your task.

Feature 2 - Finding Data in a Table

When you need to find a specific string in a table, you can write a query by hand or you could use some of the built-in tools to make finding the string much easier. When you’re viewing a table, you can search all rows and columns by simply pressing Cmd+F or Ctrl+F. A magical search form will appear:

As you start typing, data cells with your search string will be highlighted. You can also check the "Filter rows" box to only show the rows that have your search string in them:

There are also options to search with case-sensitivity or with regular expressions, which can help you find all of the data that you’re looking for.

Feature 3 - Finding Data ANYWHERE!

This is a great tool to use when you know what you're looking for, but you aren’t sure where to find it. You no longer have to navigate a huge haystack of the SQL export text file to look for your needle!

In the database tab, right-click on the drupal8 database and pick "Full-Text Search...":

In the new window that opens, you can enter your search term and press Search:

PHPStorm will open the "Find" tab and show you how many matches were found in the tables of your database:

Delivering Great Digital Platforms

PHPStorm is a true workhorse of Drupal development. It allows talented people to be more productive in their efforts to create amazing features for Drupal and awesome digital experiences for users. The built-in suite of tools for PHPStorm—especially the database tools—makes this IDE my favorite when it comes to delivering great digital platforms for our clients at Bounteous.