Welcome to Codidact Meta!
Codidact Meta is the meta-discussion site for the Codidact community network and the Codidact software. Whether you have bug reports or feature requests, support questions or rule discussions that touch the whole network – this is the site for you.
Comments on False positive for 30,000 character limit
Parent
False positive for 30,000 character limit
I tried to edit a post, but I received the following message saying it is over 30,000 characters. I double checked in a text editor that the number of characters is 27,835 (as shown in the Codidact edit text box - see the orange writing at the bottom right of the image below), and also confirmed that these are all single byte characters, so the total number of bytes is also 27,835. I can't think of another reason it would be treated as over 30,000 characters.
Is there anything I need to do differently, or is this a bug?
The post I was trying to edit was being approximately doubled in length as I was sandbox testing two different presentation formats. It contains no images (before or after the attempted edit). Editing the post without doubling the length saves fine - I tested this to make sure.
In case it's relevant, note that in order to make the orange character count show at the bottom right, I needed to add a space and then immediately delete it - the orange character count was not present at the moment the red error message appeared
Post
My best guess would be that the check is performed on the HTML representation of the post. In the database, two representations are stored. The first is the markdown representation as you typed it, and the second is the HTML representation.
In HTML, a lot of the lines would get some extra characters, for example a header like # Test becomes <h1>Test</h1> and a list of items changes too:
* a
* b
* c
changes into
<ul>
<li>a</li>
<li>b</li>
<li>c</li>
</ul>
This could explain the count you see being a few thousand characters shorter than what QPixel reports when checking for the limit.
That said, I don't think this was taken into account when setting the limit. Perhaps a larger limit would make more sense (or perhaps it should be checked on both). Programmatically, I don't believe there is a specific reason for putting the limit at 30.000, and a bigger limit should potentially be considered (and the limits should differ between the markdown and the html to avoid this issue). The maximum for the way things are currently stored is roughly 65.500 characters, so there is room to up the limit.
0 comment threads