The configuration form (and everywhere in the code) states that the string you enter in the blacklist are used as prefixes to match against tags:

The strings are matched as prefixes, so for example config: will match tags as config:core.extension and config:block_list.

But this is the code behind the matching:

if (strpos($tag, $prefix) !== FALSE) {
  $blacklisted = TRUE;
}

This code checks if the tag contains the blacklist value, instead of starts with it.
This should be changed to:

if (strpos($tag, $prefix) === 0) {
  $blacklisted = TRUE;
}
CommentFileSizeAuthor
#2 purge-tags_blacklist_prefixes-3436188-2.patch691 bytesrp7

Issue fork purge-3436188

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

rp7 created an issue. See original summary.

rp7’s picture

rp7 commented
Assigned: rp7 » Unassigned
Status: Active » Needs review
StatusFileSize
new purge-tags_blacklist_prefixes-3436188-2.patch691 bytes
jnicola’s picture

jnicola commented

A quick note on this issue, it does indeed not match on prefix... and that's been good for us.

I would think the larger solution here would be to keep the current functionality as a blanket string match, and add a prefix section.

rgristroph’s picture

rgristroph commented

In particular, Drupal 11 now does node:nid:revisions cache tags, and if you want to block ":revisions", that's not a prefix. If your site doesn't show any but the default published revision to the general public, you might get some efficiency from that.

japerry made their first commit to this issue’s fork.

japerry opened merge request !83

  • japerry committed 8152e1bf on 8.x-3.x 
    docs: #3436188 Document that coretags blacklist entries are substring...
japerry’s picture

japerry
Location KOMK
commented
Status: Needs review » Fixed

The code has always matched blacklist entries as substrings; only the documentation says "prefix". Switching to prefix matching (#2) would silently break sites that rely on entries such as `:revisions` or `_list` (#3, #4), so MR !83 changes the documentation instead:

  • The form description and schema labels say a tag is excluded when it contains one of the strings, and the "Add prefix" button is now "Add string".
  • Documented the substring in CacheTagsQueuer.
  • Added a unit test case that fails under prefix matching.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

jnicola’s picture

jnicola commented

That works I suppose, though it does seem to be missing attribution to everyone in here who contributed to researching the issue and commenting. Or perhaps I am missing that bit.