Page MenuHomePhabricator

Remove stub link formatting user preference from MediaWiki core
Open, MediumPublic


Under Preferences > Appearance > Advanced options, the preference Threshold for stub link formatting should be removed from MediaWiki core and either be placed into a MediaWiki extension or be implemented as a JavaScript script/gadget.

In the code base, this is ./includes/Preferences.php, and StubThreshold/stubThreshold in various places.

The feature contributes to parser cache fragmentation, which is bad and to be avoided. It's an old, quirky feature that would likely never be implemented in MediaWiki core if were proposed today. It's merely a(n) historical artifact that it's currently in core and it shouldn't be any longer.

Version: unspecified
Severity: enhancement



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:33 PM
bzimport set Reference to bz28426.
bzimport added a subscriber: Unknown Object (MLST).

Does it actually contribute to parser cache fragmentation? I was under the impression it disabled the parser cache totally for users who used that option (Which probably is not the greatest thing either). wrote:

Well that's definitely worse. It could certainly be fairly easily implemented with JavaScript; I wonder if there's a CSS solution which doesn't involve a thousand CSS rules to highlight links under a kilobyte...

Bumping this down to enhancement -- as noted in prior discussions this is a goal but we won't want to kill it just yet until it's replaced with a clean way to do it. (More general article state like a 'Popups lite' might be nice.) wrote:

Do we have a status for "requested regression"?? :D

Statistics requested by Mark H: there are 18,412 users across all wikis who have the stubthreshold preference set. Unified accounts were not accounted for, so a user who has the preference set on multiple wikis is counted multiple times.

Top 10 of wikis with most stubthreshold users:
enwiki 4789
dewiki 1545
jawiki 1336
ruwiki 1179
ptwiki 791
eswiki 623
frwiki 530
plwiki 513
commonswiki 415
nlwiki 366

ayg wrote:

Doing this in JavaScript would be just evil. It's definitely the kind of feature that should be server-side. We could remove the cache impact with some work, if anyone cared. If the proposal is to just drop it completely, I'm not going to object, but no way should we move it to JS, for all sorts of reasons. (Of course, users could always reimplement it themselves in JS, and we can't stop them, but we don't have to encourage it.)

Although I use this feature, you have my vote to get it removed entirely.

Was it removed? I can't find it.

It is still in core MediaWiki, under Preferences > Appearance > Advanced options.

Removing good first task as related code is in 4 or 5 source files and (more relevant) as T30426#333026 implies that there is no clear way ahead ("we won't want to kill it just yet until it's replaced with a clean way to do it"), hence could potentially become controversial.
Feel free to re-add the tag once these issues have been sorted out and a clear way forward is offered to a new code contributor.

If we wanted to make this feature work properly, I think the right way would be to parse the HTML page content for links, find all links to pages on the current wiki, run a DB query to see how big they are, and add a suitable class to the parsed HTML. This would not affect caching; would have no performance impact on anyone who has the feature disabled; and for whoever has the feature enabled, will add one HTML parse/serialize and one (small, indexed) database query.

This assumes we have an HTML parser that will round-trip the markup with simple changes like this. We do, right?