Wedge
Public area => The Pub => Bug reports => Topic started by: Arantor on March 2nd, 2012, 10:53 AM
-
This is curious.
I could understand > 255 failing because the choice is stored as an unsigned tinyint, but I have no idea why it gets out of step for 128-255.
-
The (real) problem is in the logic of the javascript: the script counts how many items are there and it continues the numbering from there, so if you let's add 5 options you have ids from 0 to 4, then you edit the poll and remove two options in the middle (2 and 3 let's say) and save the ids on the next page load will be 0, 3, 4, but when you add a new option with the javascript it add the new input with id equal to 3, that way you have 2 input box with id 3 and of course the second will be the one used by php.
-
Ah, that makes perfect sense, thanks :)
I note the commit note mentions fixing it for > 255, is the column a smallint in SMF 2.1, or is a suitable error thrown at the user? (A poll with 255 options, or lots and lots of editing, is probably going to be messy and probably should be recreated from scratch.)
-
For the 255 options I simply added a $poll/post_errors even though is not 100% reliable because this count is based on the number of options ($optionCount), but since the id_poll is not based on that count (because in case an option is deleted the id is not decreased) it could still throw errors...I think I'll see if there is another option.
-
Well, you have another method that you can use - examine $_POST['options'] when it comes in. Pull the array_keys and iterate over them, looking for any values > 255, which can be relied upon to be accurate, as it were.
-
emanuele, aren't you one of the current SMF developers? ;)
(It would seem that they're all lurking here, I reckon... Possibly even more now with all of the SMF bug topics :P)
Re: poll options, I never bothered much about them, but I'd just like to point out that whenever I edit some options (e.g. remove one and replace another), the result will usually be mixed up. Not the number of votes for each item, but the order in which they're shown.
-
emanuele, aren't you one of the current SMF developers? ;)
-
Don't forget to follow our changelogs, we often report SMF bugs there too. (When we're merciful, we specify 'SMF bug' so that SMF devs can easily find them in the logs :P)
I'm definitely curious to know where the SMF dev team currently stands with regards to Wedge, though :)
-
Don't forget to follow our changelogs, we often report SMF bugs there too. (When we're merciful, we specify 'SMF bug' so that SMF devs can easily find them in the logs :P)
I'm definitely curious to know where the SMF dev team currently stands with regards to Wedge, though :)
Personally I'm plain curios (as always I am) to see the final result! :D
And if the question is another: well, I'm too young (in SMF years) to know the full story and I don't like to rely on others' reports and opinions in this kind of matters. ;) So let's say I feel neutral.
-
Oh, it's safe to say that since most of those we thought undermined SMF's community (most notably vblamer) left to other failures, we're fine with the SMF management these days. It's been quite some time since I've been in a flame war with SMF really... Over a year I'd say?
-
Sorry to take this a bit off topic... Why would anyone have so many options in a forum poll?
-
Because they made 1500 logos for their members to choose from? :P
-
You wouldn't normally, but if you keep editing a poll, it might have 255+ different options in its life.
-
It would break other things like layout before becoming another bug nest ;)
-
Sorry to take this a bit off topic... Why would anyone have so many options in a forum poll?
-
"Let's add 10.000 options to see if it crashes the server... And then I'll complain that it's a bug!"
Technically, I doubt anyone would read a poll with a hundred options, let alone answer it...
-
But if you keep re-editing a poll, I guess you could exceed 255, which is how the original bug happened.
-
Even with few options you mean? It's only about the id?
-
Yup. If you have a poll with 3 options, they use ids 0 through 2. Even if you remove something, the next id will be 3.
-
It follows MySQL's AUTO_INCREMENT value, no?
-
That's part of the problem, separately, that it uses the count of items there as the id of the next item to insert (as opposed to tracking what the next item would really be), which is how they get messed up in the first place.
It sort of is auto-inc and sort of isn't... >_<