Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Jul 12 2023
Jul 12

Drupal's Webform module is great. It allows users to create forms with all sorts of field types through a UI that's easy to use. It's a great friend to marketers. We use it to power our contact form, collect webinar registrations, and as a lead capture for ebooks.

But data trapped in Drupal doesn't do much good. Data needs to move and flow. It needs to be exported and imported and analyzed and followed up with. It needs to be used.

You can view Webform results on your Drupal website and export them in various formats, such as a CSV or tab-delimited file. But depending on the number of your forms and what you want to do, that could be time-consuming. You can automate it with custom plugins and modules, but that takes development time, and anything you do will need to be maintained to keep up with API changes.

But there is a way to automate the exporting of your Webform data and the sending of it to other services and with zero code. Any marketer can do it. We've been using it to streamline some of our processes.

The Webform plugin that makes this possible

You don't need any extra modules to get this to work. First, go to the Settings→Emails/Handlers of a Webform. Click on Add handler.

Find Remote Post and add the handler.

Give it a good title. Since we'll be sending results to Zapier, we'll call ours "Zapier." The key field to focus on is Completed URL. You can do other things, but we'll keep this as simple as possible while still being useful.

Next, we need to go to Zapier.

Getting the data into Zapier

You can use Zapier for free for many things. However, for what we want to do, you'll need a paid account because it requires a premium feature. You can usually get a free trial of the premium features to see if it works for you.

Zapier lets you create automations called Zaps, which have Triggers that will make them run certain Actions. A single Trigger can have multiple actions attached to it.

First, we'll create a Zap and choose a Webhook for our Trigger. Choose the Catch Hook event as shown below.

Next, you'll have the option of entering a Child Key. We will ignore this because we don't need it and have a simple form we want to catch. You might want to use this if you only want access to a subset of the data from a very large or complicated form.

After you click Continue, Zapier will give you the webhook URL and ask for a test. This is the URL you will put in the Completed URL field of your Webform.

After you put the webhook URL in your Webform handler, a new field labeled Completed custom data will appear. You can use this to send Zapier hardcoded data or pass along data from tokens. Why would you want to do this? Maybe you want to use the same Zap for multiple Webforms and use this to pass the webform name or a tag you want to attach to a CRM entry. For now, we're going to ignore it and keep things simple.

Save your handler and then visit your WWebform on your Drupal website. Fill it out and submit it with test data. Go back to Zapier and press the Test trigger button. You should see your test data on the screen, and if everything looks good, click Continue with selected record. You'll use this data to help set up your actions.

What do you want to do with your Webform data? For us, we send it straight to our CRM as a lead. Sometimes we add it to a Google Spreadsheet. Maybe you want to automatically add a reminder to your calendar to follow up with this person. Or maybe all three at the same time. If/then blocks are available in Zapier, so you can check if the newsletter value is "1" and send it to the appropriate newsletter list. This is especially useful if your email marketing provider doesn't have a Drupal Webform plugin.

You still have your data inside Drupal if you need it, but now it's doing more work for you.

Go forth and make your life easier

We won't cover setting up specific actions because there are thousands of them, and Zapier already has excellent documentation. Now that the data has reached Zapier, you are free to do anything you want, and you haven't written any code. Most of the major CRM providers have Zapier integrations. Look for what you want to do on their website.

But don't feel like you have to be locked into Zapier. Other platforms aim to do what Zapier does, like Make and IFTTT. Test things out. Play around.

If you have your own workflows and automations that have made your life easier, we'd love to hear about them. Feel free to reach out on Twitter or LinkedIn.

Jan 04 2023
Jan 04

Microsites can be a useful tool. If you need sections of your website to look different from the main theme, or you have an initiative that needs greater emphasis, or you want a content team to have more control over a specific group of content, then implementing microsites can be a good solution. 

What's the best way to implement them? And how do you know you need a microsite versus a new website altogether?

Let's start with a definition.

What are microsites?

A microsite can mean many things. At the highest level, a microsite is a section of a larger website that

  • lives on the same domain but has enough content to be considered a website if it lived on its own
  • has its own defined mission to justify its existence even if the parent website didn't exist
  • has the ability to define its own look and feel while still maintaining a clear association with its parent website

Universities and state governments might have each department as a microsite. A television network might give its most successful shows its own microsites. Many organizations naturally need microsites to help them manage, communicate, and organize information.

This can be accomplished in many ways. Given example.com/foo/bar, bar might be a folder that is an entirely different website or platform than what lives at example.com. Or it might live on a subdomain like bar.example.com. You can do this with Drupal, where each department is a complete Drupal instance. This can work well. You just need to put in the administrative elbow grease to manage and maintain all of those instances. Spinning up a new site usually requires IT and developer support. And unless you have a single sign-on solution, you'll need to manage different user accounts for each website.

For the purposes of this article, we will be dealing with microsites that all live in the same instance of Drupal. One Drupal website but many potential microsites.

How do we accomplish this?

Ways to change the look and feel

There are a few ways to change the look and feel of a section of a Drupal site, and each provides varying levels of flexibility and control.

Swap the theme based on specific criteria

Using a ThemeNegotiator, you can determine the active theme of a page based on whatever criteria you want. A class that extends ThemeNegotiatorInterface should have at least two methods:

  1. determineActiveTheme() - this returns the machine name of a theme
  2. applies() - this returns TRUE if the theme from determineActiveTheme should be used in the current context

You can use whatever criteria you want in the applies() method. Maybe you base it on the route or some property on a content type or the content type itself. For example, this service declaration of a custom ThemeNegotiator passes in an entityTypeManager, which will let us load the node data of the current page inside the applies() method.

example.theme.negotiator:
  class: '\Drupal\example_module\Theme\ExampleThemeNegotiator'
  arguments: ['@theme_handler', '@entity_type.manager']
  tags:
    - { name: theme_negotiator}

If you want to set this from the UI, you can use the Theme Switcher module to define some basic rules to control when a theme is shown. You still need to create and customize the theme, however.

With a new theme comes a different set of theme settings and block layouts and templates. This is the most flexible option but requires new custom code for every microsite. It makes sense if you have a predefined number of microsites.

Use the same theme but add classes or libraries based on context

If you don't want the overhead of different themes or your look and feel to keep the same structure as the main theme, adding contextual classes and/or libraries is a good option. 

For one project, we determined distinctive sections based on the path of a node. We had code that determined what section a page belonged to and passed that to the front end via preprocessing.

$variables['is_blog'] = \Drupal::service('example.path_matcher')->isBlogPage();

if ($variables['is_blog']) {
  $variables['page']['#attached']['library'][] = 'example/blog';
}

Like switching themes, this option also makes the most sense if you have a pre-defined number of microsites and don't expect to add more since it requires custom code for each one.

Have fields on the content itself control the look and feel

A content type can have fields that control its look and feel. Change colors, upload a logo, have unique menus and link lists, different layouts, fonts, and more. Changes are made in preprocessing based on the field values.

Be careful when offering unlimited options. Letting users create arbitrary layouts and color combinations can create chaos. You'll get layouts that look like they were thrown together by a toddler and color palettes that force people to look away in pity and disgust. Know your users. Know their needs and expectations.

You'll also want the best UX possible, with clear help text and guardrails to prevent a microsite from going rogue. Here are some patterns we have used in the past with Drupal.

This is an example of a color palette selector that allows any color to be picked but checks for accessibility. It also has sensible defaults to select if users don't want to get too granular.

Here is a font selector.

You can also let users control the layout for certain areas.

This option requires more developer effort upfront but puts more power into the hands of users. Once set up, any editor with proper permissions can create a new microsite without asking a developer for help. Only adding new predefined options will require the deployment of new code.

Content under a microsite

A microsite with only one page is called a landing page. We want to maintain the emphasis on the word site, which means we need a way to have additional content on our microsites. This is only a problem to solve for the third option above, where users can create microsites on their own. The system's criteria for switching the theme or adding additional classes can cascade to other pages. 

For example, if the blog is a microsite, then the criteria might be anything that matches the URL pattern of example.com/blog/*. That makes it easy enough for users to add content to the microsite. Just make sure the URL matches.

But for microsites controlled by the content itself, there is no established pattern or criteria. Users need a way to associate content with a microsite. Like anything else with Drupal, there are many ways to accomplish this. The simplest way is to have an entity reference field on content types that can be part of microsites. This field points to the parent microsite content. The Entity Reference Hierarchy module might also fit your needs.

A microsite implementation example

Let's take the example of a company with an extensive suite of products, and this company wants each product to have a hub on the website with its own unique look but remain within overall brand guidelines. They want to provide editors with flexibility but also with obvious guardrails. Throughout this example, we will refer to a product named Widget Prime. These are the content types and fields that might be implemented.

Product Home Page content type

This will be the main hub of a product and contain all the information that will cascade to other pages. 

Fields:

  • Submenu - a list of links
  • Layout - a dropdown list of predefined layout options.
  • Color Palette - a radio selection of predefined color palettes
  • Overview - a text field for a basic introduction on the product home page
  • Sidebar - a multivalue block field to reference blocks if the selected layout has a sidebar

Content for Product Home Pages

For our example, we'll have two content types that can be tied to a microsite: Blog posts and Videos. Each has an entity reference field named Product for selecting a Product Home Page node.

Bringing it all together

Based on the entity reference field, we can create a way to aggregate the most recent blog posts and display these in sections on the microsite home page. This can be done with an embedded View, or we can write a custom EntityQuery and inject the results into the template. This code collects all the blog posts for a product and inserts them into a variable called "feed" that will be available to templates.

/**
 * Implements hook_entity_view().
 */
function widget_prime_entity_view(array &$build, EntityInterface $entity, EntityViewDisplayInterface $display, $view_mode) {
  if ($entity->bundle() !== 'product') {
    return;
  }
  $query = \Drupal::entityTypeManager()->getStorage('node')->getQuery();
  $query->condition('type', 'blog')
    ->condition('status', NodeInterface::PUBLISHED)
    ->condition('field_product', $entity->id())
    ->range(0, 10)
    ->sort('created', 'DESC');
  $build['feed'] = [
    '#cache' => [
      'tags' => 'node_list',
    ],
  ];
  if ($blog_posts = $query->execute()) {
    $view_builder = \Drupal::entityTypeManager()->getViewBuilder('node');
    $build['feed'] = array_map(
      function (NodeInterface $blog_post) use ($view_builder) {
        return $view_builder->view($blog_post, 'teaser');
      },
      $blog_posts
    );
  }
}

For blog posts and video child content, we'll load the referenced Product Home Page node to grab the submenu, color palette, and sidebar values so they can be inherited. We recommend creating a service, or series of services, that can be queried to get this information during preprocessing. This unifies the microsite and keeps things consistent.

Keep in mind that this is just one example, and there are many other options. You could have a Hero field or a Logo field. You could have additional fields for promo items. You could also get fancy with permissions and have certain roles only be able to edit certain microsites and their child content. What you offer or what limitations you introduce will depend upon your unique needs and your team.

Some warnings when implementing microsites

Microsites can be addicting. If you implement them right, the flexibility and ease of use you give to your editors can give them a rush of empowerment that could go straight to their heads. And since it is better to give than to receive, you'll want to keep orchestrating these successes for others, desiring to give them more and more.

But temper this enthusiasm with some warnings and cold, hard reason.

Content associated with more than one microsite

Beware of the temptation that may come from stakeholders to have a single piece of content appear on more than one microsite, depending on the context. This gets complicated quickly and doesn't work as well as imagined. 

Which menu and theme should you display? Which content is the true parent? You can solve some of this contextually based on where a user clicks from, but that's a lot of potential work for minimal payoff. And what if a user shares a blog post on social media? You would need to pass around the microsite info in the URL or something equally cumbersome.

Relying on path matching means support requests

If you're relying on path matching to define your microsites and relying on your editors to get it right, sooner or later, you're going to deal with support requests. "Why is my content not styled to the microsite?" This is inevitable. Be prepared.

Use pathauto, but consider your path aliases carefully

At some point, you'll need to consider SEO and tidy up your URL paths to fit with the connected microsite. Random path patterns aren't good for UX and aren't good for SEO. If you have a microsite located at www.example.com/widget-prime, you'll want to do your best to keep microsite content consistent with some pattern like www.example.com/widget-prime/this-is-a-blog-post and not keep things at the root like www.example.com/this-is-a-blog-post.

Best to turn to pathauto early to help you manage this. But this can get complex fast. For content that can be associated with a microsite, will that association be optional or required? If it's optional, what should be the path alias when it's present versus not present? The pathauto and token modules provide options for entity references, as well as excluding empty values intelligently. For example, you'll be able to use something like [node:field_microsite:entity:title] in the path pattern.

Conclusion

Microsites are an excellent way to provide your editors with flexibility while keeping things consistently within brand guidelines. They get a unique look and feel to help differentiate their content without stretching your design system beyond its intended limits. As long as you do your user research and don't go overboard with options, everyone wins.

We've put together several microsite implementations, from complex to simple, helping organizations improve their marketing efforts and extend the usefulness of their content management system. Contact us for help discovering what would work best for you.

Dec 07 2022
Dec 07

Drupal 10 was released on December 14, 2022, with new features and new possibilities. Here's what you need to know.

Making Drupal beautiful with Claro and OIivero

Drupal 10 has two new default themes, and we are proud to say that we helped push these initiatives forward so that they would be ready and stable for this release.

Olivero, the new front-end theme, has a modern design that accommodates common features like secondary navigation, media embeds, and layout builder. It is also WCAG AA conformant. Learn more about the design process for Olivero.

Claro, the new administration theme, came out of Drupal's Admin UI & JavaScript Modernisation initiative. Claro refreshes the administration UI with an up-to-date look and feel and brings in well-known UI patterns used on the web. It also has a focus on being accessible to as many users as possible. In the future, you can expect Claro to focus on UX improvements for each persona who has a hand in managing a Drupal website.

Theme starter kit

Currently, if you want to create a custom theme, you could use a core or contrib theme as a base theme and inherit all of its code and functionality. This works great…unless you want to modify or remove parts of the base theme. Drupal 10 comes with a theme generation tool that copies all of a theme's files and performs some string replacement to create the same theme but under a different name.

You can use this tool to copy the new starter_kit theme and have a new theme with basic templates and CSS. This barebones theme provides useful scaffolding, ready to be customized. If you want to streamline theme development further with different templates and defaults, you can create your own "starter" theme and use that as a base from which to copy.

More upcoming features

The plan is to make Automatic Updates and Project Browser a part of Drupal Core during Drupal 10's lifecycle. These features help match user expectations for using a modern content management system. 

Automatic Updates lets you update Drupal Core with the push of a button, but only patch-level changes. You won't be able to use it to upgrade to Drupal 11, for example, but you will be able to use it to update to new minor versions of Drupal 10. Listen to our podcast with three of the people working to make Automatic Updates a reality.

Project Browser lets users search for modules and themes and install them without leaving their Drupal site, even if the site uses Composer to manage packages and dependencies.

Upgrading from Drupal 9

Drupal 9 will reach its end of life on November 2023, which matches the end of life for Symfony 4. This gives you almost a year to plan your upgrade. While upgrading to Drupal 10 shouldn't be a huge endeavor, you'll want to pay attention to the modules you use and your hosting infrastructure. Both can cause unexpected snags. Here is what to look out for:

  • Contributed modules - make sure the contributed modules you have installed are ready for Drupal 10. If they aren't, consider working with the maintainers to help create and test patches. Acquia has a running list of modules and their Drupal 10 readiness status.
  • Custom modules - make sure your custom code is not using any deprecated functionality.
  • Hosting infrastructure - Drupal 10 will require PHP 8.1. Drupal 9 requires PHP 7.3, so you might have some system administration work to do.

Porting your code to Drupal 10

Drupal 9.5 and Drupal 10 will be identical, but Drupal 9.5 will still have all deprecated functionality remaining. This means you can update to Drupal 9.5, update your code to remove any deprecated functionality, and then it will be ready for Drupal 10. Here are the steps you want to take:

After you have worked through all the fixes, your codebase will be ready to upgrade to Drupal 10. You won't have much to do here if you have kept up with Drupal 9 deprecations as they have been updated.

Moving to CKEditor 5

Drupal 9 uses CKEditor 4 as its default rich text editor, but Drupal 10 will use CKEditor 5. This latest version of CKEditor is a complete rewrite with a modern JavaScript architecture and an improved UI. You'll have access to several new features.

But since it is a rewrite, CKEditor 4 plugins are not compatible. If you only used its out-of-the-box Drupal features, then moving to CKEditor 5 is simple. After updating to Drupal 9.5, switch your text formats to use CKEditor 5, which will trigger a semi-automatic upgrade path.

If you want to stay on CKEditor 4 for a while, install the CKEditor 4 module before moving to Drupal 10. This can buy you some time if you have some custom CKEditor 4 plugins you need to migrate because all custom JavaScript code will need to be rewritten. Like Drupal 9, CKEditor 4 becomes end-of-life near the end of 2023, so the sooner you start, the better.

Time to get prepared

A year goes by faster than you think. It's almost the end of 2022 already, and many people will be surprised despite the previous eleven months of hints, clues, and warnings. Time doesn't crawl, it gallops at a thundering pace. Drupal 9's end-of-life will be here before you know it. Start planning for Drupal 10 now.

Still on Drupal 7? Find out what your options are, including the possibility of migrating to Drupal 10.

Already feel behind? Maybe a little overwhelmed? Maybe your development has been focusing on new features and enhancements, and you don't want to grind their progress to a halt so you can do updates. Either way, we can help. Our support and maintenance services prioritize long-term maintenance by creating automated end-to-end testing and automated package updaters that keep your website updated, stable, and secure. When your website stays current with the latest Drupal core and contrib releases, upgrading to Drupal 10 (and beyond) becomes much easier.

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web