Shariq Ansari Posted January 30, 2016 Share Posted January 30, 2016 I just discovered yet ANOTHER thing that was unimproved (i.e. reduced in functionality) from 3.X to 4.X: storage/configuration of multi-value member profile fields. 3.X implementation: Multiple values could be configured, each with a unique string that identified it internally These strings were stored back to the database and were human-readable and could be easily searched One could change the order of the values in the list WITHOUT AFFECTING THE UNDERLYING UNIQUE IDENTIFIER... good relational design 101 4.X implementation: Derr we're just gonna stored a comma-separated list of integers that refer to the ordered placement of a string in a list.... Resorting the list actually BREAKS EXISTING VALUES... I just tested this. Guess I'll log a bug... I've seen @Lindy go on and on about how IPS 4.X is a complete rewrite/refactor, and I GET that, and I appreciate that, I really do... but why is that a recurring excuse/explanation for replacing powerful, functional, well-designed feature implementations that have been around for years with LESS POWERFUL, poorly-designed versions? UPDATED: Bug submitted.... listen everyone, you could easily corrupt user data and not even know it... pretty serious, in my opinion: Link to comment Share on other sites More sharing options...
Morrigan Posted January 31, 2016 Share Posted January 31, 2016 How do you mean? You mean the "Select" or something? I don't have that problem with selects and use them liberally and without accord everywhere on all of my sites. Link to comment Share on other sites More sharing options...
Shariq Ansari Posted January 31, 2016 Author Share Posted January 31, 2016 3 minutes ago, Morrigan said: How do you mean? You mean the "Select" or something? I don't have that problem with selects and use them liberally and without accord everywhere on all of my sites. Do you ever add items to the list anywhere other than at the end of the list, and/or resort the list? If so, you've corrupted users' existing selections... I just tried this on my own site... I resorted an existing list and switched the first two options around in the list... and bam, on my user profile, the new option showed up, even though I hadn't edited my own profile setting, just resorted the list... Bad news. The only way to allow for resortable & updateable lists of options AND store options based on their placement in said lists is to have code that runs whenever the list is updated and updates ALL EXISTING USER VALUES to match the new indices. They neglected to do that, so instead, it all just shifts around. They need to switch back to the (vastly superior) IPB 3.4.X implementation, which stored unique strings that could be used to identify user-selected values INDEPENDENT of their sort order in the list... Link to comment Share on other sites More sharing options...
Morrigan Posted January 31, 2016 Share Posted January 31, 2016 I resort the list all of the time. Never had a problem whatsoever. I add to it and move things about to be sure that they are up to date (I have an ever changing directory site). You may not want to submit a bug, you may want to submit a ticket. Link to comment Share on other sites More sharing options...
Shariq Ansari Posted January 31, 2016 Author Share Posted January 31, 2016 3 minutes ago, Morrigan said: I resort the list all of the time. Never had a problem whatsoever. I add to it and move things about to be sure that they are up to date (I have an ever changing directory site). You may not want to submit a bug, you may want to submit a ticket. You do this for multiple-value select fields? Link to comment Share on other sites More sharing options...
Morrigan Posted January 31, 2016 Share Posted January 31, 2016 Yes. All the time. I keep them in alphabetical order. So if I add values they have to be moved from the bottom of the list upward. It's to choose specific multi-value options for easier user browsing. Link to comment Share on other sites More sharing options...
Shariq Ansari Posted January 31, 2016 Author Share Posted January 31, 2016 4 minutes ago, Morrigan said: Yes. All the time. I keep them in alphabetical order. So if I add values they have to be moved from the bottom of the list upward. It's to choose specific multi-value options for easier user browsing. So if you look in the core_pfields_content table for the values provided for one of these fields... you're saying that they get updated for all users when the list is resorted? Because... they're positional. They're stored as integers referring to the position in the list. In order for what you're describing to work, every time you resort the list as you're describing, every last user's existing values would have to be shifted accordingly. I've just tested this and confirmed that that doesn't happen, for me... would you be willing to test yourself and verify that the integer values do get updated? Link to comment Share on other sites More sharing options...
Morrigan Posted January 31, 2016 Share Posted January 31, 2016 That's what I'm trying to get out of you, I didn't understand the problem until just now. You're talking about it "auto changing" the value on the database value on already created records? So: Value 1, Value 2, Value 3 You reorder it to be: Value 1, Value 3, Value 2 And existing one that have them chosen still appear to show: Value 1, Value 2, Value 3 Instead of your updated order? Just to be sure I'm understanding your plight correctly. Link to comment Share on other sites More sharing options...
Marcher Technologies Posted January 31, 2016 Share Posted January 31, 2016 6 minutes ago, Morrigan said: That's what I'm trying to get out of you, I didn't understand the problem until just now. You're talking about it "auto changing" the value on the database value on already created records? So: Value 1, Value 2, Value 3 You reorder it to be: Value 1, Value 3, Value 2 You are correct up til there. He's referring to the fact if a user has provided a selection of value 1 and value 2 while it was configured originally, after updating the field options, it will appear that the user has selected value 1 and value 3 instead in displaying the saved field data. It actually changes the 'value' based on the position in the list. Link to comment Share on other sites More sharing options...
Morrigan Posted January 31, 2016 Share Posted January 31, 2016 7 minutes ago, Marcher Technologies said: You are correct up til there. He's referring to the fact if a user has provided a selection of value 1 and value 2 while it was configured originally, after updating the field options, it will appear that the user has selected value 1 and value 3 instead in displaying the saved field data. It actually changes the 'value' based on the position in the list. Okay, still don't have that problem. @djpretzel Just tested it for you. So I took one of my listings out of the archive: Chose Ghost, Were-Create and Shifter Went into the ACP, here were the before: Here it is AFTER I move and change Vampire (mind you I saved it and went back into it just to be sure it moved and to take the screenshot): Refreshed the listing and they were still the only three chosen: Vampire being where Were-Create was didn't change it: Link to comment Share on other sites More sharing options...
Shariq Ansari Posted January 31, 2016 Author Share Posted January 31, 2016 @Morrigan Those aren't out-of-the-box IPS4 field selections... they seem to allow two values, "Name" and ALSO "Email/ID" which is presumably being persisted back. In other words, the field in question is customized, third-party code that doesn't have this problem. It works like the old, good IPB 3.4.X fields did... Lucky you! Try it with an out-of-the-box multivalue select field... Link to comment Share on other sites More sharing options...
Marcher Technologies Posted January 31, 2016 Share Posted January 31, 2016 Custom Profile Fields Morrigan, not Pages Database Fields. Pages Database Fields have you provide a key, or identifier, with each item, thus this issue doesn't exist there. Link to comment Share on other sites More sharing options...
Morrigan Posted January 31, 2016 Share Posted January 31, 2016 I'm still not able to duplicate this. Done the exact same way before. I just created this field special for this testing on my live site: If you are having a problem, I reiterate submitting a ticket. Link to comment Share on other sites More sharing options...
Shariq Ansari Posted January 31, 2016 Author Share Posted January 31, 2016 31 minutes ago, Marcher Technologies said: Custom Profile Fields Morrigan, not Pages Database Fields. Pages Database Fields have you provide a key, or identifier, with each item, thus this issue doesn't exist there. Ah yeah, what he said At any rate, this is a data corruption bug... and I assume it's been here since 4.X. Not good. Now, let's talk FIXES: Band-aid: Temporary solution would be to not allow editing/resorting of custom profile field multi-select lists, after creation... this represents a loss of functionality - lists are no longer maintainable. Crappy fix: I *suppose* if IPS devs were hellbent on storing these as comma-separated, positional integers... they could write a background process that, WHENEVER a list is resorted/edited, goes through every last member and shifts the values accordingly.... so ugly, though... and inefficient... Slightly less-crappy fix: Store the actual lookup values AND positional values in core_cache somewhere? Better fix: Make them work the same way as Pages, or the way IPS 3.4.X custom profile fields did. If it ain't broke... don't break it... BEST fix: There's a WAY to do this relationally;additional table, core_pfields_content_multiple.... repeating rows for multiple values... my god, it would be beautiful... I'd be fine with band-aid for 4.1.8 and then either better fix or best fix... crappy fix would make no sense.... @Morrigan for your test, did you look at the underlying data in the core_pfields_content table? Did it get shifted? I'll log a ticket to confirm this is a bug... once again, I've done this test on my own site on a field with 10+ values, and it definitely shifted the selection.... here's the proof: Link to comment Share on other sites More sharing options...
Morrigan Posted January 31, 2016 Share Posted January 31, 2016 No. @djpretzel Yes. In my database it still shows "Test 1" and "Test 2". Link to comment Share on other sites More sharing options...
Shariq Ansari Posted January 31, 2016 Author Share Posted January 31, 2016 1 minute ago, Morrigan said: No. @djpretzel Yes. In my database it still shows "Test 1" and "Test 2". In your database it shouldn't show either of those values... it should show comma-separated integers... in core_pfields_content.... e.g. "0, 1" Perhaps you've got additional customizations doing something VERY funky... Link to comment Share on other sites More sharing options...
Morrigan Posted January 31, 2016 Share Posted January 31, 2016 No, no I don't. This is default IPB 4 stuff: It likely means the functionality changed or something in your database isn't correct. Again! I recommend a ticket! I'm sure @Lindy would as well. Link to comment Share on other sites More sharing options...
Shariq Ansari Posted January 31, 2016 Author Share Posted January 31, 2016 @Morrigan How do you KNOW it's default stuff? I'm running ZERO third-party plugins, mods, etc. at the moment... here's what I'm seeing: You seem to be getting comma-separated strings instead of positional integers... somehow.... very interested in the explanation... It's also worth mentioning that even comma-separated value strings have their own problems, in that values cannot be renamed without breaking things... whereas the unique string keys allow that by providing a level of abstraction/indirection between the display value and the persisted key value. You're running 4.1.7? I am. I already logged a ticket, FYI. Link to comment Share on other sites More sharing options...
Morrigan Posted January 31, 2016 Share Posted January 31, 2016 24 minutes ago, djpretzel said: @Morrigan How do you KNOW it's default stuff? While trying not to be offended by the statement of blatant "Are you an idiot?" connotation, Because I know that none of my mods change the behavior of Profiles. Unless you think that my skin, that is controlled by my custom.css is magically changing the submission values somehow. Link to comment Share on other sites More sharing options...
Shariq Ansari Posted January 31, 2016 Author Share Posted January 31, 2016 3 minutes ago, Morrigan said: While trying not to be offended by the statement of blatant "Are you an idiot?" connotation, Because I know that none of my mods change the behavior of Profiles. Unless you think that my skin, that is controlled by my custom.css is magically changing the submission values somehow. Bad faith assumption on your part... I think IPS4 is complicated enough that a smart person, i.e. a non-idiot, might still be confused/unsure about whether a given customization is affecting portions of core functionality or not. At any rate, 4.1.7? Because the implication is, if we both have vanilla (at least in this regard) installations of 4.1.7, it's persisting multi-value custom profile fields quite differently... somehow. Maybe it's a threshold based on the number of values and/or the length of values, I don't know... you could try testing with 10+ list options of 30+ characters each... I'll try and locate the portion of source code that's handling this logic, since we're still waiting on an official response. Link to comment Share on other sites More sharing options...
Morrigan Posted January 31, 2016 Share Posted January 31, 2016 I don't think it would be a threshold issue (yes 4.1.7). Have you tried creating a new field and not edit an old one? Link to comment Share on other sites More sharing options...
Shariq Ansari Posted January 31, 2016 Author Share Posted January 31, 2016 34 minutes ago, Morrigan said: I don't think it would be a threshold issue (yes 4.1.7). Have you tried creating a new field and not edit an old one? I just tried that, and it DOES persist it as strings instead of positional integers... 13 values "Very Long Display Value #1,,cool!", "Very Long Display Value #2,,cool!", "Very Long Display Value #3,,cool!", etc. Persisted as: Quote "Very Long Display Value #1,,cool!,Very Long Display Value #2,,cool!,Very Long Display Value #11,,cool!,Very Long Display Value #12,,cool!" Meaning, I suppose, that at some point IPS were made aware of this issue, and corrected it so that future fields would store strings, but previous ones would keep using positional integers? Or just that fields upgraded from IPB 3.4.X work this way, specifically... Either way, that was a baaaaad decision on their part, and it's still a bug that can and will lead directly to data corruption - I need a way to convert the old fields to use strings instead of integers! And, while I was testing, another bug - if you put a comma in one of the list values, when you go back to edit your profile, the existing selections are removed. Doesn't escape commas properly, in other words. Should really persist a unique string key... IPB 3.4.X had this down perfectly... and IPS Pages 4.X seems to do it right, too... Link to comment Share on other sites More sharing options...
clearvision Posted April 21, 2017 Share Posted April 21, 2017 In the process of converting my 3.4 site and just ran into this. Had a select field with statefilename=State Readable Name pairs. Now only have State Readable Name which of course can't be used to get to the flag images. So all users will lose this field. Not sure yet how to do this again on 4.x. Also now to use select field you have to enter each by HAND? Before you could paste in your entire set of select data from an editor or other source. Sigh. I'll also add this was nothing special... the example for the field formatting box in 3.4 to show you how to use select was this: {title} is the title of the custom field, {content} is the user added content. {key} is the form select value of the selected item in a dropdown box. Example: <span class='row_title'>{title}:</span><span class='row_data'>{content}</span> Example: <span class='row_title'>{title}:</span><span class='row_data'><img src='imgs/{key}'></span> And now they drop the key part entirely. Link to comment Share on other sites More sharing options...
Joy Rex Posted April 21, 2017 Share Posted April 21, 2017 So for users who are considering Pages in 4.x for the first time (e.g. not converting from a previous 3.4.x install), is this still a concern? Link to comment Share on other sites More sharing options...
clearvision Posted April 21, 2017 Share Posted April 21, 2017 9 minutes ago, Joy Rex said: So for users who are considering Pages in 4.x for the first time (e.g. not converting from a previous 3.4.x install), is this still a concern? My comment had nothing to do with Pages. This is the built in member profile "extra" fields in the core. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.