Last modified: 2014-11-17 10:35:55 UTC
If you protect a page or move a page, you often want to give detailed reasons for that, and unfortunately if your comment is too long, it is cut off and not fully saved in the history[1]. Editing a page solve this problem through a maxlength="200" in the input-tag. There does not seem to be a limit in the forms of page moves and page protections. [1] see these examples: http://de.wikipedia.org/w/index.php?title=Benutzer%3AChurch_of_emacs%2FTestseite&diff=55039106&oldid=54976709&uselang=en http://de.wikipedia.org/w/index.php?title=Benutzer%3AChurch_of_emacs%2FTestseite3&diff=55039224&oldid=55039106&uselang=en
added maxlength=200 for page moves per r45517. Please note the the protection form has a maxlength of 255 already.
> Please note the the protection form has a maxlength of 255 already. This is correct, however not only the edit comment itself is stored in the rev_comment (which has the actual 255-byte-limit), but also the automated part of the comment ("Protected "[[<pagename>]]": ") and the selectable comment (for example "Counter-productive edit warring: "). So, in total you have (in this example, with the specified pagename and selectable comment): Protected "[[Main Page]]": Counter-productive edit warring: That's already 60 bytes, so you have only 195 bytes left - much less than the 255 byte limit the user sees! I don't think a fix his easy here: On one side, you don't know in advance which selectable comment will be picked (so you can't calculate the actual maximum in advance), on the other hand I don't think that there's going to be a change in the data type/255-byte-limit of rev_comment. But even where there's no easy fix, the least that should be done is to warn the user about this bug.
Reverted in r45571 -- this changed the field from a textarea to a single-line text input field, when it was a larger field deliberately, thus causing a usability regression. Additionally we would like to *accept* longer comments, not cut them off more aggressively.
(In reply to comment #3) > Additionally we would like to *accept* longer comments, not cut them off more > aggressively. I would say that setting a maximum length on the field is less aggressive than appearing to accept long comments and then cutting them off when they're actually saved. :) Accepting longer comments would be nice, of course. Should a separate bug be filed for that? Or does it come under bug 4714 (which currently only mentions edit summaries)?
If bug 4714 (which is basically about rev_comment and not only about the edit summary) would be fixed, this bug could be closed as well. It should be noted however, that this may be not the case for quite a while (the bug is already open since almost two years) and until then, this bug is still relevant. After all, it's a real bug, while 4714 is just a feature request. I think that not allowing a too long comment in advance (when the user is aware about this fact and is able to make it short) is better than cutting a long comment off *after* the user moved the page.
*** Bug 17091 has been marked as a duplicate of this bug. ***
This becomes even worse, inho, with the selectable custom-made comments that are installation/localization dependant. It is also bad in the context of blocks, where you often want to refer to an edit (i.e. an URL of a diff) which is put behind the custom comment. The most significant part, oldid=xxxxx, is truncatd most likely. :-( A too restrictive solution was, to subtract punctuation and the longest message size from the count of available characters, and output it as the lenght restriction of the (additional) comment field to the browser, in the hope that it honors the parameter. Since that can be pretty easily implemented, it might be a solution to cope with until a better solution was developped. Better was to warn the user of the possible truncation (like one can be warned when an edit comment was omitted on a normal page edit, if one chooses so in ones preferences), letting him know of the allowance, the number of characters truncated, set the input field size, and if he alters his message, recycle until all fits, or an unaltered message comes a 2nd time. Best was, to allow longer comments per increased data base field length.
Another problem with maxlength is that it counts characters while the database filed has a byte limit. Non-ASCII characters can take up two or more bytes. Maybe a simple js script could count the length on change or submit events and warn the user if neccessary?
One issue with the protection log entries (and possibly others) is that while the protection settings and expirations are concatenated with the reason for the revision table, they aren't for the logging table. The reason and protection settings are stored in different fields.
Maxlength re-added in r60054 if $wgHtml5 == true, since HTML5 allows maxlength on textareas. It works in Chrome 4, but not Firefox 3.5 or Opera 9.22, so leaving this open for now.
Created attachment 8453 [details] Temporary fix This temporarily circumvents some problems by using the same javascript code used for the edit summary to prevent problems with unicode, and reduces the max length for protection reasons to 180 bytes instead of 255 characters.
For really fixing this bug we need to increase the maximum edit summary length in the database: bug 4714. Then we can arbitrarily set the client side limit to something more sane than 180 bytes.
(In reply to comment #11) > Created attachment 8453 [details] > Temporary fix > > This temporarily circumvents some problems by using the same javascript code > used for the edit summary to prevent problems with unicode, and reduces the max > length for protection reasons to 180 bytes instead of 255 characters. Committed in r86846.
*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*