🇳🇱Netherlands @casey

casey → created an issue.

We are having the same issue.

For now we simply clean out 'advanced_settings.gtm' manually in our google_tag.container.default.yml:

...
advanced_settings:
  consent_mode: false
  gtm: {  }
...

This is possible as TagContainer::getGtmSettings() returns a default config array. We don't need to override these defaults (not up until now at least).

I do hope however a better solution will be found. Maybe a single google_tag container entity should only have a single GTM id?

What about:

1. adding a new entity storage handler that stores all configurable fields in a single JSON database-column
2. adding dirty checking to entity API so we can prevent saving unchanged entities
3. adding paragraphs (and entity_reference_revisions) to core using this new storage handler

Patch for CKEditor 5 (only) support

bbrala → credited casey → .

Patch #154 incorrectly did request_time - expire instead of expire - request_time to recalculate mag-age

This patch is a combination of the patch in #131 and 🐛 Stacked caches result in max-age drift in caches Active for usage in sites <=D10.2

Turns out, skipping max-age of 0 (that is, handling max-age=0 as permanent in page cache) is not a good solution; if you use max-age to ensure a cached page is rebuild after a certain timestamp, and if a request happens on exactly the expiration time, the response must not be cached (as the max-age is 0). At least in such cases, page cache must not handle max-age=0 as cache permanently.

And since we (currently) cannot determine why max-age was set to 0, I think page cache should never cache responses with a max-age>=0. Even if this means that certain (or all) pages will no longer be cached by the page cache. Note this means that for example multilingual sites using the language switcher block ( 📌 Make language switcher block cacheable Postponed ) no longer have their pages cached by the page cache module, but at least the page cache won't be incorrectly caching pages permanently that have a max-age>=0. Also, those pages will probably still be cached by the dynamic page cache.

I think we should deprecate using the Expires header as the expire time for the page cache and just use the max-age of the cacheable metadata of the response. There are several places (like access checks) that don't have access to the final reponse and can only pass cacheable metadata.

I also think this issue is actually about two different issues:

1. Page cache incorrectly ignoring the max-age of the cacheable metadata of the response (patch #131)
2. The Cache-Control response header not containing/reflecting the max-age of the cacheable metadata of the response (patch #148 or something like cache contol override module)

For now, if your site depends on time-based cache invalidations you at least need the patch from 🐛 Stacked caches result in max-age drift in caches Active , even if your site is not using the page_cache module.

If you are using the page_cache module, you also need the patch from #131 as a complete solution.

If you are not using the page_cache module (but are using another pubic/managed caching solution, like a reverse proxy like Varnish), the patch from #148 might work.

The Cache Control Override module can be used additionally if you want to set a minimum and/or maximum on the max-age of the Cache-Control response header.

Quick patch that synchronizes the max age of cached date with the current time if the cached item has an expire set.

bbrala → credited casey → .

casey → created an issue.

This patch is based upon #131, but ignores cacheable metadata's max-age if it is 0. This should work around the issues like suggested by @Berdir in #146

I agree that Timo has the necessary knowledge for this position and support his application.

Reroll of patch #16

I think we should either merge any existing cache metadata on the renderable, like the patch in #5,

or throw an exception if the CacheableMetadata removes any existing cache metadata when applied to a renderable (diffing the new resulting #cache with the old existing ##cache)

casey → created an issue.

What about changing the return type/hint of EntityInterface::id() and all other ID parameters//returns to ?string and dropping int altogether as possible return type.

IDs are used to uniquely identify entities and not to do calculations with or anything.
Dropping int as will simplify the interface and makes it easier to enforce strict typing ( https://www.drupal.org/project/drupal/issues/3050720#comment-13562649 🌱 [Meta] Implement strict typing in existing code Active )
It will still be possible to do things like auto increment (no issue at all when handled by the DB) and finding the next available (numeric) ID.

I think almost all existing code will continue to work; as already stated, the type of ID variables are already inconsistent.

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

It looks like this issue has been fixed in 🐛 ajax_page_state leaks through request in Views Ajax Needs work

In development environments the api key is typically not provided. When the api key is missing currently every drush call triggers at least one " [error] OhDear site id is missing! Fix it ..."

Previous patch doesn't work.

casey → created an issue.

Static patch file of MR up until #4 for use with composer-patches

Reroll. Still needs a test

Reroll for 10.2

Wrong patch

To be able to update the change time during syncing the EntityChangedConstraintValidator must also be updated

Previous patch used the wrong variable in constructor

Maybe we should also check visibility rules? Something like this might work.

casey → created an issue. See original summary → .

#24 does not apply to D10

Duplicate of 🐛 Query parameters and anchor of substitution url are being stripped Closed: duplicate

I think I agree with Berdir that the right solution is to trigger an exception.

Something like this would work.

To lock a row, it should not have a draggable class and its weight should be disabled. Also, this patch only works for (not select) inputs as weight.

casey → created an issue.

casey → created an issue.

This patch only fixes ImageStyleDownloadController and is only to be used in combination with patch #5 #3309534-6: Accessing private file with .jpg, .jpeg, .png extension returns WEBP image → .

Actually, why is it even allowed to request/generate a webp when a specific (not a image-style derivative) file is being requested?

This patch simply removes the FileDownloadController replacement.

It would be even better to first check if a webp is being requested, before trying to validate if the requested uri is an image.

Reroll of #2

Here's a patch that removes the jquery dependency from better_exposed_filters/general and better_exposed_filters/auto_submit

Just run into this issue as well. What about only checking the query arguments from data-drupal-link-query and only skip if any of those don´t match the current query, while ignoring any additional query arguments from the current query.

What about passing just query and fragment. This keeps the plugin interface much cleaner.

casey → created an issue.

Patch seems to be working.

This patch also allows the use of html tags in the more link text

Here's a patch we've been using in a project since D8 to support argument tokens.

casey → created an issue.

MR as patch file to be able to use it via composer-patches

*For 50% written by ChatGPT :D

casey → created an issue.