This is part 2 in this series that explores how to use paragraph bundles to store configuration for dynamic content. The example I built in part 1 was a "read next" section, which could then be added as a component within the flow of the page. The strategy makes sense for component-based sites and landing pages, but probably less so for blogs or content heavy sites, since what we really want is for each article to include the read next section at the end of the page. For that, a view that displays as a block would perfectly suffice. In practice, however, it can be really useful to have a single custom block type, which I often call a "component block", that has an entity reference revisions field that we can leverage to create reusable components.
This strategy offers a simple and unified interface for creating reusable components and adding them to sections of the page. Combined with Pattern Lab and the block visibility groups module, we get a pretty powerful tool for page building and theming.
The image below captures the configuration screen for the "Up next" block you can find at the bottom of this page. As you see, it sets the heading, the primary tag, and the number of items to show. Astute readers might notice, however, that there is a small problem with this implementation. It makes sense if all the articles are about Drupal, but on sites where there are lots of topics, having a reusable component with a hard-coded taxonomy reference makes less sense. Rather, we'd like the related content component to show content that is actually related to the content of the article being read.
For the purpose of this article, let's define the following two requirements: first, if the tagged content component has been added as a paragraph bundle to the page itself, then we will respect the tag supplied in its configuration. If, however, the component is being rendered in the up next block, then we will use the first term the article has been tagged with.
To do that, we need three things: 1) we need our custom block to exist and to have a delta that we can use, 2) we need a preprocess hook to assign the theme variables, and 3) we need a twig template to render the component. If you're following along in your own project, then go ahead and create the component block now. I'll return momentarily to a discussion about custom block and the config system.
Once the up next block exists, we can create the following preprocess function:
function component_helper_preprocess_block__upnextblock(&$variables) {
if ($current_node = \Drupal::request()->attributes->get('node')) {
$variables['primary_tag'] = $current_node->field_tags->target_id;
$variables['nid'] = $current_node->id();
$paragraph = $variables['content']['field_component_reference'][0]['#paragraph'];
$variables['limit'] = $paragraph->field_number_of_items->getValue()[0]['value'];
$variables['heading'] = $paragraph->field_heading->getValue()[0]['value'];
}
}
If you remember from the first article, our tagged content paragraph template passed those values along to Pattern Lab for rendering. That strategy won't work this time around, though, because theme variables assigned to a block entity, for example, are not passed down to the content that is being rendered within the block.
You might wonder if it's worth dealing with this complexity, given that we could simply render the view as a block, modify the contextual filter, place it and be done with it. What I like about this approach is the flexibility it gives us to render paragraph components in predictable ways. In many sites, we have 5, 10 or more component types. Not all (or even most) of them are likely to be reused in blocks, but it's a nice feature to have if your content strategy requires it. Ultimately, the only reason we're doing this small backflip is because we want to use the article's primary tag as the argument, rather than what was added to the component itself. In other component blocks (an image we want in the sidebar, for example) we could simply allow the default template to render its content.
In the end, our approach is pretty simple: Our up next block template includes the paragraph template, rather than the standard block {{ content }} rendering. This approach makes the template variables we assigned in the preprocess function available:
{% include "@afro_theme/paragraphs/paragraph--tagged-content.html.twig" %}
A different approach to consider would be adding a checkbox to the tagged content configuration, such as "Use page context instead of a specified tag". That would avoid having us having an extra hook and template. Other useful configuration fields we've used for dynamic component configuration include whether the query should require all tags, or any tag, when multiple are assigned, or the ability to specify whether the related content should exclude duplicates (useful when you have several dynamic components on a page but you don't want them to include the same content).
As we wrap up, a final note I'll add is about custom blocks and the config system. The apprach I've been using for content entities that also become config (which is the case here), is to first create the custom block in my local development environment, then export the config and remove the UUID from the config while also copying the plugin uuid. You can then create an update hook that creates the content for the block before it gets imported to config:
/**
* Adds the "up next" block for posts.
*/
function component_helper_update_8001() {
$blockEntityManager = \Drupal::service('entity.manager')
->getStorage('block_content');
$block = $blockEntityManager->create(array(
'type' => 'component_block',
'uuid' => 'b0dd7f75-a7aa-420f-bc86-eb5778dc3a54',
'label_display' => 0,
));
$block->info = "Up next block";
$paragraph = Drupal\paragraphs\Entity\Paragraph::create([
'type' => 'tagged_content',
'field_heading' => [
'value' => 'Up next'
],
'field_number_of_items' => [
'value' => '3'
],
'field_referenced_tags' => [
'target_id' => 1,
]
]);
$paragraph->save();
$block->field_component_reference->appendItem($paragraph);
$block->save();
}
Once we deploy and run the update hook, we're able to import the site config and our custom block should be rendering on the page. Please let me know if you have any questions or feedback in the comments below. Happy Drupaling.
