Condition plugins not evaluated properly when using Some Modules

I am working on this, mostly fixed, MR soon.

MR is ready. The culprit was really this:

But I also cleaned up some other bits of the code. I removed a trait, I figured it was making an already complicated code even more obscure and I wanted to leave things as close to BlockForm.php as possible as this will make it easier to keep up with any changes on core if there's any around this logic.

I also think (not 100% sure) that what I did and explained on #3345719-6: Google tag code is not present → is not necessary (I quickly tried and it looks it's not) but as BlockForm.php is doing it, I'd leave it there just in case. I did note this on the comments on a @TODO.

@NicholasS if you can try this that'd be great.

Ill try to test this out ASAP, one other observation I had when I uninstalled these modules causing issue, I noticed they also deleted the Google_tag config. And on 2.x that resulted in a WSOD on the admin form. and on 1.6x which I was just testing it only deleted the container config, no white screen of death. Hopefully your fix solves that issue too.

Hmm, it probably won't, but if you can try that as well and outline steps to reproduce that'd be great.

So I have been testing and it appears this solved the issue with a stock install with rules. I however still having issue with my more complex real world site. For some reason I am still having it save entity_route_context conditions in my real world site, trying to still figure out why its not working for me. But for a stock site with only rules and google_tag yeah it seems to be working.

your entity_route_context is the default condition or you are editing something? what happens if you save a block config when you save the block with the same visibility settings?

I was about to try the context modules but my current test site is D10 (which is where most of my google tag fixes has been going on). I will try testing with a D9 sometime later but maybe I can help you troubleshoot the issue.

The module looks a bit dated:

https://git.drupalcode.org/project/context_entity_field

I wonder if there's something odd with that condition, but if there is, a similar (if not the same) should happen with blocks visibility. I use that as a baseline.

Ok so I was able to re-create this in a stock drupal Gitpod. All I can figure out is that after you install some of these modules, you have to uninstall/re-install google_tag to get the behavior I am seeing. Ill explain my steps in Gitpod.

start a fresh gitpod https://gitpod.io/#DP_PROJECT_NAME=google_tag,DP_ISSUE_FORK=,DP_ISSUE_BR...

run ddev composer require cweagans/composer-patches

add your patch

"patches":{
  "drupal/google_tag": {
    "https://www.drupal.org/project/google_tag/issues/3357105#comment-15028743": "https://git.drupalcode.org/project/google_tag/-/merge_requests/39.diff"
  }
}

Reinstall with patchddev composer require 'drupal/google_tag:^2.0'
Add rulesddev composer require drupal/rules && ddev drush en rules

Install context ddev composer require drupal/context && ddev drush en context
Install this other one ddev composer require drupal/entity_route_context && ddev drush en entity_route_context

Still works at this point, UNTIL you uninstall and re-install.

ddev drush pmu google_tag
ddev drush en google_tag

Now when google_tag is install after these other are installed, I can't seem to get the google tag to show up.

I attached a video of the above steps https://www.drupal.org/files/issues/2023-04-28/adding-rules-make-gtag-no... →

Sorry this was the correct video for #14 https://www.drupal.org/files/issues/2023-04-28/with%20patch%20and%20modu... →

Ok so yeah I think I nailed down that is a problem with https://www.drupal.org/project/entity_route_context → infact I cant even uninstall that module without errors.

But whats odd is I tested it and I do infact have to install https://www.drupal.org/project/entity_route_context → first, then uninstall/reinstall google_tag and only then does it stop working correctly.

If I setup and install google_tag first, and then install https://www.drupal.org/project/entity_route_context → it works fine.

In your steps to reproduce at which point you save d
The google tag setting with a value ?

@hanoii - I updated #14 to clarify when I added google_tag settings, its basically after I install the module each time.

Doing even more testing, since I can't uninstall entity_route_context I did find that if I manually strip out all the 'entity_route_context' related conditions from the yml and import the google_tag.container config the module works as expected, I just cant save the google_tag settings again, or the conditions get added back.

So at this point I think my issues have more to do with this other module. Unless your module should be evaluating if these "entity_route_context" conditions were untouched? Because I am leaving them at their defaults but the seem to be added as conditions for google_tag.

I am pretty sure this is not an error in this module, but rather in how context and it's ecosystem handle the conditions. I can't look at this right now, but the same things happens with blocks.

If you do the same with blocks, the block will not display in the same situation as google tag. If you uninstall google tag, the same things happens with block. this is because entity_route_context adds a new context to a condition from the context module and it's saved with that.

There are a lot of things going on that are outside of this module:
- I would have expected for the configuration to have a dependency on the new module if a context of that module is used, but this is not happening.
- Also context default are just wrong. If you just enable context and save google tag (or a block) you will see visibilty/conditions being output in the config. These works because those conditions are empty, but still, there should be none.

This module doesn't filter out defaults, core does it so I think that context is failing to provide the instance default properly so that it is filtered out.

All of this, I think needs to be fixed somehow on contexts, and if not, core, but I would think it can be fixed in context.

I tried context:^5 and entity_route_context:^4 on a real world site on D10 and this doesn't happen. I wonder if it's the new version that did something better.

> This module doesn't filter out defaults, core does it so I think that context is failing to provide the instance default properly so that it is filtered out.

Ok yeah that sounds very logical, at least I have a crude work around by manually removing the conditions and importing that config. Thought switching from google_analytics to google_tag would be a quickie, here I am ~8hrs later :P

Not sure if it helps but I compared the list of "conditions" in gtag to my typical block settings, and these problem fields are not typically there on my block settings. This I think supports your idea of them not being filtered out correctly.

Hmm, not sure on those, on my tests. I normally see the same conditions on both, at least they should be as they are using the same conditions plugins, maybe there's some filtering. I wonder where those are coming form, probably context_entity_field ?

Yeah I can confirm D10 with context:^5 and entity_route_context:^4 does not have this issue. Thanks maybe I can look at those projects and see if I can patch them. (I have too many D10 blockers so thats not an option right now) But then again hope its not the D10 part that fixes it...

In reply to #22 yes very sure they are coming from context_entity_field

'entity_field:node':
    id: 'entity_field:node'
    field_name: body
    field_state: filled
    field_value: ''
    context_mapping:
      node: '@entity_route_context.entity_route_context:canonical_entity:node'
    negate: false

I wonder if this issue is related as well. https://www.drupal.org/project/context_entity_field/issues/3279400 →

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