0

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.
Improve this question
1
  • 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 ♦
    Commented Feb 28, 2018 at 13:10

1 Answer 1

Reset to default
1

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.

Improve this answer
5
  • 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
    Commented Feb 28, 2018 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
    Commented Feb 28, 2018 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
    Commented Mar 1, 2018 at 5:30
  • @Berdir Also hook_block_access will not be called for not-rendered blocks.
    – Taha Jahangir
    Commented Mar 1, 2018 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.
    – 4uk4
    Commented Mar 1, 2018 at 17:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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