[buddypress-trac] [BuddyPress Trac] #5731: text/number profile fields not rendered if value == 0

[buddypress-trac]

#5731: text/number profile fields not rendered if value == 0
--------------------------+-----------------------
 Reporter:  DJPaul        |       Owner:  djpaul
     Type:  defect (bug)  |      Status:  reopened
 Priority:  normal        |   Milestone:  2.1
Component:  XProfile      |     Version:  1.0
 Severity:  normal        |  Resolution:
 Keywords:  needs-patch   |
--------------------------+-----------------------

Comment (by WCUADD):

 I'd like to add a comment even if I'm not sure that it can be valuable for
 your collective thoughts at this point.

 Managing the '0' value case for required xprofile fields is clearly an
 edge case. Nevertheless, for those who meet this problem, it really seems
 a bug as it is not easily understandable why the users can't register when
 fixing a (semantic) valid '0' value in a required xprofile field.

 Another side effect is when updating profile with a consequent number of
 fields in a group fields: the only screen difference between failed or
 successful profile update is a global message. From support experience, I
 can tell that users stayed puzzled and didn't understand it, as they took
 care to enter values in all required fields, and that another substantial
 proportion of users did even not see the warning (although highlighted
 with CSS), they thought that it was OK and left the screen and much later
 on, they realized they lost their data. Support returns were it was very
 discouraging.

 Correcting the bug is nearly impossible without going deep into the core
 code, leading to the solution to keep off the required caracter of the
 fields that can semantically take the '0' value, but it is a very simple
 and easy way to cope with it.

 '''Far away from me to suggest that this problem should be corrected for
 2.1, I'm just exposing the user point of vue if it can be helpful in some
 way. In my humble opinion, it sounds to me much more like something which
 is important but with low priority.'''

 However, what I'm militantly in favour of is to give the developper the
 possibility to add its own control routines if needed, what I described as
 "semantic checks" in comment:12. It's obvious that BP does not have to
 include all possible checks and plugins can be usefully relied on this.
 But often, it seems a waste to use a plugin that can deal with a lot of
 cases when you only need to add a few simple additional checks. And this
 could be possible with a simple "open door".

 When modifying the code to rationalize the field validation process, do
 you think it could be desirable / possible to add a hook mecanism for this
 purpose (possibility for a developper to add his own semantics checks) ?
 Thank you for reading and examining this suggestion. Please forgive me in
 advance if this is not the right place to mention this possible
 enhancement, as this ticket has given rise to field validation process in
 a wider way.

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/5731#comment:15>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac