Wedge
Public area => The Pub => Bug reports => Topic started by: Farjo on February 20th, 2013, 05:59 PM
-
This is on SMF and it seems the same on Wedge. We have a Custom Profile Field of field type Select Box, with about 10 values. If one of these values is changed then all its values are removed from the themes table and those members who formerly had this value will now have none.
The work around is to use sql to update the themes table to the new value for the appropriate members, then come back to SMF / Wedge to change the field value.
I.e. run this:
update `themes` set value = 'New Value' where variable = 'cust_sbox' AND value = 'Old Value'
Is this an old bug or is editing the values beyond the idea of select boxes?
-
It's an old bug - it's fundamental to SMF's implementation.
It's actually something I tackled in SimpleDesk so I do know how it can be tackled, but it's horribly messy.
Essentially yes, the actual value is stored in the themes table, rather than a pointer to the relevant item, if that makes sense (so instead of storing 'New Value', you could store the number of the item)
That does have some other interesting consequences so I have been wary of suggesting it or acting on it, though, especially as I've debated adding in 'multi select' (i.e. picking 1+ items from the list rather than just 1) as I did in SimpleDesk, but that has the same issues. It also then gets into the situation where you potentially need to be able to reorganise the list of items.
-
Fair enough :)
Yes it is a bit of an odd setup. When I was first looking for the values I was looking for profile field tables; putting it into themes is bizarre!
Maybe a rough and dirty 'fix' then is to make it clear that the values cannot be amended once used. At the minute the help says:
"Reordering Options: You can reorder the options by moving text around between the boxes. However - an important note - you must make sure you do not change the text when reordering options as otherwise user data will be lost."
I guess this should be changed as it gives the impression that you can change the text when not reordering the options, without losing data.
Luckily I tried it on test data first :^^;:
-
Yes it is a bit of an odd setup. When I was first looking for the values I was looking for profile field tables; putting it into themes is bizarre!
Firstly, there's no additional queries to get the data for the user's profile area - it will automatically be loaded for the user.
Secondly, the themes table already holds per-user information of indeterminate amounts, as that's where preferences are set. Given its heritage as a mod-that-became-a-core-feature-because-the-original-author-later-became-a-dev, it is not really surprising.Maybe a rough and dirty 'fix' then is to make it clear that the values cannot be amended once used. At the minute the help says:
-
I see, although I'm surprised that in this day&age there's a problem with making more queries (not doubting you - just surprised).
-
There is a *perceived* problem with more queries. And to a degree there is a valid issue - if you have to make too many queries per page, something is wrong.
I don't usually have an issue when the number caps at about 20 per page when it's a complex page. Or it's got lots of plugins. But I see issues when you get into 50+ queries per page, like vB 5 betas that make 60 just to get a single topic. Without modifications.