https://bugzilla.wikimedia.org/show_bug.cgi?id=17597
Summary: Record links to special pages in the data base
Product: MediaWiki
Version: 1.15-svn
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: Normal
Component: General/Unknown
AssignedTo: [email protected]
ReportedBy: [email protected]
CC: [email protected]
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.
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
