Suppose we want to use a different layout/blocks in front page. I know there is a page visibility restriction feature in block configuration, and also Page Manager and Panelsmodules exist, but what's the downside of this solution?

  1. Define a specific region content-front in theme
  2. Place some blocks in this this region
  3. Render this region only in page--front.html.twig template

The above solution has some advantages: front-page blocks are listed separately from other blocks, no need to configure each block to be in <front> page (preventing a O(n) task), using native UI to arrange the blocks.

Edits:

  • hooks like hook_block_access or hook_preprocess_block will not be called for a block not being rendered.
  • 1
    If it fits your requirement, there’s no downside. If you don’t need a region, don’t render it (and vice versa). If you’d rather maintain two page templates than one because your block/region needs are better suited that way, do it - Drupal won’t care and it won’t have any side effects other than the contents of a region not being rendered to a page whose template doesn’t render it – Clive Feb 28 at 13:10

Drupal won’t care and it won’t have any side effects other than the contents of a region not being rendered to a page whose template doesn’t render it

It's not quite that simple.

The problem with dynamically not rendering a region is that Drupal doesn't know about that. It will still load, check and prepare those blocks on every page, which means it is unecessary overhead compared to defining visibility rules to only have it shown on the frontpage. You can also do an empty check of the region in the template and as a result, only have it printed if there are blocks inside (this doesn't work reliably with blocks that might be shown but might be empty but it should work if they are configured to not be shown).

You could also implement a hook_block_access() implementation and deny view access for all blocks in a certain region, then you don't need to manually configure them all, but it does need to be in a module.

  • It will still load, check and prepare those blocks on every page - this was not changed with how Context module used to handle this? – Kevin Feb 28 at 20:35
  • Don't know how that should be related to the context module? This is impossible to not do, how core know what the page template will do when building list of blocks to render? – Berdir Feb 28 at 21:16
  • I checked that hook_preprocess_block will not be called for a block that is not being rendered. What's the other preparation or load steps for blocks? – Taha Jahangir Mar 1 at 5:30
  • @Berdir Also hook_block_access will not be called for not-rendered blocks. – Taha Jahangir Mar 1 at 6:13
  • @TahaJahangir, possible reasons are, the block was rendered some time ago (and now is cached) or it will be rendered later (all blocks are rendered in a lazybuilder callback by default). Both help to mitigate the downsides. So in most cases your approach should work without performance problems, but as Berdir said, it's not quite that simple, if performance matters better run tests. – 4k4 Mar 1 at 17:40

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.