Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.I couldn't find this so will ask. Hav eput it as a feature request for 7 as i suspect thats where it will need to go if not already there
For most things in life we have Who, What, Where, and When
For blocks we have
"Who" -Role specific visibility settings
"What" - Block Body
"Where" - Page specific visibility settings
But what about "When"?
At present we can add some php to "Page specific visibility settings" to handle the dates, but for many users php, may be a little too much when they are starting out, and this then adds extra complexity when only specific nodes are needed, which can easily be handled with :-
Show on every page except the listed pages.
Show on only the listed pages.
What about the a "Date specific visibility setting", "Start date", "End date" and always if empty?
Comments
Comment #1
stevectorMy understanding of the Blocks Everywhere initiative is that it will allow for pluggable visibility rules. These will function in a fashion very similar to pane visibility rules in Panels. It'd be easy enough to make a date range access plugin. Marking as postponed because that won't be possible until the Blocks Everywhere initiative is farther along.
http://drupal.org/sandbox/eclipsegc/1441840
Comment #2
David_Rothstein commentedThis seems like the kind of thing that can already be done by contrib modules, using hook_block_list_alter().
Does it really make sense to add it as a specific feature to core? I'm not sure it's a common enough use case.
Comment #3
damiankloip commentedI think I would agree with #2. The use case isn't common enough, should be easy enough for a contrib module to do.
Comment #4
Anonymous (not verified) commentedI can accept it may be considered a low usage issue as it has taken 3 years for anyone to even respond!. But I have been using this since before raising the issue, by using PHP in the Page Specific Visibility settings. Which is I guess how most people achieve the goal.
The point of the request is to make it simpler for the average user and therefore increase the usability and market penetration of Drupal.
It would also reduce the need to update yet another module
Simple use scenario. You need a block, displayed between certain dates. Maybe 'Happy New Year' etc. You know when these blocks need to be displayed, but at present you have to enable the block and disable the block. By having the dates, you can set it and get on with your life.
You may say a "contrib module" can do this, but there has to be one that 'does' do this, which means you need someone with enough knowledge to create one. The administartive costs of an additional module must be far greater than adding what I would assume is 2 extra fields and a small amount of code to core to include validation and implementation of the data.
Comment #13
longwaveI don't think this is a common enough feature request to include in core but this is solved in contrib: https://www.drupal.org/project/block_date