Change Details

We will soon be able to start turning on the refactored comment storage, allowing comments of up to 1000 Unicode characters. This will be usable by API clients immediately. But everything in the web UI that applies a limit is still going to be applying the old limit of 255 bytes. When the server-side `$wgCommentTableSchemaMigrationStage` variable is set to `MIGRATION_OLD` (0), frontend code should continue to apply the 255-byte limit. When that variable is set to any other value (other expected values are 1, 2, and 3), frontend code should limit things to 1000 Unicode characters. Note that JavaScript and HTML5 `maxlength` work with UTF-16 code points, e.g. `"😭".length` returns 2 but MediaWiki will count it as only 1; see also {T180497}. Note that `$wgCommentTableSchemaMigrationStage` is temporary, so it should be made easy to search for in relevant code for future removal; naming variables to contain "CommentTableSchemaMigrationStage" or including that string in nearby comments is recommended. Extensions not using "compatibility policy = rel" may want to treat it as 0 when unset and the CommentStore class does not exist, and set to `MIGRATION_NEW` (3) when unset and the CommentStore class exists. Places that may need attention for this task include: [x] The edit summary in the edit form, including the JavaScript that adds the byte counter. [x] The edit summary in VE, if it uses different code. [X] The reason field in the protection form. [ ] The reason field in the page move form. [ ] The reason field in the page deletion form. [ ] The reason field in the file deletion form. [ ] The reason field in the page undeletion form. [ ] The reason field in the revision deletion form. [ ] The reason field in the block form. [ ] The reason field in the user rights change form. [ ] Anything else that creates an entry in the `logging` table with a user-entered `log_comment`. Note that extensions storing comments in their own tables don't need updating for this task, but may want to be updated to take advantage of CommentStore themselves.

We will soon be able to start turning on the refactored comment storage, allowing comments of up to 1000 Unicode characters. This will be usable by API clients immediately. But everything in the web UI that applies a limit is still going to be applying the old limit of 255 bytes. When the server-side `$wgCommentTableSchemaMigrationStage` variable is set to `MIGRATION_OLD` (0), frontend code should continue to apply the 255-byte limit. When that variable is set to any other value (other expected values are 1, 2, and 3), frontend code should limit things to 1000 Unicode characters. Note that JavaScript and HTML5 `maxlength` work with UTF-16 code points, e.g. `"😭".length` returns 2 but MediaWiki will count it as only 1; see also {T180497}. Note that `$wgCommentTableSchemaMigrationStage` is temporary, so it should be made easy to search for in relevant code for future removal; naming variables to contain "CommentTableSchemaMigrationStage" or including that string in nearby comments is recommended. Extensions not using "compatibility policy = rel" may want to treat it as 0 when unset and the CommentStore class does not exist, and set to `MIGRATION_NEW` (3) when unset and the CommentStore class exists. Places that may need attention for this task include: [x] The edit summary in the edit form, including the JavaScript that adds the byte counter. [x] The edit summary in VE, if it uses different code. [x] The reason field in the protection form. [x] The reason field in the page move form. [x] The reason field in the page deletion form. [x] The reason field in the file deletion form. [x] The reason field in the page undeletion form. [x] The reason field in the revision deletion form. [x] The reason field in the block form. [x] The reason field in the user rights change form. [ ] Anything else that creates an entry in the `logging` table with a user-entered `log_comment`. Note that extensions storing comments in their own tables don't need updating for this task, but may want to be updated to take advantage of CommentStore themselves.

We will soon be able to start turning on the refactored comment storage, allowing comments of up to 1000 Unicode characters. This will be usable by API clients immediately. But everything in the web UI that applies a limit is still going to be applying the old limit of 255 bytes. When the server-side `$wgCommentTableSchemaMigrationStage` variable is set to `MIGRATION_OLD` (0), frontend code should continue to apply the 255-byte limit. When that variable is set to any other value (other expected values are 1, 2, and 3), frontend code should limit things to 1000 Unicode characters. Note that JavaScript and HTML5 `maxlength` work with UTF-16 code points, e.g. `"😭".length` returns 2 but MediaWiki will count it as only 1; see also {T180497}. Note that `$wgCommentTableSchemaMigrationStage` is temporary, so it should be made easy to search for in relevant code for future removal; naming variables to contain "CommentTableSchemaMigrationStage" or including that string in nearby comments is recommended. Extensions not using "compatibility policy = rel" may want to treat it as 0 when unset and the CommentStore class does not exist, and set to `MIGRATION_NEW` (3) when unset and the CommentStore class exists. Places that may need attention for this task include: [x] The edit summary in the edit form, including the JavaScript that adds the byte counter. [x] The edit summary in VE, if it uses different code. [Xx] The reason field in the protection form. [ x] The reason field in the page move form. [ x] The reason field in the page deletion form. [ x] The reason field in the file deletion form. [ x] The reason field in the page undeletion form. [ x] The reason field in the revision deletion form. [ x] The reason field in the block form. [ x] The reason field in the user rights change form. [ ] Anything else that creates an entry in the `logging` table with a user-entered `log_comment`. Note that extensions storing comments in their own tables don't need updating for this task, but may want to be updated to take advantage of CommentStore themselves.