Extension talk:TitleKey

About this board

archive of previous talk

Breaks VisualEditor autocompletion for templates

Vedmaka (talkcontribs)

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.

Kghbln (talkcontribs)

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.

FreshVegetarian (talkcontribs)

Is this fixed?

Tguiot (talkcontribs)

Also interested in having a fix for this!

TiltedCerebellum (talkcontribs)

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:


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.

FrozenPlum (talkcontribs)
Reply to "Breaks VisualEditor autocompletion for templates"

1.37.2 not working

2A00:A040:197:15B:48F6:FAD0:E5C7:E9F7 (talkcontribs)

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.

Reply to "1.37.2 not working"

Can no longer search other namespaces

Bttfvgo (talkcontribs)

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?

Bttfvgo (talkcontribs)

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...

Bttfvgo (talkcontribs)
Bttfvgo (talkcontribs)

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.

Alanhuang122 (talkcontribs)

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.

2003:C2:3F22:8200:88FF:1B74:E990:1633 (talkcontribs)

"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.

Reply to "Can no longer search other namespaces"

Error suggesting search results with accents (UTF-8)

Xuanthucit (talkcontribs)
Kghbln (talkcontribs)

Answers were provided here.

Xuanthucit (talkcontribs)

Thanks all so much!!!

Reply to "Error suggesting search results with accents (UTF-8)"

Error search suggest Template in VisualEditor

1 (talkcontribs)

Hi all,

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


Reply to "Error search suggest Template in VisualEditor"

One step further: search suggestions for matching '''any word''' in the title

NocNokNeo (talkcontribs)

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) (talkcontribs)

search in MW is just horrible out of the box

Reply to "One step further: search suggestions for matching '''any word''' in the title"

Include in Release

Summary last edited by Kghbln 20:52, 11 November 2016 7 years ago

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

Bachsau (talkcontribs)

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)

FlightTime (talkcontribs)

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

Sophivorus (talkcontribs)

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

Reply to "Include in Release"

Accent and special characters independent search

Rbirmann (talkcontribs)

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
Krinkle (talkcontribs)
  • 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.
Rbirmann (talkcontribs)

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...


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


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...

Wikinaut (talkcontribs)

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.

Sophivorus (talkcontribs)
Reply to "Accent and special characters independent search"

Method to setup without shell access

Jamesmontalvo3 (talkcontribs)

On my production server I do not yet have shell access, so I had to work around this. I wrote the following script to be used over HTTP to add the required MySQL table and populate it with data. This script worked in my environment and is not guaranteed to work on yours. It is certainly not the most robust code possible. MediaWiki/Titlekey developer gurus: please feel free to comment on any erroneous content. Hope this helps!


 *  Before you use this script please note that this was created by a person
 *      inexperienced with the inner workings of MediaWiki. It was created to
 *      get around the problem of not having command line access on a 
 *      particular server with a specific MediaWiki load with specific 
 *      extensions. THIS MAY NOT WORK ON YOUR COMPUTER. Anyone who knows more
 *      about MediaWiki please feel free to edit mercilessly.
 *  I've tried to write this script without any dependencies so it should run
 *      on just about any PHP load. However, this abysmally slower than using
 *      the standard rebuildTitleKeys.php script from the command line. If your
 *      wiki is large this script may not work for you (without vastly 
 *      increasing max_execution_time in php.ini).
 *  Note on implementation: titlekey.sql says tk_key is "with namespace prefix"
 *      which seems to me that titles should be recorded like with the prefix
 *      like "Template:Citation needed" instead of just "Citation needed".
 *      However, my inspection of the Titlekey extension indicates that prefix
 *		is not included.
 *  Input your database host name, username, password and database name below.

$hostname = "YOUR HOST NAME";
$username = "YOUR USERNAME";
$password = "YOUR PASSWORD";
$db_name  = "YOUR DATABASE NAME";

 *  No changes should be required below this point...unless I made a mistake.

echo "Connecting to database...";

// Connect to database 
$db = mysql_connect($hostname, $username, $password)
    or die ('Unable to connect. Check you connection parameters.');

// Select particular database
mysql_select_db($db_name, $db)
    or die(mysql_error($db));

echo "connection successful.<br />";
// Construct query to retrieve all relevant page information from standard
// MediaWiki table 'page'
$query = "SELECT page_id, page_namespace, page_title FROM page";

echo "Retrieving page information...";

// Perform query to retrieve page information
$result = mysql_query($query, $db) or die (mysql_error($db));

echo "page information retrieval successful.<br />";

// Loop through pages (for each result create associative array $page)
while( $page = mysql_fetch_assoc($result) ) {

     *  Page names from the standard MediaWiki table 'page' must be reformatted
     *      to be searched quickly and easily with case-insensitivity. Three
     *      actions must be performed on the page title:
     *      1) Replace all underscores with spaces using PHP's str_replace
     *      2) Convert all characters to upper case using PHP's strtoupper
     *      3) Always escape characters before inserting into a database
    $titlekey_page_name = mysql_real_escape_string(
            str_replace("_", " ", $page['page_title'])

    // Create a string of SQL values to be inserted into the new titlekey
    //      table. String is pushed to $inserts array to be used later.
    $inserts[] = '(' 
        . $page['page_id'] . ', ' 
        . $page['page_namespace'] . ', ' 
        . '"' . $titlekey_page_name . '"'
        . ')';

// Take $inserts array (array of strings) and glue them together with ", "
//      in between each string.
$inserts = implode(', ', $inserts);

 *  Build the full insert query. The new table 'titlekey' has columns:
 *      1) titlekey.tk_page corresponds to page.page_id
 *      2) titlekey.tk_namespace corresponds to page.page_namespace
 *      3) titlekey.tk_key corresponds to page.page_title
 *          (in all caps, no underscores)
$insert_query = 
    'INSERT INTO titlekey
        (tk_page, tk_namespace, tk_key)
    VALUES ' . $inserts . ';';
// if titlekey table does not yet exist, create it
$create_table_query = 
        -- Ref to page_id
        tk_page int unsigned NOT NULL,

        -- Keep a denormalized copy of the namespace for filtering
        tk_namespace int NOT NULL,

        -- Normalized title.
        -- With namespace prefix, case-folded, in space form.
        tk_key varchar(255) binary NOT NULL,
        PRIMARY KEY tk_page (tk_page),
        INDEX name_key (tk_namespace, tk_key)


echo "Creating table 'titlekey' (if required)...";

// Execute query to add titlekey table
mysql_query($create_table_query, $db) or die (mysql_error($db));

// In case titlekey already existed and had data in it, remove all data prior
//     to repopulating.
mysql_query("TRUNCATE TABLE titlekey;", $db) or die (mysql_error($db));

echo "table created.<br />Inserting pages into 'titlekey' table.";

// Execute query to insert values into new titlekey table
mysql_query($insert_query, $db) or die (mysql_error($db));

// Close database connection

echo "<br /><br />Update operations complete.";
Nakohdo (talkcontribs) (talkcontribs)

Yeah I looked into MaintenanceShell, but in general I don't use extensions marked "experimental" on my production server.

This post was posted by, but signed as Jamesmontalvo3.

Nakohdo (talkcontribs)

But if the alternative is using a PHP script for direct database access with database credentials in plain text this might be an option to be considered ;-)

Jamesmontalvo3 (talkcontribs)

This is intended as a run-once-and-delete script...as opposed to having MaintenanceShell, an experimental extension which exposes shell-like privileges, running full time on your production server. It's a trade off of whether you trust yourself to scan through my intentionally simplified code or trust the creators of MaintenanceShell to not leave security holes and possible data-corrupting bugs.

Nakohdo (talkcontribs)

I tried another extension which works with MediaWiki 1.20.2, Extension:Maintenance (beta).

As the rebuildTitleKeys.php file doesn't reside in the default /maintenance folder you have to add the following to your LocalSettings.php:

$wgMaintenanceScripts = array(
  'rebuildTitleKeys' => "$IP/extensions/TitleKey/rebuildTitleKeys.php",


Then you can add the following section to the Maintenance extension's metadata.ini file:

enabled = 1


Then you should be able to run the Title Key update from the Maintenance extension page.

Reply to "Method to setup without shell access"

Adding data to the search

2 (talkcontribs)

how can i add data whith search text.the is stored into database please help me. (talkcontribs)

add data with search text.The data is in the database.Data is like jobposition,location.

Reply to "Adding data to the search"