Problem/Motivation

The features to exclude user id 1 or admin pages is broken.

Steps to reproduce

  1. Enable the advanced feature "Exclude admin pages"
  2. Enable the withdraw tab
  3. Load an admin page
Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

svenryen created an issue. See original summary.

svenryen’s picture

Turns out this is "by design". We now have a banner that stays "hidden" on all pages, including admin pages.
Note that the banner won't open, you'll just see a "Privacy settings" tab when the features to exclude admin pages or uid 1 are enabled.

I added some description to clarify this behavior.

svenryen’s picture

Status: Active » Needs review
svenryen’s picture

Assigned: Unassigned » neslee canil pinto

Neslee Canil Pinto made their first commit to this issue’s fork.

neslee canil pinto’s picture

Assigned: neslee canil pinto » Unassigned
Status: Needs review » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

endrukk’s picture

I think we need to reopen this.

When Include minimal CSS, I want to style the banner in the theme CSS. is enabled and the banner is positioned on top it interferes with the admin theme and makes admin experience experience pretty poor.

Can we actually not render the markup on admin pages?

svenryen’s picture

The whole point of Include minimal CSS, I want to style the banner in the theme CSS is that you should style the banner by yourself, and we can't do anything about that feature as many sites rely on it.

If you want to not render the markup on admin pages, have a look under Advanced settings, there's an option to Exclude admin pages, as well as Exclude paths which allows you to enter values such as "/admin" and "/admin/*" should you wish to manually exclude any pages.

These feature are available both in d7 and d8/9.

Furthermore, admin pages are excluded by the default settings of the Drupal 8 module.

ambient.impact’s picture

I'm a bit confused by this: is it necessary to show on admin pages even if that's checked to exclude admin pages when "withdraw consent" is available due to legal reasons, or is this an unintended bug?

tanc’s picture

I've also noticed this weird unstyled tab and form hanging around on admin pages. I've stepped through the code and the only thing the exclude paths and exclude from admin theme do is set open_by_default to false, which as far as I can tell stops the banner from being open but doesn't stop the code from being included. I guess I'll open a new issue as this is closed.

svenryen’s picture

Status: Closed (fixed) » Active
svenryen’s picture

@tanc, did you open a new issue?

svenryen’s picture

Status: Active » Needs review

@tanc , @Ambient.Impact , can you take a look at the patch in the new MR (https://git.drupalcode.org/project/eu-cookie-compliance/-/merge_requests...) and check if it resolves the problem you're experiencing?

It currently hides the banner entirely if there's a match from the excluded paths, the user is admin and the corresponding setting is set, or the admin theme is active and the corresponding setting is set.

kevinquillen’s picture

Furthermore, admin pages are excluded by the default settings of the Drupal 8 module.

It still appears in an entity browser modal, despite having this setting set. How do we prevent it from rendering period for UID 1 and administrator roles?

svenryen’s picture

@kevinquillen, did you enable the Don't show the banner for site administrators (including UID 1). under Advanced, and do you still see the banner or tab with this patch applied?

kevinquillen’s picture

Yes, even with the patch it shows up. Even with a path set, it shows up.

The uid1 check is odd to me, if the role is administrator isn't that good enough?

Anyway, here I am as user 1 WITH the box checked:

debug

Path match and admin route match and admin theme match are all true (uid1 isnt, for some reason). hide_the_banner is true, and here it is right in the entity browser:

debug

Doing some debugging I made this change:

  if (!$hide_the_banner) {
    $variables['#attached']['drupalSettings']['eu_cookie_compliance'] = $data['variables'];
    $variables['#attached']['drupalSettings']['eu_cookie_compliance']['open_by_default'] = $open_by_default;
    $variables['#attached']['drupalSettings']['eu_cookie_compliance']['hide_the_banner'] = $hide_the_banner;
    $variables['#attached']['library'][] = 'eu_cookie_compliance/eu_cookie_compliance_' . ($config->get('use_bare_css') ? 'bare' : 'default');
  }

Sure enough, it is now gone from the entity browser:

debug

But the banner shows on the front of the site for anonymous users, which is what I want.

Can execution or attaching just quit out like this if its been determined that it should not show?

svenryen’s picture

Thanks for the detailed report. I'll take another look.

The uid1 check is odd to me, if the role is administrator isn't that good enough?

The code dates back to #1594604: don't pester uid 1 from 2017. I don't recall the details why there's a check for UID 1. It could have been necessary for Drupal 7?

svenryen’s picture

Status: Needs review » Needs work
kevinquillen’s picture

A day later and with no further changes, it stops showing up on both my local and in the cloud. I do not know why. I did not dismiss it nor do I have any cookies.

svenryen’s picture

Could it have been cache that got cleared?

Are you using the patch and does it behave properly now?

  • svenryen committed 4734bfd on 8.x-1.x
    Issue #3236590 by svenryen, Neslee Canil Pinto, kevinquillen, endrukk,...
svenryen’s picture

Status: Needs work » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.