Layout Builder with Reusable Blocks and Revisioning
A marketing team uses Layout Builder on the Landing Page content type to create custom layouts per node. They have 30 landing pages, each with a unique layout. They want to reuse a promotional banner block across multiple pages. Currently, they create a new custom block for each page, resulting in 30 separate blocks that are hard to update. They also need to ensure that when they update the banner, all pages reflect the change immediately. Additionally, they want to schedule layout changes for a future date without affecting the live page until then. The site has revisions enabled for Landing Page nodes. The team reports that after editing a layout, the changes are not visible on the live site until they clear the cache.
1. What is the best approach to reuse the promotional banner block across multiple landing pages while allowing centralized updates?
Read the worked answer
Instead of creating a custom block for each page, create a single reusable custom block (or a block content entity) and place it in the Layout Builder layout for each landing page. In Layout Builder, when adding a block, choose 'Create custom block' only if you need a unique block per page. For reusable content, create the block once via Structure > Block layout > Custom block library, then in Layout Builder, add an existing block by selecting 'Block' and then choosing the custom block from the list. This way, updating the custom block updates all instances. Alternatively, use a content entity reference field and a view to display the banner, but a custom block is simpler. Ensure that the custom block is not set to 'reusable' incorrectly; it should be a block content entity that can be placed multiple times. After placing, the block will be referenced, so changes to the block content propagate to all pages.
2. How can the team schedule layout changes for a future date without affecting the live page?
Read the worked answer
Layout Builder does not natively support scheduling layout changes. However, since Landing Page nodes have revisions enabled, the team can create a new revision of the node, modify the layout in that revision, and use the 'Schedule' feature from the Content Moderation or Scheduler module to publish the revision at a future date. But note: Layout Builder changes are stored in the node revision. If the node is published, the layout changes are immediately live unless the node is in a non-default revision. To schedule, they can use the Scheduler module to publish a draft revision at a specific time. Alternatively, they can use the Content Moderation workflow to move the revision to a 'Scheduled' state and have a cron job publish it. The key is to keep the live revision as the default until the scheduled time. Ensure that the 'Published' state is the only default revision state, so that the draft revision with layout changes does not become live prematurely.
3. Why are layout changes not visible on the live site until cache is cleared, and how can this be fixed?
Read the worked answer
Layout Builder changes may not appear immediately due to caching. Drupal caches block and layout output. When a custom block is updated, the cache tags for that block should be invalidated, but if the block is placed in Layout Builder, the layout may be cached separately. Ensure that the 'Cache' settings for the block are not set to a high value. Also, check that the site's cache is configured to clear on content updates. If using a reverse proxy or CDN, they may need to be purged. In Drupal, the 'Internal Page Cache' and 'Dynamic Page Cache' should automatically invalidate when content changes. However, if the custom block is not correctly invalidating cache, check that the block's cache tags are being applied. A common issue is that the block is rendered with a cache context that is too broad. For immediate visibility, the team can use the 'Clear cache' button, but a better fix is to ensure that the block's cache settings are set to 'Cache per page' or 'Cache per user' as appropriate, and that the block's cache tags are correct. Also, ensure that the 'Cache' setting in the block's configuration is not set to 'Never' or a very long time.