As we know views exposed filter blocks will reuse the same ID, based on view and display. To work around that, in this module, code exists to generate a new form ID based on the build id of the block. Normally this is an alphanumeric string, and will change. While this works, it makes later theming of the form pretty much impossible.
A common method for theming views_exposed_blocks is to add some template suggestions, based on the id of the form, like so:
function MYMODULE_theme_suggestions_alter(array &$suggestions, array $variables, string $hook): void {
switch ($hook) {
case 'views_exposed_form':
$suggestions[] = 'views_exposed_form__' . str_replace(
['views-exposed-form-', '-'],
['', '_'],
$variables['form']['#id']);
break;
}
Previously to using this module, I was using block_preprocess in a custom module to override the form id to actually match the machine name of the block, like so:
function MYMODULE_preprocess_block(array &$variables): void {
if ($variables['base_plugin_id'] === 'views_exposed_filter_block') {
// update id to make it unique - bug in views reusing ids
$variables['content']['#id'] = $variables['attributes']['id'];
}
}
This would result in a super helpful template suggestion like views-exposed-form--block-machine-name.html.twig which could then be used to add markup to the form.
Since this module uses the build id, none of this is possible!
n/a
I propose that we instead use the machine name from the block configuration to generate our ID. It will still be unique, as each placed block has a unique machine name, but now it's also something we can target meaningfully in code form preprocessing and theming.
The only drawback to this is that currently in core, there is no way to pull out the machine name within the build() method of a block, as shown on 💬 Retrieve unique block ID or machine name in build() method of BlockBase class Active , but a workaround is provided in comment #10 where it gets added to the configuration, which is readable from the build() method.
I am providing a patch that adds this functionality to the configurable_views_filter_block_block, with a fallback of the build id, as on an existing block, this data is not available until after the block configuration is resaved. The if condition could be removed and an update hook that resaved blocks of that type could be added on an upcoming release.
Needs work
1.0
Code
Can you elaborate why you set this back to needs work? What are the steps to complete this issue?
Could it be that 💬 Works with AJAX enabled? Needs review will solve this issue? At least it is related towards the build ID.