Last modified: 2014-05-10 04:21:45 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 10237 - #ifexist for interwiki links
#ifexist for interwiki links
Status: NEW
Product: MediaWiki extensions
Classification: Unclassified
ParserFunctions (Other open bugs)
unspecified
All All
: Low enhancement with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on: 11 20646
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-13 00:37 UTC by Dominic
Modified: 2014-05-10 04:21 UTC (History)
10 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Dominic 2007-06-13 00:37:33 UTC
Currently, #ifexist does not work for interwiki links. No template call on, say, Wiktionary can tell whether a page on Wikipedia exists, or vice versa.

This functionality would have several potential uses, including making a targeted template so that failed searches and nonexistent pages on any project could detect when the search term exists on another project and *direct* users to the project they want, instead of always giving them links to six projects that might have a page if they check them all (which they are unlikely to do).
Comment 1 Brion Vibber 2007-06-27 17:47:32 UTC
There's a few possible ways to do this. Direct database checks might be 'cheapest' internally, but ugly to handle with our current config code mish-mash.

Doing an HTTP hit might be easiest. I'm not sure if we're doing anything sufficiently nice with 404 responses... a HEAD check would be nice. :)

Alternatively could hit Special:Export just to check for existence.

Would strongly recommend using an in-cluster cache for checks, perhaps a shared memcache area (which could then be cleared on create/destroy).


There are issues of resulting cache coherency and cascading updates, since we have no infrastructure for doing that across wikis.

There are also issues with resolution of double-prefixes (eg, w:en:Foo), which currently is not done 'natively'. That could be done 'for free' with certain types of HTTP checks, or we might have to build it in.
Comment 2 Roan Kattouw 2007-06-27 17:57:49 UTC
Just how do you intend to use HTTP headers here? Visiting [[en:fkdjsfkdjfa]] won't give you a 404, just a "This article doesn't exist" message.
Comment 3 Brion Vibber 2007-06-27 18:43:56 UTC
Hence the sentence after it.
Comment 4 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-06-27 21:48:26 UTC
How about the bot API?  That must have cheap checks for the existence of a page.
Comment 5 Connel MacKenzie 2007-06-28 00:13:37 UTC
If a HEAD request comes in, the most lightweight thing you could do would be to return a 404 (or 301 REDIRECT) which would make the cross-project stuff enormously easier, no?  That would have to be cheaper than invoking the full API.PHP stuff, right?
Comment 6 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-06-28 03:50:12 UTC
The PHP stuff has to be invoked either way at the receiving end, to decide whether the article exists or not to start with.  Apache can't figure that out by itself, since we aren't talking about simple file existence.  The question is how much PHP has to be invoked.  If you just request the article you have to initialize the whole MW framework and prepare to show the page, and if it does exist you then actually have to render it and so forth (even for HEAD, because Content-Length needs to be correct).  Using the API would just do API initialization and then a single database query, presumably, which should be considerably faster (especially in the worst case where the page actually has to be parsed and rendered).
Comment 7 Roan Kattouw 2007-06-28 05:57:27 UTC
(In reply to comment #6)
> Using the API would just do API
> initialization and then a single database query, presumably, which should be
> considerably faster (especially in the worst case where the page actually has
> to be parsed and rendered).
That is indeed correct. The API also allows checking for multiple pages in one request (and thus one DB query), up to a limit of 500 pages (5,000 for sysops and bots). The URL for a simple check would be:

http://www.mediawiki.org/w/api.php?action=query&prop=info&titles=API|Talk:API|Dog|User:fdfsdfa

 

Comment 8 Rob Church 2007-06-28 12:31:11 UTC
Made some notes at http://www.mediawiki.org/wiki/User:Robchurch/Interwiki_existence_checks.
Comment 9 Brion Vibber 2007-06-28 13:25:28 UTC
(In reply to comment #6)
> The PHP stuff has to be invoked either way at the receiving end, to decide
> whether the article exists or not to start with.  Apache can't figure that out
> by itself, since we aren't talking about simple file existence.  The question
> is how much PHP has to be invoked.  If you just request the article you have to
> initialize the whole MW framework and prepare to show the page, and if it does
> exist you then actually have to render it and so forth (even for HEAD, because
> Content-Length needs to be correct).

Unless the 200 or 404 is cached by Squid, of course. :)

> Using the API would just do API
> initialization and then a single database query, presumably, which should be
> considerably faster (especially in the worst case where the page actually has
> to be parsed and rendered).

...but not cacheable, so that PHP and DB overhead is always there.
Comment 10 tisane2718 2010-03-21 04:58:07 UTC
I recommend that in addition to the interwiki #ifexist parser function, we also implement existence checking of interwiki links such as [[m:foo]], and provide for red/blue link coloration depending on the result of that check. Red links can be useful, in that they tempt users to create a new article. Therefore, in some cases, we don't want to have a template causing an interwiki link to appear as unclickable text, or not to appear if the page doesn't exist; we just want the link to be red.

We can implement such coloration via #ifexist as described at [[w:Wikipedia:Link_color#Making_links_appear_a_different_color_for_everyone]], but it would save keystrokes and simplify the markup just to have existence-detecting interwiki links. Presumably we'll use the LinkEnd or LinkBegin hook for this.
Comment 11 Marcin Cieślak 2011-03-13 13:40:26 UTC
Red links are already covered in a classic bug 11
Comment 12 Helder 2013-02-23 19:34:43 UTC
Maybe this will be possible to implement using Lua + WikiData?
Comment 13 John Mark Vandenberg 2014-05-10 04:21:45 UTC
(In reply to Helder from comment #12)
> Maybe this will be possible to implement using Lua + WikiData?

This depends on Wikidata having an item for the target page, which isnt 100% guaranteed.  Anyway, the data is mostly ready for this, and there is an API to implement it using Wikidata.

https://www.wikidata.org/w/api.php?action=wbgetentities&sites=enwiki&titles=Death_Star&props=labels&languages=nn&format=json

(but wiktionary isnt supported yet)

A #ifexists implemented in wikidata and lua (see but 11 comment 25) would be dependent on bug 47930.

Native #ifexist support would like be PHP invoking the target wiki API per comment 7, but the hard part is then tracking when the local page with the #ifexist call needs updating because the link target page is created or deleted on the link target wiki.  Maybe mediawiki can re-use/general the external site changes notification work that Wikidata is doing in bug 47288, so that mediawiki sites can notify each other of these events. (or re-use an existing message bus framework that has PHP support) non-mediawikis on the interwiki map could be periodically polled by backend processes, and events fired into message bus when changes are found.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links