🇧🇪Belgium @lorenzs

Tested the latest patch from #13 and works well.
This is way better than putting it hardcoded to 'public'. Only small drawback I see is that the derivative image will always have the same scheme as the original image (where the scheme is derived from the uri).
So I think only very specific use cases where sites are putting derivatives and originals in different locations (f.e. public & s3 if no general takeover of public) will encounter issues with this but all others can work with this already.

lorenzs → made their first commit to this issue’s fork.

Update readme en remove above client specific naming

Tested.. again.. PKCE is a widely used standard and this issue is now open for more than 2 years keeping us busy with MR's and patches that were tested and reviewed... I do not think anyone is offended by an extra setting in the mentioned config form so please make another alpha release - it is alpha for a reason and setting can easily be skipped if not needed.

In the meantime I can confirm this is working on a D10/PHP8 site with PKCE/SHA256 enabled.
For me the use of the setting in the form is very clear (off, on - then choose transformation) but fine if it would be 1 toggle. That also prevents having 'no' transformation on existing installs when enabling the config only via code - without saving the settings form.

Added in latest 4.x dev branch.

Added in latest 4.x dev branch.

lorenzs → created an issue.

lorenzs → created an issue.

D10 compatibility is merged in the 4.x branch which will get a release. Thanks for preparing this!

This is a fix on a deprecated function.
setAccount will be removed in the upcoming D10 release

Hi, It has been a very busy year but it is my plan to get a D10 version out asap.

I'd suggest to ignore Google's suggestion here if you want to be GDPR compliant.

The only proper way to be compliant is:

1. include Tagmanager by default (as the module facilitates)
2. configure Tagmanager to use consent-mode (container settings)
3. add a 'consent-initialization' tag with your Consent-Management banner (preferably via a template)
4. configure on each of your other tags requiring a consent an 'additional' consent

f.e. for a GA4-tag add 'analytics_storage' again under 'advanced settings' > 'Require additional consent for tag to fire' (allthough this is also a built-in setting)

Also see this well-written article;

https://brianclifton.com/blog/2022/03/14/google-consent-mode-breaks-privacy-laws/

So this patch or 'solution' from Google is not needed/wanted for GDPR compliancy, on the contrary, it will do the opposite.