Last modified: 2014-11-17 10:36:18 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T19597, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 17597 - Record links to special pages in the data base
Record links to special pages in the data base
Status: NEW
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
1.15.x
All All
: Low enhancement with 3 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: 14787
  Show dependency treegraph
 
Reported: 2009-02-21 11:42 UTC by Purodha Blissenbach
Modified: 2014-11-17 10:36 UTC (History)
3 users (show)

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


Attachments

Description Purodha Blissenbach 2009-02-21 11:42:53 UTC
This is a followup to bug 16162
Currently, special page links are not being recorded in the database.
Imho, it would be useful to start doing that so as to:
- allow "what links here" on special pages (at least useful
  to maintainers)
- gain the potential to speed up lookups by moving some
  servertime and usertime eating handling to the process of
  saving a page (once) rather than leaving it in the process of
  serving a page (likely performed more often)

Atm, there are various names addressing any special page
(generic, aliased, localized, fallback language(s), fallback
language(s) localized). They a are resolved via http redirects.
This may cause redirect chains of up to 5 http requests causing
server load, bandwidth use, and remarkable delays to users,
rewritten URLs in Browsers, and maybe other inconveniences.

Resolving all these once, during page saving, internally,
and later using the final result, should imho be advantagous.

Various nice side effects, such as added lookups, come with it.

(We should not abandon the redirect stuff though,
because there may be old, or hand-edited URLs, and we need to
cope with possible changes of localized names before the
database has been completely updated)

There is just one snag: Links to special pages may be parameterized. They come in several kinds:
1. Special:Page/parameter
2. {{Special:Page|parameterlist}}
3. {{fullurl:Special:Page|parameterlist}}

For the time being, I'd suggest to postpone version 3 until
a working solution for the others has been found (with 3 in
mind of course), and then transform these external links into
some kind of internal ones.

I momentarily have no proposal to make as to how to handle
parameters, since I am not familiar enough with the details
involved. Only two basic approaches:
- keep parameters in the database somehow (with the benefit
  to use them in queries, but inconsistent with e.g.
  template parameters)
- do not keep parameters in the db, rather let the parser get
  them when needed (with added flexibility of having less static
  parameters, such as current user, language, time, cookies, etc.)
I lean towards the latter.

During the process of saving such links, e.g.
 Special:ListAdmins
 Special:UserList/sysop
 → {{Special:UserList|group=sysop}}
needs to be completely broken down into an unambiguous final
canonical representation. That has implications:
- Parameters may not be visible in the original wikicode of a
  page. Where to keep them, if not in the db? Shall we accept
  to rewrite the Wikicode of "Special:ListAdmins" at least to
  "Special:UserList/sysop" so as to have a string reference to
  "sysop" when rendering?
- So as to obtain a way of breaking down parameters, we need to
  rely on the parameter handling of individual special pages.
  Thus, they need to get an additional entry point to be called
  during page save for this purpose. While that is generally
  not a big problem per se, it requires perhaps some care to
  be taken regarding cases such as:
- Special:UserList/{{#case:{{localtime-am-pm}}|am=sysop|pm=bot}}
  This example is silly. I could not find useful ones without
  resorting to such complex things like building a page
  on a users geo-coordiantes being used in an extension like
  Semantic MediaWiki e.g. collecting places of interest in
  walking distance to him or her. I do not know wether or not
  this is a problem.
  At least, the new internal parameter handling call of special
  pages needs generally be aware of the fact that, it may receive
  unparseable stuff which can only be resolved when the page is
  finally being rendered.
  Not having gone into the implementation details, a possible
  caveat might be: 
   Special:UserList/{{something}}
   → {{Special:UserList|group={{something}}}}
   → {{Special:UserList|user={{something}}}}
  depending on {{something}}.
So, likely, this bug is going to spawn additional ones to be dealt with before it can be completely solved.
Comment 1 Andre Klapper 2014-11-04 13:30:02 UTC
...and quoting Brion from bug 16162:

For now the special links are not being recorded. It could be useful to start recording them, but we'd want to do a few things:
* Normalize the link names to canonical form
* Consider a way to deal with parameters
* Add UI for all the various "show me stuff from the link tables" to consistently allow doing something with that data

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


Navigation
Links