Last modified: 2008-09-21 01:21:09 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 12234 - Protection log entries can be cut off
Protection log entries can be cut off
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
All All
: Normal minor (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch, patch-need-review
Depends on:
  Show dependency treegraph
Reported: 2007-12-07 23:08 UTC by CBM
Modified: 2008-09-21 01:21 UTC (History)
3 users (show)

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

trim protection log comments (1.26 KB, patch)
2008-04-07 23:06 UTC, CBM
trim log comments (1.73 KB, patch)
2008-04-09 11:28 UTC, CBM

Description CBM 2007-12-07 23:08:34 UTC
The protection log for [[Mozilla Firefox]] in English Wikipedia includes the following:

2007-12-04T22:08:11 Cbrown1023 (Talk | contribs | block) changed protection level for "Mozilla Firefox" ‎ (Firefox has been protected for nearly a week now and, looking at the discussion page, it seems like one of the edit warriors has agreed to walk away. Could it be unprotected now? -MBlume 05:39, 4 December 2007 (UTC) (restoring semi-protection) [edit=autoc) 

This log entry was apparently truncated because of excessive length. The truncation cut off the details of the protection level, making it impossible to parse the log entry to determine the protection level. Also, the expiration date is completely removed. 

If a protection log entry is too long, it should be trimmed before the restriction level and expiration date are appended.
Comment 1 Robert Leverington 2007-12-07 23:18:06 UTC
This would be because log_comment is only a VARCHAR(255), however increasing this to the next biggest level (BLOB\TEXT) would use a hell of a lot of resources. Perhaps if the different sections were stored in different columns the situation could be helped, however the easiest solution would be to disallow or trim comments that add up with the other parts of the summary to a value higher than 255 characters.
Comment 2 CBM 2008-04-07 23:06:46 UTC
Created attachment 4795 [details]
trim protection log comments
Comment 3 CBM 2008-04-09 11:28:19 UTC
Created attachment 4796 [details]
trim log comments

The  first patch changed the order of the page history entry slightly, update patch to keep the same output format
Comment 4 Aaron Schulz 2008-09-10 18:46:20 UTC
Those details really should use log_params
Comment 5 Aaron Schulz 2008-09-10 19:46:19 UTC
Fixed in r40713. This is not retroactive.
Comment 6 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-09-21 01:21:09 UTC
(In reply to comment #1)
> This would be because log_comment is only a VARCHAR(255), however increasing
> this to the next biggest level (BLOB\TEXT) would use a hell of a lot of
> resources.

Not enormously.  It would force temporary tables to disk and maybe have a few other consequences, but this column is normally only included in result sets, so it shouldn't be the end of the world.  We should switch log_comment and rev_comment to SMALLBLOB at some point, especially for i18n purposes -- some languages might have half the number of characters available and this isn't reflected in the field's maxlength, which goes by characters instead of bytes.  But those are big ALTERs and so no one seems to be interested in doing them.

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