Extension talk:TitleKey

archive of previous talk

Previous page history was archived for backup purposes at Extension talk:TitleKey/LQT Archive 1 on 2015-07-10.

I just upgraded MediaWiki from 1.37.1 to 1.42.3 and reinstalled the TitleKey extension, version 1.0 (3acd981). I added $wgSearchType = MediaWiki\Extension\TitleKey\SearchEngine::class; after wfLoadExtension( 'TitleKey' ); in LocalSettings.php as instructed in Extension:TitleKey#Installation. I ran the update script as part of the MediaWiki upgrade.

Unfortunately TitleKey seems to break page text search now. Case-insensitive page title search works correctly, but if I try to search for a word in the contents of a page, I get no results. I have run both RebuildTitleKeys and rebuildtextindex, but neither of them fixed the problem. If I comment out the two TitleKey lines in LocalSettings.php, then page text search works again. (Of course, page title search becomes case-sensitive.)

Is there something else I can try to get TitleKey working with page text search?

That could be due to you needing to do:

```

$wgSearchType = MediaWiki\Extension\TitleKey\SearchEngineMySQL::class;

```

The classname was changed in https://github.com/wikimedia/mediawiki-extensions-TitleKey/commit/a37af77932c71fb32311f73f99a19ba23f18cacc#diff-6a6295f752062fb0eec4a9df4e87c164b8d8d3b48023a54a1e682671296eb8a3R59

I added mention to the docs here about the other DB types as well.

Ah, that was it! Thank you for your help!

We could probably get rid of the requirement to set that at all: T377286

Deprecated: Use of PrefixSearchBackend hook (used in TitleKey::prefixSearchBackend) was deprecated in MediaWiki 1.27. [Called from MediaWiki\HookContainer\HookContainer::register in /www/wiki/includes/HookContainer/HookContainer.php at line 438] in /www/wiki/includes/debug/MWDebug.php on line 386

They are working on it (a bit).

See: https://phabricator.wikimedia.org/T353985

Steps to reproduce:

1. . Install Visual Editor REL1_30 + Parsoid
2. . Create a template like "DummyTemplate"
3. . Edit a page via Visual Editor and select "Insert" -> "Template"
4. . Type first symbol of tempalte name

Expected result: list of found templates is displayed Actual result: nothing is displayed

The reason is that apparently TitleKey is affecting results of "api.php?action=query&format=json&prop=info%7Cpageprops&generator=prefixsearch&gpssearch=P&gpsnamespace=10&gpslimit=10&ppprop=disambiguation&redirects=true" request which VE uses to find templates by name because each found page appears to be missing when TitleKey is enabled and works and intended when TitleKey is disabled.

Oops, indeed a fix for this will be cool. Keeping fingers crossed. I suggest to create a phabricator task for this. I doubt that anybody will have a peep here.

Is this fixed?

Also interested in having a fix for this!

No, this is still not fixed. I just submitted a bug report on it myself after discovering the hard way that it cripples the Template Wizard extension also and any extension that relies on API:Prefixsearch:

https://phabricator.wikimedia.org/T257773

Came here to post this for anyone who might run across the very same frustrating issue and found a 2 year old thread about it. The extension should not cripple the API.

This may now be resolved. TemplateWizard and Titlekey now "play nice" together on 1.39 with search no longer broken. It seems template search in VisualEditor did not use the standard search API:

https://phabricator.wikimedia.org/T274907

https://phabricator.wikimedia.org/T286990

Default behavior of 1.37.2 does what this extension says it does, but that may have to do with setting collation in MySQL to be case insensitive. When this extension is turned on, getting search results while you type does not work. Searching other namespaces does not work.

I could search all namespaces in my search bar but after enabling TitleKey, in order to make queries case insensitive, I can now only search for items in the main namespace. Is there a specific reason why this happens?

Yep, it's indeed something with TitleKey. I disabled it and while I can no longer use case insensitive queries (like "first last" for "First Last" or "first Last"), contents of all namespaces show up again. Kind of a bummer, really...

I found the following (https://www.mediawiki.org/wiki/Manual_talk:$wgEnableMWSuggest#Adding_Namespaces) which tells exactly when the change to only search the Main namespace was enabled. I'm going to try and reverse the patch (it is, after all, 11 years later) and see if functionality returns for all namespaces. I'll let you know what I find out!

Ugh. No, I reversed the patch which did nothing, so I added the namespaces to the array. That made it so that I could type in the namespace name (like Template:) but the only results showing were items in the main namespace (no matter which namespace I tried). It was the same thing after disabling the extension so I re-enabled it, re-edited the file, removed the array and tried rebuilding title keys. Nothing. Could still type, for example, Template: and only results from the main namespace were displayed. After disabling it again, running update.php was the only way to restore the ability to search namespaces other than main. I'd rather be able to search all namespaces efficiently than having case insensitive searches only in the main namespace. Oh well, maybe one day that functionality will be added.

Reversing that patch is necessary, but not sufficient.

There was a refactor of MediaWiki core in 2016 (or possibly earlier) that introduced a bug in the PrefixSearchBackend hook that the extension uses - extensions that use that hook can't suggest pages that aren't in the main namespace.

There's a Gerrit patch that would fix that bug, but it hasn't yet been merged: Gerrit change 641277.

I spent far too long being baffled by this behaviour and trying to track down the cause - hopefully this helps if someone else finds themselves in the same situation.

"With MediaWiki 1.35 or earlier it breaks search suggestions for pages that are not in the main namespace" seems wrong. We had 1.31.15 and the Extension worked fine. After upgrading to MW 1.35.4 we encountered the problem described above: no more search suggestions when typing <namespace>:<searchstring>. I've just removed TitleKey, then namespace search works as expected. Moreover, the search string is still case-insensitive. Seems as if this extension is no longer necessary in MW 1.35.

Hi All,

My site is having problems with search suggestions.

When searching with accents:
https://prnt.sc/r2larq

When searching unsigned
https://prnt.sc/r2latq

Please help me!
Thanks!!!

Answers were provided here.

Thanks all so much!!!

Hi all,

Error search suggest Template in VisualEditor when install TitleKey Extension, please help me.

Thanks!!!

Would it be possible to take this extension one step further and match not just the beginning of the title but the beginning of any word in the title? Or at least make this optional via a configuration parameter. Thanks! NocNokNeo (talk)

search in MW is just horrible out of the box

Filed as task 38203 "Suggestion to merge TitleKey to the MediaWiki core ".

This extension should really be one of those included in the release tarballs, or even better, be merged with the core. --Bachsau (talk) 14:15, 14 April 2012 (UTC)

Agreed, just installed on my project and is working great. Kinda seems like a "no-brainer" to include this in the core.

Agree, it would make the default search engine a bit more decent.

Would it be possible to use this extension to make MW search independent of accents, umlauts and diacritical marks on page titles?

I have a Portuguese installation of MW and users are not being able to find what they are looking for unless the search term has all accents.

What I NEED:

• Accented page title results for unaccented queries: user should be able to search for unaccented terms and get accented results of page titles, so an article named "Estratégia de atuação" would show up on search results for search queries "estrategia" and "atuacao", for instance.

What I would LIKE (but this is not crucial)

• Accent-independent search for article content (as well as title)

What I DO NOT NEED at this time:

• Unaccented results for accented queries

• The normalisation of accents in title search could indeed be handled by the TitleKey extension indeed. I'd recommend creating an issue on bugzilla.wikimedia.org for under "MediaWiki extensions > TitleKey".

• For content search, you'll need to look in the abilities of the "search backend". This is beyond the scope of the TitleKey extension. The default MySQL search backend will likely not be able to support this. Look into Extension:MWSearch for example, and Lucene search.

• TitleKey normalises both the query and the index, so it will naturally work in both "directions" from a user point of view.

Apparently bug 20097 is exactly this, but since it's been there for a while, I am not sure anyone is looking into it.

As a "quick and dirty" fix, I used iconv to work around this problem.

I have patched extensions/TitleKey/TitleKey_body.php by changing the 'normalize' function to:

static function normalize( $text ) {
	global $wgContLang;
	setlocale(LC_ALL, 'pt_BR');
	$newtext = iconv('UTF-8', 'ASCII//TRANSLIT', $text);
	return $wgContLang->caseFold( $newtext );
}

With the new file in place I ran TitleKey/rebuildTitleKeys.php and things seem to be working...

Will post updates here if I notice any undesirable side-effects...

Cheers,

Rbirmann (talk) 00:58, 10 October 2013 (UTC)

UPDATE:

This is not a complete fix. Following my previous example, if the article title is "Estratégia de atuação", after this fix searching for "estrategia de atuacao" finds the article, but searching for "estrategia" or "atuacao" does not. It is something, but still far from a fix.

The quest continues...

You wrote:

This is not a complete fix. Following my previous example, if the article title is "Estratégia de atuação", after this fix searching for "estrategia de atuacao" finds the article, but searching for "estrategia" or "atuacao" does not. It is something, but still far from a fix.

The quest continues...

In my view you must apply the normalize function twice:

1. when generating the table column tk_key in rebuildTitleKeys.php - i.e. when running php rebuildTitleKeys.php
2. and when actually performing the search (what you do)

so that "translit" input values (substrings while typing) are searched against "translit" database column tk_key entries.

Let me know, if that works, and then perhaps you can send me your code, I am interested in that.

I just submitted a working patch based on this talk https://gerrit.wikimedia.org/r/#/c/286580/