Last modified: 2010-05-15 15:32:53 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 2274 - Stub threshold preferences not used on category pages
Stub threshold preferences not used on category pages
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Categories (Other open bugs)
1.4.x
All All
: Lowest minor (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-05-31 12:17 UTC by Pcb21
Modified: 2010-05-15 15:32 UTC (History)
2 users (show)

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


Attachments

Description Pcb21 2005-05-31 12:17:31 UTC
The stub detection algorithm that is used on general pages (so that, for logged
in users with stub threshold turned on links to short articles have a
class="stub" added to the link) is not utilised on category pages. Hence all
links are rendered the same way on category pages.

Fixing this bug would be useful because, for instance, there is a huge "stub
sorting" project on the English Wikipedia. That great effort would be rendered
more useful if we could use standard categories rather than special categories
to indicate stub articles.
Comment 1 Dashiva 2005-05-31 12:21:44 UTC
Clarifying, the category page text itself has stubs. It's the generated list of pages (and probably images, subcategories) in the 
category that isn't stubbed.
Comment 2 River Tarnell 2005-05-31 20:26:02 UTC
RESOLVED WONTFIX 
 
because i think the plan is actually to remove stub threshold support 
rather than make it more widely used. 
Comment 3 Pcb21 2005-06-01 09:59:12 UTC
Thanks for the responses. I guess (and so could be totally wrong) there are three steps to providing stub threshold support

1) At each save, find out the size of the text and store it in the db.
2) At each logged-in page load, look up the size of each linked page.
3) Look-up the preference of the user and for each link add a class=stub if pref > size.

Now I guess the reason that support is slated for removal is that one of these steps is showing up as a resource/speed bottleneck. Now, 
because I'm an optimist, I hope that is number 3) - the user-dependent bit. Rather than remove support totally is it possible to somehow 
just send the size through in the link and somehow the user js to figures out the rendering? 

As you might have guessed, I write as a keen user of the feature :)

Pete

Comment 4 Brion Vibber 2005-06-01 10:04:10 UTC
In 1.5 we've got a page_size field on page, and have to look up the title from page anyway. Tossing the 
third field in should be relatively easy if we're not removing it entirely. Might require some changes to 
the link gen functions to explicitly state without copying stuff around.
Comment 5 Brion Vibber 2005-06-01 10:30:17 UTC
Done in CVS HEAD for 1.5.
Comment 6 River Tarnell 2005-06-01 20:05:45 UTC
getting the length isn't the issue.  the stub threshold will never be 
accurate, because it won't be updated in the cached copy until the page 
is edited. 

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


Navigation
Links