Wedge
Public area => The Pub => Features => Topic started by: Arantor on March 5th, 2012, 12:28 AM
-
Sorry for yet another topic about a single admin setting, but I think it needs a bit of discussion.
Admin > Configuration > General > Poll Mode
You can set it to enable polls (default), disable polls, or show polls as topics. This is a bit weird, so let me explain.
If you disable polls (as opposed to show polls as topics), the poll+topic is actually hidden, it's hidden in message index, it's hidden in unread/unreadreplies, though you can still access the topic directly (which seems to me to defeat the point a bit). If you just 'show polls as topics', it's as though the poll was never added and there are no permissions to add/vote etc.
I don't know about you, but I never came across anyone who ever did properly disable polls, it's always done with permissions rather than outright turning them off (which says to me that people don't realise the option's there) and even if they did know it was there, I can't really see people using it.
So, I'm proposing to remove it, but I want to be sure that no-one's going to use it if I do. It isn't something that can be easily added back with a plugin.
-
I've always handled polls via permissions so I guess I wouldnt miss it, heck I wasnt even aware of it :P
-
There's all sorts of things like that in SMF's admin panel, which is why I've been so despairing of it!
If I had more options to polls I'd do what I've done for Who's Online, and make a page out of it, but I can't think of any other options anywhere else in the admin panel that are related to polls.
-
Never noticed it to be honest, and even if I had I would have never used it.
-
So it only affects existing poll threads:- from the option's help "Remember this if polls are not working." Maybe in the early days polls were a frequent problem and kept preventing the board / thread from loading / displaying. So this option was written so the admin could turn them off pending a fix, and it has never been removed??
Can't see a use for it now - as said if we decided we didn't want polls anymore we'd do that via permissions and let the existing ones time out or lock them or whatever.
-
I'm not sure of the historical basis for it, but I guess at some point people asked for it to be disabled and it got included, but that must have been a long time ago, it's certainly in 1.1, probably in 1.0 and I suspect it may even be in YaBBSE, though I've not actually used it.
-
+1 for removal.
Would also like to discuss making polls linked to posts rather than topics. And most importantly, multiple polls per post, ie non-unique key.
-
I'm not clear why you'd want multiple polls per topic, either directly or one per post (which allows multiple per topic), what use would it have?
-
So I killed the old poll mode setting in r1436. What benefits does reorganising things for multiple polls give us?
-
Logo madness. Have a poll for font and a poll for logo. Things like that.
Is it that hard to allow for more polls?
I don't remember the codebase much. Honestly as you may have noticed, I'm struggling irl, closing on a burnout, unable to catch up with all your changes. I haven't even read any more of these new topics or my few new PMs. I'm totally lost. Help.
-
No, it isn't that hard, really. We convert the poll id to has_poll, a bool. This allows us to fix up all the edge cases like unread replies where the icon is used. Then in Display, we check for has_poll, query for poll details and push to $context. There is actually a mod for it that can be examined, if inspiration is needed.
I had sort of noticed, with my getting streaks of half a dozen commits. Don't worry about reviewing my stuff, I'm not doing that much in the way of "big stuff" so most of it is not only modestly sized, but modestly scaled, the admin panel stuff is mostly minor tweaks, no matter how big it sounds.
All I can say is that you shouldn't worry about loading yourself up too much, you've been very, very busy lately, and you deserve a break to recuperate.
All the "big stuff" that's really left for now is stuff I need to do, so kick back and I'll dig in.
-
No, it isn't that hard, really. We convert the poll id to has_poll, a bool. This allows us to fix up all the edge cases like unread replies where the icon is used. Then in Display, we check for has_poll, query for poll details and push to $context. There is actually a mod for it that can be examined, if inspiration is needed.
All the "big stuff" that's really left for now is stuff I need to do, so kick back and I'll dig in.
I think I'll get back to this today. A bit.
-
I don't know of any mods that aren't in use at Wedge.org, not exactly the area of SMF I played with the most...
I still need to finish topic and thought privacy...
I think I'll get back to this today. A bit.
-
Is this something that we need in the core? Or something we should look at making a plugin?
(It would certainly be easier to support in the core, I'm just trying to understand if we 'really need' it or not.)
I would note that if we plan on doing 'who voted what' as we talked about, it's going to get awful crowded awful quick.
Also, I'm thinking of setting it up so that there are 10 classes applied to the poll bars, so that the first one is .pollbar .bar1 or whatever, so that themers can - if they want - get the vB look and feel of having different coloured poll bars, but that they're still consistent otherwise.
-
Is this something that we need in the core? Or something we should look at making a plugin?
I would note that if we plan on doing 'who voted what' as we talked about, it's going to get awful crowded awful quick.
Anyway, we don't NEED to show the names to everyone. We don't even have to show them immediately to admins... For instance we can add a small button to retrieve the names through Ajax or just show them via JS.Also, I'm thinking of setting it up so that there are 10 classes applied to the poll bars, so that the first one is .pollbar .bar1 or whatever, so that themers can - if they want - get the vB look and feel of having different coloured poll bars, but that they're still consistent otherwise.
-
Sure it's already recorded, it just needs displaying.
Regarding vB, it is similar to SMF/Wedge, just you have different coloured bars, one bar red, one purple, one blue etc. All I'm saying is to add classes to differentiate the bars, for style purposes.
-
Oh... I see. I didn't read that through :P
I guess it makes sense indeed. Not in the default skin though ;)
-
Oh I didn't expect the default skin to do that, just have the classes to support it ;)
-
We should make sure these classes are set on the list items, not the bar divs :)
-
As long as it lets me style the bars like I'm suggesting, it's all good.
-
I'm looking into adding support for multiple polls right now.
A few things.
- I can either add an id_topic to the poll table, or allow for comma-separated poll IDs in the topic table (or both!) What do you like best? The table solution simply requires adding an extra key (on id_topic), seems simple enough. The poll ID list should be okay too, in the sense that when in Display, we can easily query for the poll details by using id_poll IN ({string:poll_ids}).
- I noticed that poll questions are limited in size -- varchar(255). I *think* it might make sense to make that size larger, for specific cases... Maybe even a varchar(65535) would be okay (or just varchar(20000) to account for UTF8, or whatever...)
Heck, if you look into the database structure, there are dozens of varchar(255) that could really benefit from being switched to a larger size, now that we're requiring MySQL > 5.0.3 anyway... Thing is, it's best to do it now. We could still add some sort of converter to the upgrader code when we release new versions, but it's simpler now.
Oh, and while I'm at it... Maybe we could do without the upgrade script? Maybe we could have it inside the admin area... And call it automatically if we find out that the current database version is different from the current Wedge files version. Ask for users to fill in their admin password, and launch the upgrade process... Thus, no files to remove after the upgrade.
-
- I can either add an id_topic to the poll table, or allow for comma-separated poll IDs in the topic table (or both!) What do you like best? The table solution simply requires adding an extra key (on id_topic), seems simple enough. The poll ID list should be okay too, in the sense that when in Display, we can easily query for the poll details by using id_poll IN ({string:poll_ids}).
I noticed that poll questions are limited in size -- varchar(255). I *think* it might make sense to make that size larger, for specific cases...
Heck, if you look into the database structure, there are dozens of varchar(255) that could really benefit from being switched to a larger size, now that we're requiring MySQL > 5.0.3 anyway...
Oh, and while I'm at it... Maybe we could do without the upgrade script?
-
- I can either add an id_topic to the poll table, or allow for comma-separated poll IDs in the topic table (or both!) What do you like best? The table solution simply requires adding an extra key (on id_topic), seems simple enough. The poll ID list should be okay too, in the sense that when in Display, we can easily query for the poll details by using id_poll IN ({string:poll_ids}).
I've never verified this, but my reading of the rather-vague documentation in MySQL suggests that when using UTF-8 that's actually storing UTF-8 characters, you store them based on the actual number of characters, not the number of bytes. (Certainly it makes reference to CHAR(10) fields in UTF-8 tables taking 30 bytes, as it has to account for 3 bytes per character) This suggests we'd still end up with 255 characters' worth of question even when using multibyte characters, but this needs verification to be sure.
http://dev.mysql.com/doc/refman/5.0/en/string-type-overview.html#id804512 (i.e. VARCHAR(255) allows for 255 *bytes*, not chars)
http://dev.mysql.com/doc/refman/5.0/en/column-count-limit.html (implies otherwise in the first VARCHAR example.)
I guess it would need testing...There's a world of difference between 'could really benefit' and 'might be useful', and actually the only ones that stand out in my head as being useful are things like the topic subject. I'm not sure that most fields which are varchar(255) would actually benefit.
Interesting idea, though I'm not worried about it at present, that's what beta is for, right? :P
-
I thought that having a 0/1 choice only in a key was going to hurt performance..? Like t.approved?
In terms of indexing, we never query based on 'has poll/has no poll' so it doesn't need to be added to any of the indexes on the topics table.The MySQL documentation tends to contradict itself on this.
In our case, VARCHAR(255) means 255 characters but that it will probably need a 2 byte length in UTF-8 because 129 Japanese characters, for example, will overflow 255 bytes in physical length.
This is ultimately where the performance penalty of using UTF-8 comes in, where you're expressly not using a single byte character set where you don't have to worry about byte length vs character length.Plenty that I could think of when seeing the list, really...