Integrate Cookies-Banner by hook instead of "Cookies UI" Block

Created on 6 July 2022, over 2 years ago
Updated 21 February 2024, 10 months ago

Problem/Motivation

This feature request is free to discuss. I personally think it is quite annoying to always set a "Cookies UI" block first, before actually being able to use the module properly, since Cookies are usually site wide anyway. Additionally, submodules like cookies_video, cookies_instagram, etc. have their content blocked, but no way to unblock the content, if the admin forgot to set the "Cookies UI" block.

I suggest implementing the current "Cookies UI" Block logic inside a hook. We could implement a function that tells, if cookies are currently enabled for the current route and current user.
The admin would be able to set a "Show COOKiES Banner" permission and furthermore be able to define routes to include / exclude cookies behavior.

@Anybody, @JFeltkamp, what do you think about this? Of course, this is just a minor request, but could definitely help to improve the general usability of this module!

Expected Functionality:

Settings / UI:

  • Enabled checkbox at the Cookies Settings page as killswitch
  • Permission "Show COOKiES Cookie banner" for role based configuration
  • Disabled / Enabled at path(s)
  • ...?
  • Migrate block visibility rules (where possible)?

API:

cookies_is_active() tells if the cookie banner is active on the current page. Also called by the hook which then adds the cookies banner. Can be used by the knockout Scripts to determine if KO should be done

There shouldn't be caching issues as the functionality is based on (logged in) user / url.

Feature request
Status

Postponed

Version

2.0

Component

Code

Created by

🇩🇪Germany Grevil

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • 🇪🇸Spain cbccharlie

    In case this helps someone with the same need, here's what we have done:

    In our case, we wanted the block to always be placed, both in the public and private parts, without having to do it through Drupal block management. To achieve this, we have:

    1. Loaded it into our module using the hook_page_top and always at the beginning for accessibility.
    2. $cookies_ui_block = Drupal::service('plugin.manager.block')->createInstance('cookies_ui_block');
      if ($cookies_ui_block instanceof BlockPluginInterface) {
        $block['cookies_ui_block'] = $cookies_ui_block->build();
        $page_top = $block + $page_top;
      }
      
    3. By doing this, we didn't get the cookie blocked message in each component due to the logic of the CookiesKnockOutService class, which checks if the block is placed. Since we always want it to be placed, we need to alter this logic. To do this, we have converted that class to a service in a merge request (MR) from another issue on Drupal.org ( https://www.drupal.org/project/cookies/issues/3422880 Convert CookiesKnockOutService in service Needs review ), and in our module, using a ServiceProvider, we alter the service so that the doKnockOut method always returns true.
  • 🇩🇪Germany Anybody Porta Westfalica

    Thanks @cbccharlie while I don't think we should switch to a hook generally, I'm totally fine with providing better API ways to use COOKiES like this, if there are no other downsides :)

    I commented the other issue.

Production build 0.71.5 2024