Hi all,
MediaWiki has a user setting to add a CSS class to article links whose length is below a certain threshold (preferences/appearance/advanced options/threshold for stub link formatting). Is it possible to enable this by default on a Wikimedia wiki? Some of the advantages: - a lot of editors seem to use it already to find articles which need some care, and currently it slows down page loading for them because it breaks caching, so they could work quicker. - like red links, it could bring in new editors by making readers realize that some of the linked articles need help. - it could make readers waste less time because they could realize the article is a stub without clicking at it. On the other hand, I suppose it would raise database load because the length of all linked pages would need to be queried at HTML generation. (Or is that query already already necessary to see which links are red?)
Tisza Gergö wrote:
Hi all,
MediaWiki has a user setting to add a CSS class to article links whose length is below a certain threshold (preferences/appearance/advanced options/threshold for stub link formatting). Is it possible to enable this by default on a Wikimedia wiki?
No. Currently it would mean not caching any page view. The feature would need to be adapted to allow efficient stub linking (I have some ideas about it, and the new linker makes things easier).
Still, we might not allow stub links for anons in miser mode.
Feel free to open a bug.
Platonides writes:
No. Currently it would mean not caching any page view. The feature would need to be adapted to allow efficient stub linking (I have some ideas about it, and the new linker makes things easier).
Still, we might not allow stub links for anons in miser mode.
Feel free to open a bug.
Would it be possible to raise the default threshold for links to a page to be red? Currently it's 0, if I understand correctly, but we could decide to make it 1024 or whatever for everyone (if some wiki asked it), couldn't we?
Federico Leva (Nemo) wrote:
Platonides writes:
No. Currently it would mean not caching any page view. The feature would need to be adapted to allow efficient stub linking (I have some ideas about it, and the new linker makes things easier).
Still, we might not allow stub links for anons in miser mode.
Feel free to open a bug.
Would it be possible to raise the default threshold for links to a page to be red? Currently it's 0, if I understand correctly, but we could decide to make it 1024 or whatever for everyone (if some wiki asked it), couldn't we?
No. Anything other than showing no stubs skips the cache.
On 06/06/11 00:09, Platonides wrote: <snip>
No. Anything other than showing no stubs skips the cache.
Since it skips cache, can not we disable that stub highlighter once for all?
On Mon, Jun 6, 2011 at 8:48 AM, Ashar Voultoiz hashar+wmf@free.fr wrote:
On 06/06/11 00:09, Platonides wrote:
<snip> > No. Anything other than showing no stubs skips the cache.
Since it skips cache, can not we disable that stub highlighter once for all?
Logged in users don't get cached versions of the page...
On 06/06/11 00:56, K. Peachey wrote: <snip>
Since it skips cache, can not we disable that stub highlighter once for all?
Logged in users don't get cached versions of the page...
I am well aware of that. The root cause being the various options available to users, my proposal is merely to get ride of one of the options :-)
Ashar Voultoiz wrote:
On 06/06/11 00:56, K. Peachey wrote:
<snip> >> Since it skips cache, can not we disable that stub highlighter once for all? > Logged in users don't get cached versions of the page...
I am well aware of that. The root cause being the various options available to users, my proposal is merely to get ride of one of the options :-)
I think you would find opposition from wikipedians when you tried to ditch the stub threshold option.
"Platonides" Platonides@gmail.com wrote in message news:isjjo3$dmq$1@dough.gmane.org...
Ashar Voultoiz wrote:
On 06/06/11 00:56, K. Peachey wrote:
<snip> >> Since it skips cache, can not we disable that stub highlighter once for >> all? > Logged in users don't get cached versions of the page...
I am well aware of that. The root cause being the various options available to users, my proposal is merely to get ride of one of the options :-)
I think you would find opposition from wikipedians when you tried to ditch the stub threshold option.
We find opposition from some subset of Wikipedians when we try to do just about anything. The presence of a small group of extremely vocal users should certainly be noted, but shouldn't be an automatic blocker, or we'd never get anything done. If we proceeded to remove the feature, they could fairly easily add it into Popups or one of the other JS citadels.
--HM
"Leo Koppelkamm" diebuche@gmail.com wrote in message news:BANLkTinscKfVPnRSCska4Svdgq9zGvU3nA@mail.gmail.com...
If we proceeded to remove the feature, they could fairly easily add it into Popups or one of the other JS citadels.
I don't see a way to do it in JS w/o lengthy & expensive API checks.. Leo
So they'll do it with lengthy API checks, just like the rest of the data Popups gathers. We tell them not to worry about performance, remember? The number of people who would use a JS implementation is probably small enough for it not to be particularly severe.
--HM
Platonides <Platonides <at> gmail.com> writes:
Feel free to open a bug.
Thanks, did so: https://bugzilla.wikimedia.org/show_bug.cgi?id=29276
On Sat, Jun 4, 2011 at 11:24 AM, Tisza Gergö gtisza@gmail.com wrote:
- a lot of editors seem to use it already to find articles which need some care,
and currently it slows down page loading for them because it breaks caching, so they could work quicker.
It would be better if we could fix it so it didn't break caching at all, of course, such as by adding the coloring during a postprocessing stage, after the parser cache is invoked rather than before.
On the other hand, I suppose it would raise database load because the length of all linked pages would need to be queried at HTML generation. (Or is that query already already necessary to see which links are red?)
Yes, we're already querying for redlinks, so there's no additional cost to query page_len while we're at it. In fact, we always query page_len anyway just in case we need it for stubs -- see doQuery() in includes/cache/LinkBatch.php.
But as Platonides says, the parser cache is currently not used at all when stub coloring is enabled -- I didn't realize that. If you think about it, if we cached pages with stub coloring, we'd have to purge the cache of all pages linking to them whenever they changed length, or at least whenever the length change put them above or below some threshold.
This would be moot if we added the coloring on postprocessing after retrieval from cache, instead of during parsing. But that's a fairly ambitious project, I guess. Alternatively, we could cache it and just not care if the coloring is outdated, but users would doubtless complain too much for that to be worth it.
On Sat, Jun 4, 2011 at 6:54 PM, Platonides Platonides@gmail.com wrote:
No. Currently it would mean not caching any page view. The feature would need to be adapted to allow efficient stub linking (I have some ideas about it, and the new linker makes things easier).
What were you thinking of?
On Sun, Jun 5, 2011 at 8:08 AM, Federico Leva (Nemo) nemowiki@gmail.com wrote:
Would it be possible to raise the default threshold for links to a page to be red? Currently it's 0, if I understand correctly, but we could decide to make it 1024 or whatever for everyone (if some wiki asked it), couldn't we?
I'm not sure what you're asking. Currently, links to a page are red if the page does not exist. It doesn't have to do with the number of links to the page.
Aryeh Gregor wrote:
It would be better if we could fix it so it didn't break caching at all, of course, such as by adding the coloring during a postprocessing stage, after the parser cache is invoked rather than before.
There's a tracking bug about avoiding parser cache fragmentation: https://bugzilla.wikimedia.org/show_bug.cgi?id=28424.
Federico Leva (Nemo) wrote:
Would it be possible to raise the default threshold for links to a page to be red? Currently it's 0, if I understand correctly, but we could decide to make it 1024 or whatever for everyone (if some wiki asked it), couldn't we?
I'm not sure what you're asking. Currently, links to a page are red if the page does not exist. It doesn't have to do with the number of links to the page.
I think he's talking about changing the default value of $wgDefaultUserOptions's "stubthreshold" on a per-wiki basis. It's currently 0 everywhere, as far as I know.
MZMcBride
On Sun, Jun 5, 2011 at 2:25 PM, MZMcBride z@mzmcbride.com wrote:
I think he's talking about changing the default value of $wgDefaultUserOptions's "stubthreshold" on a per-wiki basis. It's currently 0 everywhere, as far as I know.
We could do that if we wanted to disable the parser cache for all logged-in users by default, which we most likely don't.
On 5 June 2011 21:09, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
On Sat, Jun 4, 2011 at 11:24 AM, Tisza Gergö gtisza@gmail.com wrote:
- a lot of editors seem to use it already to find articles which need some care,
and currently it slows down page loading for them because it breaks caching, so they could work quicker.
It would be better if we could fix it so it didn't break caching at all, of course, such as by adding the coloring during a postprocessing stage, after the parser cache is invoked rather than before.
Why don't we just add the numbers to html and let JavaScript make sense out of them? -Niklas
On Sun, Jun 5, 2011 at 4:46 PM, Niklas Laxström niklas.laxstrom@gmail.com wrote:
Why don't we just add the numbers to html and let JavaScript make sense out of them?
We can't put the numbers in any form in the parser cache, because they'll become outdated as soon as the length of the linked page changes. The only way to use the parser cache is to put some marker in it which is substituted for the appropriate page's length when the parser cache entry is retrieved and displayed. Once we're doing that, we may as well also check the user's pref and add a class depending on it, so we don't have to do anything in JS.
Even if we solve this for parser cache, of course, it won't work for Squid cache. Anons are never going to get nonzero stub thresholds.
Aryeh Gregor wrote:
On Sat, Jun 4, 2011 at 6:54 PM, PlatonidesPlatonides@gmail.com wrote:
No. Currently it would mean not caching any page view. The feature would need to be adapted to allow efficient stub linking (I have some ideas about it, and the new linker makes things easier).
What were you thinking of?
Depending on page cacheability:
1) If the page is not cached and won't be cached (render of old version, page preview...) create the stub links as we do now.
2) If the page can be cached, Render it ignoring stub threshold if not cached. else Fetch html from cache.
If the user has a stub threshold different than 0, SELECT page_namespace,page_title FROM pagelinks JOIN page ON ... WHERE pl_from=$this->mArticleId AND page_len < $user->getStubThreshold();
For each of those stub pages: $a = Linker::Link() (ignoring stub threshold), $b = Linker::Link() (as stub). Extract the open tag from $a and $b. str_replace $a with $b in the html.
Bypassing the whole parsing structure in that way is not pretty, but it's really efficient.
On Sun, Jun 5, 2011 at 6:22 PM, Platonides Platonides@gmail.com wrote:
If the user has a stub threshold different than 0, SELECT page_namespace,page_title FROM pagelinks JOIN page ON ... WHERE pl_from=$this->mArticleId AND page_len < $user->getStubThreshold();
For each of those stub pages: $a = Linker::Link() (ignoring stub threshold), $b = Linker::Link() (as stub). Extract the open tag from $a and $b. str_replace $a with $b in the html.
Bypassing the whole parsing structure in that way is not pretty, but it's really efficient.
Hmm, interesting approach. Basically a postprocessor like I was thinking of, except simpler. I was thinking you'd insert special markers into the HTML that you'd replace later. But I can't think of any ways you'd get mismatches with your method, given that the parser outputs reasonably simple HTML -- in particular, no comments or <script>s or <style>s or other things where you can have unescaped <'s as text.
On Mon, Jun 6, 2011 at 4:21 PM, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
Hmm, interesting approach. Basically a postprocessor like I was thinking of, except simpler. I was thinking you'd insert special markers into the HTML that you'd replace later. But I can't think of any ways you'd get mismatches with your method, given that the parser outputs reasonably simple HTML -- in particular, no comments or
<script>s or <style>s or other things where you can have unescaped <'s as text.
It looks like it'll be fine as long as <a> is not a whitelisted tag.
Roan Kattouw (Catrope)
wikitech-l@lists.wikimedia.org