[Experimental] Disable preprocessing for gtag.ajax.js, to facilitate GDPR/non-GDPR variations

Created on 21 March 2024, 7 months ago
Updated 23 April 2024, 6 months ago

Problem/Motivation

We're currently using https://drupal.org/project/cookies for GDPR compliance. In our setup, we detect if the request originates from the EU and use that as caching variation to ignore/activate the consent-honoring mechanism. Recent work got us to hit a bug where JS aggregation (post D10.1, which uses a lazy mechanism) fails for one aggregate. The quickest fix we found was just disabling preprocessing for gtag.ajax.js.

Although a deeper analysis for the proper root-cause of this problem is yet pending, I think it's worth sharing a patch for this, should somebody else find the same issue. The exception message we saw is:

Only file JavaScript assets with preprocessing enabled can be optimized.

📌 Task
Status

Active

Version

2.0

Component

Code

Created by

🇨🇴Colombia jedihe

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

Comments & Activities

  • Issue created by @jedihe
  • 🇨🇴Colombia jedihe

    Patch attached.

  • 🇩🇪Germany Anybody Porta Westfalica

    @jedihe thanks for the post! COOKiES maintainer here.

    Please check the code at:
    https://git.drupalcode.org/project/cookies/-/blob/1.2.x/modules/cookies_...

    Have you enabled that submodule and are you using the latest COOKiES version?

    The change from the patch here should NOT be required, as we set the preprocess to false in COOKiES. Could you please elaborate if that doesn't work?

  • 🇨🇴Colombia jedihe

    Thanks for your suggestion, @Anybody!

    Yes, we're using cookies_gtag 1.2.11. A quick comparison of the local install vs. cookies_gtag.module-1.2.x showed cookies_gtag_js_alter() to be identical.

    So, for us, it's not enough what is done in cookies_gtag_js_alter(), only by using the patch in #2 we got to fix the error.

  • 🇩🇪Germany Anybody Porta Westfalica

    Thanks @jedihe, did you take a look at the code?

    I really don't get the difference. Can you tell what it is? Our code should exactly do the same already as your patch does. What am I missing?
    Could you perhaps debug that, so that we can fix this in COOKiES? That would be awesome.

  • 🇨🇴Colombia jedihe

    Thanks for the quick follow-up :).

    The difference is that the js_alter hook in COOKiES is only setting preprocess to false when a certain condition is met; as long as that condition is true for all visitors, it should be no problem. In our case, we want to handle users in two groups: one with COOKiES enabled, one without.

    Although I didn't yet do a deep analysis to fully confirm, the above is what should explain the issue we were seeing.

    I think this change record is relevant for this discussion: https://www.drupal.org/node/2888767 . In particular:

    In general, hook_css_alter() and hook_js_alter() may now be called from a separate HTTP request from the one rendering the HTML (this was already the case with some contributed modules), and as such cannot vary on all information from the request such as route.

  • First commit to issue fork.
Production build 0.71.5 2024