@camslice

Nice work @mkalkbrenner, serving my particular use case perfectly with minimal config and disruption

Completely agree with @neclimdul → . Previously I was able to send dataLayer properties along with the page_view event provided by the default Google Tag. At some point these properties became undefined, now I know why.

My current solution is to set the Google Tag trigger to "DOM Ready" instead of the default "Initialization". This means the dataLayer is already populated before the Google Tag is triggered, however it can have a negative effect on metrics due to the delay between Initialization and DOM Ready. Further reading: Page view triggers

Ideally the dataLayer snippet should be above the GTM snippet. That way the dataLayer is already populated and people can use the default "Initialization" trigger for their Google Tag. The default config should Just Work™ IMHO.

I've had to disable this filter for now as it often causes the site to crash when rebuilding after a cache clear. Broken links in particular seem to slow it down to the point of timeout.

Bump. I too would like to be able to export Groups to config

Yes that's exactly what happened to me. The consent checkbox was unticked, I updated the module as part of routine monthly maintenance. The bug caused it to become ticked without my knowledge. Fast forward a month and the client asks "why do we have a flatline of GA data for April?". Pretty serious bug IMHO.

Fix on dev branch works for me on Drupal 10.2.5. Lost about a month of tracking data. Not happy.

Wonderful, thanks @nidhi27! So now we just wait for the project maintainer to approve and merge?

IMHO opinion this filter is needed, however it should target Twig specifically and properly process HTML entities.

In its current form, the result is the same as |striptags|trim.

For example, take a field value of "Twelve O'Clock".

Both |striptags|trim and |remove_html_comments produce the same result:

Twelve O'Clock

I suggest 2 changes to make this filter worthwhile in its own right:

1. Rename it to |strip_twig_debug

or

|remove_twig_debug</li>
  <li>Process HTML entities</li>
</ol>

If processing HTML entities feels too invasive, you could always pass an optional argument allowing people to prevent HTML entity processing.

Currently, the only viable option is the <a href="https://www.drupal.org/project/twig_htmlspecialchars_decode">twig_htmlspecialchars_decode</a> module, resulting in quite a long and clumsy filter chain  ':[]
<code>
|striptags|trim|twig_htmlspecialchars_decode

camslice → created an issue.

@sgoodwin's solution in #4 didn't work for me, however this does the trick:

$config['system.mail']['interface']['default'] = 'php_mail';
$config['system.mail']['interface']['webform'] = 'webform_php_mail';

When you switch the smtp module OFF, it also modifies the system.mail config.

I hope my comment doesn't result in this issue going stale ':[]

Nice one @adebruin, I've added a similar patch for sign_up and login events here: https://www.drupal.org/project/google_tag/issues/3406422#comment-15401008 🐛 Sign Up and Login events do not work Needs review

Patch to use in composer.json to avoid regression.

camslice → created an issue.

Bump

camslice → created an issue.

Looking forward to being able to use this module in Drupal 10. Extremely powerful when combined with block_visibility_groups →

I am having the same issue with both "Login" and "Sign Up" events ("User registration" as it's named in the Admin UI). The only way I can get these event to fire is to implement a custom submission handler, then use $form_state->disableRedirect();. This is not really a "solution" though, because it leaves the user on a form that has already been submitted.

@cosolom's changes fixes it for me. Nice work.

I wonder if this could also fix the purchase event issue I reported here? https://www.drupal.org/project/google_tag/issues/3406399 🐛 purchase event not being sent on successful webform submission Active

camslice → created an issue.

Thanks @joseph :)

hi joseph.olstad → , will you be released a new tag on the 8.x-1.x branch that includes this fix? the current tag 1.10.0 does not seem to include the fix. thanks

Great, thanks for the prompt responses LOBsTerr

Ah I see, I guess this applies to rejected membership requests too. Is there some way to review and remove rejected requests via the Admin UI?

This change to grequest.routing.yml:10 causes a 403 Forbidden response for "Outsider" (AUTHENTICATED USER) when trying to access the request membership form:

... @@ -7,6 +7,7 @@ entity.group.group_request_membership:
 7  _group_permission: 'request group membership'
 8  _group_installed_content: 'group_membership_request'
 9  _group_member: 'FALSE'
10+ _group_membership_request: 'TRUE'

https://git.drupalcode.org/project/grequest/-/commit/bb48aac4fa0364dbd7a...

If I remove line 10: _group_membership_request: 'TRUE' the request membership form renders correctly.

Commit 6a90ca0b broke my install. When I click the "Approve membership" button, it displays the following fatal error:

The website encountered an unexpected error. Please try again later.

RuntimeException: Controller "Drupal\grequest\Controller\GroupMembershipRequestController::approveMembership()" requires that you provide a value for the "$group_relationship" argument. Either the argument is nullable and no null value has been provided, no default value has been provided or because there is a non optional argument after this one. in Symfony\Component\HttpKernel\Controller\ArgumentResolver->getArguments() (line 80 of /app/vendor/symfony/http-kernel/Controller/ArgumentResolver.php).
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->onController(Object, 'kernel.controller', Object)
call_user_func(Array, Object, 'kernel.controller', Object) (Line: 142)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object, 'kernel.controller') (Line: 157)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 81)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 718)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

```

Reverting this commit fixes the problem. I think there may be some other places where the group_content needs to be renamed to group_relationship, such as in the routing parameters for example:
docroot/modules/contrib/grequest/grequest.routing.yml

Reroll #49 for 2.2.x — for people on the upgrade path. My first patch, sorry if I messed it up.