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: [[Category:{{{Test}}} Group]]]

On page: Test=Blue
When rendered: [[Category:[[Blue]] 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' __NOAUTOLINKS__ 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:

#0 /usr/share/mediawiki/includes/MagicWord.php(244): Language->getMagic(Object(MagicWord))
#1 /usr/share/mediawiki/includes/MagicWord.php(197): MagicWord->load('MAG_LINKTITLES_...')
#2 /var/lib/mediawiki/extensions/LinkTitles/LinkTitles.body.php(206): MagicWord::get('MAG_LINKTITLES_...')
#3 [internal function]: LinkTitles::removeMagicWord(Object(Parser), '<div class="suc...')
#4 /usr/share/mediawiki/includes/Hooks.php(117): call_user_func_array(Array, Array)
#5 /usr/share/mediawiki/includes/parser/Parser.php(353): wfRunHooks('ParserBeforeTid...', Array)
#6 /usr/share/mediawiki/includes/OutputPage.php(651): Parser->parse('<div class="suc...', Object(Title), Object(ParserOptions), true, true, NULL)
#7 /usr/share/mediawiki/includes/OutputPage.php(1883): OutputPage->parse('<div class="suc...', true, true)
#8 /usr/share/mediawiki/includes/specials/SpecialPreferences.php(574): OutputPage->wrapWikiMsg('<div class="suc...', 'savedprefs')
#9 /usr/share/mediawiki/includes/specials/SpecialPreferences.php(126): PreferencesForm->mainPrefsForm('')
#10 /usr/share/mediawiki/includes/specials/SpecialPreferences.php(15): PreferencesForm->execute()
#11 [internal function]: wfSpecialPreferences(NULL, Object(SpecialPage))
#12 /usr/share/mediawiki/includes/SpecialPage.php(771): call_user_func('wfSpecialPrefer...', NULL, Object(SpecialPage))
#13 /usr/share/mediawiki/includes/SpecialPage.php(559): SpecialPage->execute(NULL)
#14 /usr/share/mediawiki/includes/Wiki.php(229): SpecialPage::executePath(Object(Title))
#15 /usr/share/mediawiki/includes/Wiki.php(59): MediaWiki->initializeSpecialCases(Object(Title), Object(OutputPage), Object(WebRequest))
#16 /usr/share/mediawiki/index.php(116): MediaWiki->initialize(Object(Title), NULL, Object(OutputPage), Object(User), Object(WebRequest))
#17 {main}

Hast du eine Idee, woran das liegen könnte? (Jonas)

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 LinkTitles.i18n.magic.php 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)

Hallo Zusammen, ich habe den selben Fehler mit: LinkTitles 3.1.0, MediaWiki 1.15.1, PHP 5.5.32 (cgi-fcgi), MySQL 5.5.46-log. Gibt es mittlerweile schon eine Lösung dafür? Lg Marco 22:55, 19 February 2016 (UTC)

Slight problem with parsing

I just discoverd a problem with the parser. It parses text inside <code> and <pre> tags and then converts them to links. This causes the resulting output to show the brackets and link text INSIDE a block where links will never be parsed.

(For some reason I cant currently log in, I think I forgot the password, but I will check back. By the way, look at my next topic.) ok my sig now C.Jason.B (talk) 20:50, 6 July 2013 (UTC)

This looks feasible, I just need to find time to edit the code. -- Bovender (talk) 19:04, 7 July 2013 (UTC)

Added Functionality

By the way I am the user who changed the testing tag to include 1.21. I've been abusing it on this wiki for over a week flawlessly except for the whole pre and code thing.

I needed this extension to work accross several namespaces for a project I am working on. Before this I had ZERO experience writting PHP code.

I have now modified the extension to accept the following:

• Crossnamespace linking is de-activatable by setting whitelist to include only namespace 0
• A whitelist of namespaces to link against. (If set to include only '0', it over rides the cross namespace thing)
• A weighted list of the priority of the namespaces to link against (Current namespace is always top priority)
• Boolean flag that checks for reorder teh namespace weights based on user group membership
• Additional weight lists which modify the primary one if the above flag is true

Since I have been coding php for 3 days only, my codding skills kinda suck, but:

• It works
• It has caused no errors with extensive testing (save the problem I reported previously, but I dont know if it is caused by yours or mine)(I assume both since I didnt modify the search part of the code at all)

Would you like the code? I have a dump e-mail account at aragornnrogara at Yahoo if you want to drop me a line and have me send it to ya. All the features are able to be switched off, so it cant hurt to have them.

Since it took me almost three full days to write under 100 lines of code, I probabgly wont be maintaining this, but I thought others might want the added functionality.

The only core functionality I altered is in the two callback functions, added a parameter to the main parse function ( I had it pass on the user) and altered [[$1]] in the parser.

Also since your skills are far superior to mine, I told it to simply return true if it encountered a page in the database of the form

  Page/subpage/subpage  or deeper

(an IF that checks for subst_count of "\/" being more than 1 right after you had it create safe_title or watever it was called.)

OK, my sig now

C.Jason.B (talk) 20:51, 6 July 2013 (UTC)

Are you familiar with Git? If so, you could issue a pull request on the repository at https://github.com/bovender/LinkTitles -- otherwise, if you want you may send me the code at xltoolbox at gmx net. -- Bovender (talk) 19:07, 7 July 2013 (UTC)

You may flog me now, with 10+ years using linux I have no idea how to use either subversion or git. I responded to your email adress (ignore the mysql question sent later) C.Jason.B (talk) 10:23, 10 July 2013 (UTC)

Sent you the code via your email. This is a bug fix and hopefully no new ones crawled in. There is a text doc in the file suitable for pasting into a wiki the update info in it. I suggest sandboxing it a while, i am still testing. This turned into a complete rewrite of my code so the changes to all of it are now many, but well documented (maybe to much) and default state is meant to run as a drop in replacement for the original. Also most of my stuff is in fuctions, so if a problem crops up it is easily locked out.C.Jason.B (talk) 10:23, 10 July 2013 (UTC)

A bug crept in

In the code I sent you, line 126 should read

if(count($wgLinkTitlesNamespaceNOAUTOLINKS) > 0) {

C.Jason.B (talk) 13:20, 10 July 2013 (UTC)

Link Titles Bug (Current version w/ mediawiki 1.21)

When editing a page which contains a full wiki link [[Namespace:pagename|display text]] and in the MAIN namespace a document titled text exists (using the link I gave for an example). The resulting output will be [[Namespace:pagename|display[[text]]]]

I discovered this while editing this wiki text:

{| style="[[:MW version/color|color]]:#000000; border:solid 1px #A8A8A8; padding:0.5em; margin:0.5em 0; background-[[:MW version/color|color]]:#FFFFFF;font-size:95%; vertical-align:middle;"
| style="padding:1em;width: 40px" | [[Image:Attention niels epting.svg|50px|link=]]
| {{#if:{{{text|}}}|{{{text}}}|The page {{SUBPAGENAME}} is a stub in the {{NAMESPACE}} namespace.  It is intended to have detailed content.  Please add Detail here if you are able, and have the required skills and knowledge. }}
| style="padding:1em;width: 40px" | [[Image:Attention niels epting.svg|50px|link=]]
|}

In my wiki the word skills exists as a title in NS_MAIN and in another namespace. I manually linked to the other namespace but after clicking the save button the link was [[Development:skills|[[skills]]]]

At first I thought this was due to my modifications of the code for the extension. But I pulled my version down and put the original back up, and was able to duplicate the result after clearing all caches.

I tracked the problem to the SmartLinks phase. In the main for loop you begin with $i=0 and increment by 2, this causes the error (I believe because the very first character on the page is a { ) When I rewrite that code to be $i=1 it works fine for this page, but fails everywhere else.

Proposal: Prior to the loops instantiation, check the value of subst($text,0,1) for regex match on $deliminator. If it fails set $init=0, if it matches (first char in $text is a wiki text component) set $init=1, then at the loop:

for($i=$init; $i < count($arr); $i +=2){

Unless you know a better way, I will experiment along these lines for a couple of days.C.Jason.B (talk) 05:08, 11 July 2013 (UTC)

As it turns out, this bug only seems to crop up when the extension parses template contents. If that is set to True, then the bug can occur as it seems to also reparse links. I'm not sure about the links thing, but since I turned off the parse templates feature the bug hasn't recurred. It appears my entire previous premise was false. C.Jason.B (talk) 06:36, 19 July 2013 (UTC)

Batch change

Is it possible to run this script automatically? My wiki site expands and I'd like to run LinkTitles for all the pages from time to time. It has already over 3000 pages, so doing this manually is a bit difficult. It would be great to run it during the night time.

As far as I know, it is not possible to schedule tasks in MediaWiki (I might be wrong). What I can imagine is a Special Page that could be used to trigger an automatic link scan of all pages. One would have to consider runtime limitations on shared servers though. -- The problem here is that I have extremely little time to think about this extension at the moment, but I'll try and come up with something. -- Bovender (talk) 13:52, 31 December 2013 (UTC)

Self Linking via Redirects

First off, thank you for this extension. This is easily one of the most useful extensions I have found since I have been using MediaWiki. Now onto my question. I noticed that LinkTitles will not cause a page to link to itself (which makes sense, given that the title of a page is generally going to be mentioned several times in the body) however it will link to a redirect that links back to that page.

EXAMPLE: In my wiki there is a page called Enclave. There is also an Enclaves page which redirects to Enclave. The enclave page skips the word enclave when generating links but creates a link for each instance of Enclaves which essentially links back to itself.

Would it be possible to have this extension check the redirects before generating the link to avoid it linking to itself?

Thanks.

EDIT AFTER UPDATE: Wow that was faster than I expected. You are awesome.

Version 2.4 with major new features

Today I released version 2.4 which proffers several new features that people have been asking for on this page:

• Prevent linking of pages that redirect to the current page.
• Prevent linking in PRE segments and in attributes of DIV and SPAN elements.
• Offer batch processing (by means of a Special:LinkTitles page and as a maintenance script to be run from the command line).

I still have the namespaces on my to do list. -- Bovender (talk) 15:45, 6 June 2014 (UTC)

Version 3 released

I was unhappy with the performance, which decreased due to recent feature additions. So I changed the algorithm quite a bit, which resulted in an ~10x increased speed on my machine. Release 3.0.0 is available for download now.

Error on Batch Processing

When running the Batch Processing via the Special Page I see a blank page with the following (with my server name removed): Fatal error: Call to undefined method WikiPage::getContent() in /MyServer/extensions/LinkTitles/LinkTitles.body.php on line 254

UPDATE: So it turns out I just needed to upgrade my MediaWiki (Thought I had the latest version. Apparently not.) the Batch Processing now works like a charm. I'll leave this here in case someone else has the same issue.

Error UTF8?

I tried to install the newest Version on MediaWiki 1.23.6. But i get some Error like: PHP Warning: preg_replace_callback() [<a href='function.preg-replace-callback'>function.preg-replace-callback</a>]: Compilation failed: invalid UTF-8 string at offset 33 in /srv/mediawiki/extensions/LinkTitles/LinkTitles.body.php on line 226 The activated Extension destroys the Wiki-Pages (style and format) ... please help :) thanks ... The Database is MariaDB10.0, Database-Type is INNODB, Tables are in LATIN1 and BINARY Format. $wgDBmysql5 is set to TRUE in localsettings.php all mediawiki tables are UTF8_unicode_ci and binary ...

kind regards Gerd --192.166.53.201 10:01, 25 November 2014 (UTC)

the same problem with this extention, other parametres the same too exept version - 1.24

I just got the same problem. Has there been any update to resolve this? 11/13/2015

I got it not working correctly. Rather making my page almost blank (16-11-2015)

Prevent LinkTitles to link inside Graphviz

Hi! My Graphviz DOT graph labels were vandalized sometimes by LinkTitles, so I added an exception to $delimiter at rule 134 inside LinkTitles.body.php.

I have added the following line: '<graphviz>.*?<\/graphviz>|'. // graphviz

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 20241102192615)

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)

Unable to run batchmode

If I try to run in batchmode (i.e., php LinkTitles.cli.php), I get the following error...not sure what could be causing it or how to fix. Please help!

Processing 5744 pages, starting at index 0... Page #1 (00%)[6aa514b5] [no req] MWException from line 337 of /var/www/www.hindupedia.com/htdocs/eng/includes/MagicWord.php: Error: invalid magic word 'MAG_LINKTITLES_NOAUTOLINKS' Backtrace:

1. 0 /var/www/www.hindupedia.com/htdocs/eng/includes/MagicWord.php(262): MagicWord->load(string)
2. 1 /var/www/www.hindupedia.com/htdocs/eng/extensions/LinkTitles/LinkTitles.body.php(91): MagicWord::get(string)
3. 2 /var/www/www.hindupedia.com/htdocs/eng/extensions/LinkTitles/LinkTitles.body.php(270): LinkTitles::parseContent(Title, string)
4. 3 /var/www/www.hindupedia.com/htdocs/eng/extensions/LinkTitles/LinkTitles.cli.php(108): LinkTitles::processPage(string, RequestContext)
5. 4 /var/www/www.hindupedia.com/htdocs/eng/maintenance/doMaintenance.php(103): LinkTitlesCli->execute()
6. 5 /var/www/www.hindupedia.com/htdocs/eng/extensions/LinkTitles/LinkTitles.cli.php(117): require_once(string)
7. 6 {main}

No autolinks by namespace

Hi! Love this extension - very useful, especially for non-wiki users. Reading the posts above, it looks as though there has been some work to limit the scope of LinkTitles so it only parses (on render) pages within the Main namespace (and not Forms, or Special:Form Edit, as defined by Semantic Forms). Is this code available / stable? Thanks!

Version 4 finally has support for namespaces! -- Bovender (talk) 19:31, 23 November 2016 (UTC)

Latest compatible version with MW 1.23?

What is the latest compatible version with MW 1.23? --Spiros71 (talk) 09:01, 14 August 2017 (UTC)

3.1.0. Regards, Bovender (talk) 10:54, 14 August 2017 (UTC)

Thank you very much!

Do not parse specific fields of a template

I have a template whose output with text looks like this (other templates may be in the same page too but with no restrictions):

{{LSJ1
|Full diacritics=ὑποχωρέω
|Medium diacritics=ὑποχωρέω
|Low diacritics=υποχωρέω
|Capitals=ΥΠΟΧΩΡΕΩ
|Transliteration A=hypochōréō
|Transliteration B=hypochōreō
|Transliteration C=ypochoreo
|Beta Code=u(poxwre/w
|Definition=text to be autolinked here
}}

Is it possible to have the extension autolink only content in the "Definition" field of this template? Do I guess right that if a word is contained in the text, which is the same as the page title, it will not be autolinked anyway?

Sorry for the late response. With the new version 5, it is indeed possible to define sections that may or may not be autolinked. Use the <autolinks>...</autolinks> and <noautolinks>...</noautolinks> tags for that. In your case, you may want to wrap the entire template in <noautolinks>...</noautolinks> tags and use the <autolinks>...</autolinks> only for the 'Definition' field. Yes, it's possible to nest these tags. Of course, this only really makes sense if you are dealing with automatically (or user-supplied) text. Otherwise, it would certainly be easier to add the links [[...]] yourself, rather than making the effort to add the tags. (See this discussion). -- Yes, you guess right, an article is not linked back to itself (there is even an option to check for redirects that loop back to the page). -- Bovender (talk) 03:51, 7 September 2017 (UTC)

Thanks for the reply! I am testing 3.1.0 on MW 1.23.17 but when I edit a page I get: Gateway Timeout / The gateway did not receive a timely response from the upstream server or application. / Additionally, a 504 Gateway Timeout error was encountered while trying to use an ErrorDocument to handle the request.--Spiros71 (talk) 17:55, 22 September 2017 (UTC)

Spiros, it's really hard to tell what is going on there. Not to sound mean or anything, but the LinkTitles extension has arrived at version 5, and MediaWiki at 1.29, with anything older than 1.26 not being supported any more. I don't have the resources to maintain an old version of the extension for an unsupported MediaWiki version. However, I'd be happy to have a quick look at it, maybe it's something that can be easily fixed. I would need some more information on the error though, do you find anything in the logs that could help? (By the way, I just released version 5.0.4 which fixes an important bug in the version 5 series; just in case you have that installed somewhere else.) Best, Bovender (talk) 05:32, 23 September 2017 (UTC)

Hello, about this. I'm using Page Forms (4.3.1) with LinkTitles (5.0.7) and MediaWiki 1.31.1 but I don't know how to use the <noautolinks>...</noautolinks> trick in my template creation. Here is the bit I'd like to automatically add the tags to : {{{field|image|placeholder=Recopier exactement le même nom de fichier que sur Wikimedia Commons (sans "File:" mais avec extension)}}} To be honest, I'm not sure that's doable. Thank you for the answer. -DSwissK (talk) 20:43, 13 December 2018 (UTC)

Can I specify a username and comment from command line?

When I run the linktitles-cli.php script from the command line, is it possible to pass a parameter with the username I'd like the edits to be made under? Currently it is made as user 127.0.0.1. Also, is it also possible to have another parameter for the text to put in the comment?

Cannot select this to add to my wiki. How come?

I tried looking around for some more info on LinkTitles, but I can't find any. The little box next to the extension is gray and I want to know why this is.