Page MenuHomePhabricator

Titles with non-DB-normalised keys are not recognised
Closed, ResolvedPublic


In extension Nuke, the pattern field must be currently written with the DB-normalised key (as found in the recentchanges table) in the SQL LIKE mini-language.

For instance:

  • "spam %" will never catch any title, it can be "Spam\_%" or "Spam\__" (with default MW settings, specifically the first-letter capitalisation) to catch titles like "Spam 1" but not "SpamT1"
  • "Spam_%" catches titles "Spam 1", "SpamT1", "Spam1"

It would be easier to use MediaWiki-displayed titles instead of MediaWiki-DB-encoded titles, by using MediaWiki title normalisation, but still use the two SQL wildcard "%" and "_". In particular, it would be easier to differentiate the space (encoded as "_" by MediaWiki and encoded as "\_" in SQL LIKE) and the SQL 1-character wildcard (encoded as "_" in SQL LIKE).

See also T7835 (the original feature request) and T37783.

Event Timeline

Change 541077 had a related patch set uploaded (by Seb35; owner: Seb35):
[mediawiki/extensions/Nuke@master] Use MediaWiki’s Title class to parse and normalise the SQL LIKE pattern

Issue raised multiple times on the talk page:

@Seb35: Per emails from Sep18 and Oct20 and , I am resetting the assignee of this task because there has not been progress lately (please correct me if I am wrong!). Resetting the assignee avoids the impression that somebody is already working on this task. It also allows others to potentially work towards fixing this task. Please claim this task again when you plan to work on it (via Add Action...Assign / Claim in the dropdown menu) - it would be welcome. Thanks for your understanding!

I've got the previous patch working on the latest commit of Nuke (as part of Wikimedia-Hackathon-2024), i.e. converted it to use the new QueryBuilder system. Lots of reusable stuff, so might as well just improve that patch rather than create a new one. Uploaded it under the same patch (541077).

Got this checked by a DBA to make sure it's safe, see T364144 for the general sentiment.

@Ladsgroup Per the above do you think this ticket should be declined outright in favour of T364144: Replace SQL LIKE matching for Nuke?

They are not really mutually exclusive. Both should be done ^_^

Chlod removed Chlod as the assignee of this task.May 3 2024, 5:47 PM
Chlod added subscribers: Zabe, Chlod.

Bad news: the way the filter works is inherently incompatible with QueryBuilder.

Without mucking around with internal methods, there's no way to properly handle the "pattern" without escaping the percent (which would mean % is matched literally) or not escaping _ (which would mean spaces won't work anyway). The tests also checked if one can input \% to match % literally in page title, which assumes that the escape character is \, but it's actually a backtick. To my knowledge (and the knowledge of the people beside me on the Hackathon desk), there's no way to insert raw SQL which could do a LIKE without the ESCAPE clause.

Giving up on this in favor of T364144. @Zabe restored patchset 8 at my request to restore the patch to its former condition.

Found a temporary solution. This should work for now until T364144 finally gets worked on.

Found a temporary solution. This should work for now until T364144 finally gets worked on.

I tested the new patch in a bunch of different ways and it behaves in the way I expect!

Change #541077 merged by jenkins-bot:

[mediawiki/extensions/Nuke@master] Permit spaces in the SQL LIKE pattern

Change #1027220 had a related patch set uploaded (by Scardenasmolinar; author: Scardenasmolinar):

[mediawiki/extensions/Nuke@master] Cleanup code comment on Special:Nuke

Change #1027220 merged by jenkins-bot:

[mediawiki/extensions/Nuke@master] Cleanup code comment on Special:Nuke

jsn.sherman claimed this task.