Last modified: 2014-11-18 18:07:24 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 T23911, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 21911 - Limit for long page warning should be configurable
Limit for long page warning should be configurable
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Interface (Other open bugs)
unspecified
All All
: Normal enhancement with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 6226 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-12-20 20:27 UTC by Tisza Gergő
Modified: 2014-11-18 18:07 UTC (History)
10 users (show)

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


Attachments

Description Tisza Gergő 2009-12-20 20:27:10 UTC
[[MediaWiki:Longpagewarning]] currently has a hardcoded limit of 29K. The reason for this was very old browsers like Opera 6 having problems with textareas larger than 32K (see [[Wikipedia:Article size#Web browsers which have problems with long articles]] for details), but that is not a valid reason anymore. Having a long page warning is still useful as a reminder for best practices like [[Wikipedia:Article size]], but the specific limit of 29 (or 32) K is too low. There should be a way to either configure the limit, or hide the message (e.g. by setting it to "-" - in that case, parser functions could be used to decide whether to show the message).
Comment 1 Priyanka Dhanda 2009-12-28 23:22:16 UTC
Hi Tisza,

The article size is configurable on a site wide basis as far as I can tell.
http://www.mediawiki.org/wiki/Manual:$wgMaxArticleSize

Does that not work for you? Or did I misunderstand your issue?

-p 
Comment 2 Roan Kattouw 2009-12-28 23:28:46 UTC
(In reply to comment #1)
> Hi Tisza,
> 
> The article size is configurable on a site wide basis as far as I can tell.
> http://www.mediawiki.org/wiki/Manual:$wgMaxArticleSize
They're not the same. MaxArticleSize (2M by default) is the upper limit on the size of a page, but the longpagewarning is the thing that pops up above the edit box and says "This page is nn kilobytes long. Some browsers may have problems handling pages approaching 32 kb." (paraphrasing). The 29K limit used for toggling this message is requested to be configurable.
Comment 3 Platonides 2009-12-28 23:31:52 UTC
$wgMaxArticleSize is a hard limit (2MB)

But I think he wants to change the limit at wikipedia, not at his personal wiki.

I remember brion wontfixing a similar request some years ago. Even if those browsers 
are not popular now, they are still affected. I'd be reluctant to change that limit.
Comment 4 Tisza Gergő 2009-12-28 23:49:45 UTC
Yes, I would like to change it at Wikipedia eventually (or at least at some wikipedias, based on the preference of the local community). Even if there are browsers like Netscape 4 or Opera 6 in a significant amount  (which I doubt), and even if we decide to care about them (which we have no reason to - unlike the workplace lock-in for IE6, there is no legitimate reason to still use something like NS4, and if you do, it is your own problem if websites suck), the message is little help for them if it is not followed, and well-developed articles are usually way above 32k. The only thing it does is confuse newbies, thus it is usually hidden in some way (on enwiki it is changed in a totally pointless statement about current size if the text size is below 70k).
Comment 5 Platonides 2009-12-29 00:06:38 UTC
> and if you do, it is your own problem if websites suck

The problem is not viewing the website badly, but having the browser silently? remove a large chunk of page because it can't handle large textareas.
A capability check would be preferible, though.
Comment 6 Priyanka Dhanda 2009-12-29 00:33:53 UTC
doh! I see what you mean now.

A few possible solutions:
 - make it configurable
 - investigate the limit on various browsers and display a better message only for those browsers
 - find a workaround for the browsers that have a problem (may be more trouble than it is worth)

Any thoughts?
-p
Comment 7 Mike.lifeguard 2009-12-29 04:37:23 UTC
(In reply to comment #4)
> the message is little help for them if it is not followed, and well-developed
> articles are usually way above 32k. The only thing it does is confuse newbies,
> thus it is usually hidden in some way (on enwiki it is changed in a totally
> pointless statement about current size if the text size is below 70k).

This is certainly true. The warning seems to serve no purpose, since it is never heeded. Shouldn't it simply be removed?
Comment 8 Guillaume Paumier 2009-12-29 19:16:18 UTC
A quick look at how the 3 biggest Wikipedias dealt with this message shows that 2 of them have modified it to only show the size of the page (en, de) and one of them (fr) even removed it completely because it is "useless and scares new editors".

We have some browser statistics < http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm > and information about problematic browsers ([[Wikipedia:Article size#Web browsers which have problems with long articles]]; it might be worth investigating how many users can be affected by this limit (keeping in mind that these stats are for all users, and afaict the limit is only about text areas in /edit/ mode).

Overall I would lean towards removing the message completely. Most users don't care about the size of the page. Even an configurable option to enable it on a per-wiki basis seems overkill; people who really need to know a page's size can still use the {{PAGESIZE}} magic word (see [[mw:Help:Magic_words]]).
Comment 9 Platonides 2009-12-30 00:34:39 UTC
Using {{PAGESIZE}} for that would be ugly. The proper way would be to use a gadget, like http://es.wikipedia.org/wiki/Usuario:Platonides/TamArticulos.js
Comment 10 Tim Starling 2009-12-31 00:50:08 UTC
I've previously talked about just removing the feature, but the users I was talking to complained that a warning was still needed for editorial policy purposes. If we want to take that approach, the size should be configurable, the warning should be off by default, and the message name should be changed so that the localised messages can be rewritten to indicate that the size warning is about policy, not browser compatibility. 
Comment 11 Tisza Gergő 2010-01-03 21:11:56 UTC
I too would prefer the warning to be kept (with a configurable lower limit, off by default) for policy warnings. (Guillaume: at least on enwiki, the warning does have useful content, but it is hidden with parser function constructs unless you view it on a page that is over 70K or so.)

As for backwards and mobile compatibility, a capability check in the strict sense (actually performing POST requests) is not an option; the server could send the page size instead and the browser could send it back, and both could make a sanity check based on that, but the server counts in bytes and the browser in characters, and converting between the two is probably slow. Alternatively, the browser could attach some unique string to the end and the server check for it, but that only works if the text is truncated on posting and not on populating the textbox, and I would expect the opposite to be true.
Comment 12 Raimond Spekking 2010-11-23 12:58:50 UTC
Hard coded limit for long page warning removed with r77148. New message  [[MediaWiki:Longpage-hint]] (empty per default) can be used instead.   Parameters: $1 shows the formatted textsize in Byte/KB/MB, $2 is the raw number of the textsize in Byte
Comment 13 Vitaliy Filippov 2011-02-14 22:19:14 UTC
Why not simply remove the hard-code and change
($this->kblength > 29) to ($wgMaxRecommendedArticleSize > 0 && $this->kblength > $wgMaxRecommendedArticleSize)
It would be more efficient than using a message and especially parser functions for users who want to keep the warning.
Comment 14 Helder 2012-06-26 15:11:46 UTC
*** Bug 6226 has been marked as a duplicate of this bug. ***

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


Navigation
Links