Extension talk:LinkTitles/Archive

Category Linking
This is a great extension, and is perfect for what I'm using. There is one minor issue I've found, however. When I'm using my template to auto-generate categories, and one of the names of the categories also is a link, it puts a link in the category syntax and breaks the creation of the categories. (I'm not sure if this happens if the category is manually created, I have not actually had the chance to look at it. Here is what I'm talking about, in case what I'm saying isn't clear.

Template: ]

On page: Test=Blue When rendered: Group]]]

I have fixed this for now by just black-listing the pages so they don't auto-link, but I would like to see an exclusion for things in a Category bracket. (I know, it can get tricky to do, but it's a suggestion) ^.^

--Taintedsnowqueen (talk) 20:12, 8 October 2012 (UTC)


 * Well if I understand you correctly, the problem is that the extension parses template parameters. I've quickly added a new option "$wgLinkTitlesSkipTemplates" that lets you control this behavior. Please see the main extension page to read more about it. The downside is that this setting will prevent all template contents from being automatically linked; but there is currently no other way that I can think of how to accomplish what you want. Is it what you want? -- Bovender (talk) 17:51, 9 October 2012 (UTC)


 * Sorry it took so long to get back. It wasn't exactly what I was looking for, but it is a decent work-around. (It wouldn't work for my purposes, since I mostly use templates in my wiki to generate content). After giving it a decent amount of thought, I've realized that because of how templates & this extension work, it is likely that setting is the only way to get the issue to stop. Thanks for the setting! :) Taintedsnowqueen (talk) 23:43, 1 November 2013 (UTC)

Case of linking
This is really hurting me. I hate to have to create a stub redirect for all of the items. I have lots of articles that have two words with both being capitalized. I would like the option to search exact, then case-insensitive. I know this would double the load, but it would vastly help. - - - ''The extension performs a case-insensitive regexp search. Therefore, brackets may be added to words that have incorrect capitalization, causing 'broken' wiki links to appear. You may want to create redirecting pages for these variants (to also handle different user inputs).'' -- Philipsaj


 * Hi, I've added a new option $wgLinkTitlesIgnoreCase and published version 1.7.0, but I'm afraid there will be no solution that satisfies all needs. The problem is that all articles in a Wiki begin with a capital letter, thus, if you had an article "Snow" and set $wgLinkTitlesIgnoreCase to false (meaning an exact match is required to link a title), none of the occurrences of the word "snow" in an English article about the winter would be linked. That's the reason why I had the extension perform a non-configurable case-insensitive search and replace in the first place. If I understand you correctly, you have lots of articles on "Snow Flakes" and "Snow Men". With case-insensitive linking, all occurrences of "snow flakes" and "snow men" would link to non-existing pages. I guess that's your problem, right? But how about writing "Snow Flakes" and "Snow Men" in your articles' texts in the first place? Would that not be more practical? -- Bovender (talk) 16:03, 22 January 2013 (UTC)


 * Thank you for your quick response and help! I appreciate your help and you understand the situation quite well in regards to the article titles and the challenge I face.  I'm sure my problem sounds easy and simplistic to fix, unfortunately I wish your suggestion for a fix was as easy to implement.  It is not just me doing the editing, but hundreds of people.  Many of which are extremely limited in their understanding of what they are doing, but they hold the knowledge we are trying to get recorded.  I think the only solution is a two part scan of the text.  I guess I need to find an extension that will scan my text and switch the case insensitive matches to the correct case that matches the article...  I really appreciate your extension and how it helps my wiki.  Thanks for your help.  -- Philipsaj 7:44, 23 January 2013 (CST)


 * Well I think I got it now. What is needed is automatic aliasing if the case of a page title and the case of its occurrence on the page do not match, so that link such as Snow ball are generated. I've added this functionality to the version 1.8.1 which I uploaded just now. You are probably right that a two-pass algorithm would be more useful, so that case-sensitive matches are preferred. I'll think about this further. Bovender (talk) 17:48, 26 January 2013 (UTC)


 * Version 2.0.0 of the extension should do what you requested, and I think it's a much better way to do the linking than before: First, a case-sensitive search for page titles is performed (with the exception of the first letter of a page title, which is searched for in a case-insensitive way). In a second pass, a case-insensitive search is performed, and 'piped' links "..." are added as needed. If you find that this two-pass mechanism slows down your wiki, you can turn off this behavior by setting $wgLinkTitleSmartMode = false. Hope this helps! -- Bovender (talk) 20:29, 29 January 2013 (UTC)

Blacklist pages
Thanks for this extension, it really helps when working with people that haven't grasped yet that a Wiki is there for linking contents. However, we have pages where we would like to have no links at all. So it would be cool if you considered to add a blacklist parameter for pages based on their titles analogously to the word based blacklist. What do you think of that idea? (Jonas)
 * Hi Jonas, that should be feasible. I wonder whether the best way to implement this would be a blacklist array in the config file, or something like a "__NOLINKTITLES__" command in the content of the page. Or both. Bovender (talk) 19:14, 14 February 2013 (UTC)
 * Uh, quick, cool :). I think it would be better to have a directive because then each author can specify that and not only the server admin who can access the config file. Both could also be an option to have administrative prescriptions that are not editable. In the case you would do both it would probably make sense to have flags that (de-)activate them.
 * Jonas, I've added a new 'magic word'  which can be added to a given page to prevent the extension from adding links. It's in the new 2.1.0 release. Hope it suits your needs! -- Bovender (talk) 13:23, 23 February 2013 (UTC)

Wir haben das Update installiert, bekommen aber eine Exception von unserem Wiki (es handelt sich um das Paket 'mediawiki 1:1.15.5-2squeeze5' aus Debian Squeeze - meinst du es könnte ein Problem sein, dass wir nicht 1.18 haben?) : Magic word 'MAG_LINKTITLES_NOAUTOLINKS' not found

Backtrace:

Hast du eine Idee, woran das liegen könnte? (Jonas)
 * 1) 0 /usr/share/mediawiki/includes/MagicWord.php(244): Language->getMagic(Object(MagicWord))
 * 2) 1 /usr/share/mediawiki/includes/MagicWord.php(197): MagicWord->load('MAG_LINKTITLES_...')
 * 3) 2 /var/lib/mediawiki/extensions/LinkTitles/LinkTitles.body.php(206): MagicWord::get('MAG_LINKTITLES_...')
 * 4) 3 [internal function]: LinkTitles::removeMagicWord(Object(Parser), 'parse('parse('wrapWikiMsg('mainPrefsForm('')
 * 11) 10 /usr/share/mediawiki/includes/specials/SpecialPreferences.php(15): PreferencesForm->execute
 * 12) 11 [internal function]: wfSpecialPreferences(NULL, Object(SpecialPage))
 * 13) 12 /usr/share/mediawiki/includes/SpecialPage.php(771): call_user_func('wfSpecialPrefer...', NULL, Object(SpecialPage))
 * 14) 13 /usr/share/mediawiki/includes/SpecialPage.php(559): SpecialPage->execute(NULL)
 * 15) 14 /usr/share/mediawiki/includes/Wiki.php(229): SpecialPage::executePath(Object(Title))
 * 16) 15 /usr/share/mediawiki/includes/Wiki.php(59): MediaWiki->initializeSpecialCases(Object(Title), Object(OutputPage), Object(WebRequest))
 * 17) 16 /usr/share/mediawiki/index.php(116): MediaWiki->initialize(Object(Title), NULL, Object(OutputPage), Object(User), Object(WebRequest))
 * 18) 17 {main}
 * Hi Jonas, es hatten sich ein paar Dinge eingeschlichen, die mit PHP < 5.3 Probleme verursacht haben. Das habe ich jetzt behoben (Version 2.1.1). Kann sein, daß das Euer Problem schon löst. Habt Ihr sicher die mit 2.0.0 neu eingeführte Datei  auf dem Server? Falls es immer noch Probleme gibt, bitte Rückmeldung! -- Bovender (talk) 18:07, 6 March 2013 (UTC)
 * Moin, ich hab eben das repo aktualisiert und die magic-Datei ist auch da, aber es kommt immernoch die Exception. PHP hat bei uns Version 5.3 (5.3.3-7+squeeze15). Die Exception kommt übrigens auch beim Aufrufen, sprich anschauen von Seiten, nicht nur wenn man beim editieren speichern will. Falls ich irgendwelche Experimente/Dumps/Traces beisteuern kann, die dir helfen würden, lass es mich wissen.
 * Endlich bin ich dazu gekommen, den Fehler zu reproduzieren. In einer virtuellen Maschine mit Ubuntu Server 12.04 (64-bit), PHP 5.3.10 und dem alten MediaWiki 1.15.5 bekomme ich denselben Fehler. Wenn ich dann einfach die aktuelle MediaWiki 1.20.3 darüber spiele (und die StartProfiler.*-Dateien aus dem Wiki-Rootverzeichnis lösche, die beim Update zu Fehlermeldungen führen), funktioniert die Extension. Es hängt also von der Version ab. In zwei weiteren Wikis (lokal mit PHP 5.4.6-1ubuntu1.1/MediaWiki 1.17.0 und im Web mit PHP 5.2.6-1+lenny16/MediaWiki 1.18.0) klappt es ebenfalls problemlos. Bislang habe ich nicht herausgefunden, warum es mit MediaWiki 1.15.5 nicht funktioniert; die ChangeLogs geben dazu m.E. nichts her. Der naheliegende Workaround besteht in einem Upgrade Eures Systems... aber das ist ja oftmals keine praktikable Lösung. Ich muß weiter forschen. -- Bovender (talk) 15:34, 15 March 2013 (UTC)

Slight problem with parsing
I just discoverd a problem with the parser. It parses text inside  It may be nice to add this addition to future versions, together with a kind of short manual to skip certain tags (from other extensions).

Regards from the Netherlands! Martie (80.246.200.234 )

How to automatically add links to Chinese words?
The matched content is displayed in Chinese. How to do?

Excluding links
i have metadiscriptions in the top of my pages and dont want them between brackets. i have some issues with posting them on facebook for instance. how can i exclude an portion of the page/text so this isnt an issue anymore?

Compatibility with Extension:CategoryTree ?
I'm not quite sure, but I believe that i have found a compatibility issue with Extension:CategoryTree. I recognized that on certain sites, the auto-linking after editing a site does not work properly, while it normally does. The only difference between these sites and the ones where auto-linking does actually work is that i have used the categorytree-tag from the abovementioned Extension on these sites. After doing so, LinkTitels does not any more auto-link pagenames, that are contained in the categorytree. Sounds strange? Indeed. But i was able to reproduce the problem a few times. And after deleting the categorytree, auto-linking returned to normal behaviour. In fact, auto-linking worked on the sites with categorytree too, but only above the categorytree and not below it. Is that possible or am I maniac? ;-)

By the way: I'm using

MediaWiki 1.24.1

PHP 	5.5.22 (cgi-fcgi)

MySQL 	5.5.42-log

and

LinkTitles	3.1.0

CategoryTree does not specify its version on the special:version site.

Performance with LinkTitlesParseOnRender = true
Hello LinkTitles developers and users,

We don't want hard coded links in our Wiki, that's why we use "ParseOnRender = true". Is it possible to preprocess the pages for our logged in users to render the cache in advance and deliver already parsed pages? Squid is not an alternative for us as far as I understood...? because our users need to be logged in. Would somebody be so kind to share their experience with LinkTitles performance optimization? What did you install? PHP-Accelerators? Which settings where the best for you? Apache/PHP settings? Mediawiki cache settings?

LocalSettings.php
 * require_once( "$IP/extensions/LinkTitles/LinkTitles.php" );
 * setlocale( LC_ALL, "en_US.UTF-8" );
 * $wgLinkTitlesParseOnRender = true;

My installation:
 * Apache/2.4.10 (Debian)
 * DB-Client Version: libmysql - 5.5.44
 * PHP-Extension: mysqli
 * Wiki pages: ~3500 (growing fast)
 * PHP cache = default
 * Mediawiki = CacheType = CACHE_ACCEL

A purge on our largest page takes 1min+ ... :(

Thanks in advance

Formatting gets completely lost
I have this problem when I save a page. The formatting completely changes and huge chunks of content get even lost. I can't tell why this is happening, I have various extensions installed like "CategoryTree", "PdfBook", "Approved Revs", "Lockdown"... Maybe it's some compatibility issue. I use MediaWiki 1.25.1 with PHP 5.4.43-1 and MySQL version 5.5.44 on Ubuntu 12.04 Hope someone can help me cheers

Bug w/ multi-byte characters
There is a bug where the extension doesn't recognize UTF8 characters and will create links mid-words (it thinks that a character w/ a diacritical mark is an end-of-word marker i.e., ṃ). Please help.

Example:

Ahiṃsā => Ahiṃsā

(using single quotes to hopefully not get it to parse here.

Example of page where this is happening is Ahiṃsā

Also, does it reparse existing links? E.g., once this issue is fixed, can I just re-run the CLI version of LinkTitles and it will fix these partial links?

Please help. Kkm5848 (talk) 18:18, 6 December 2015 (UTC)

Takes too long to run
We have over 3000 articles and this script takes more than 30 seconds to run every time an article is saved. Is there any way to improve its run time further so that it can run on save instead of turning it off and only running in batch mode.

FYI, prior to our upgrade from Mediawiki 1.16.5 we were using the Autolink extension which was a much more efficient in doing the same. Do you know why it was more efficient?

Kkm5848 (talk) 05:08, 7 December 2015 (UTC)