[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:  has-patch 2nd-opinion  |
-----------------------------------+-----------------------

Comment (by WCUADD):

 I omitted to tell that I follow the guidelines proposed by the first fix
 here in changeset 8554 by only adding `AND $x != '0'` to the `empty($x)`
 check. The `empty()` problem can be solved with different methods as you
 pointed. That's the reason why I indicated all '''the places that
 currently prevent to set '0' value in required xprofile fields'''.

 Note that this problem can have a lot of consequences when BP is in
 production. For example, asking for the number of children living in the
 household (in an intentional communities purpose) as a required field
 prevent users to register! Two solutions were considered : either to keep
 off the required caracter of the data (not recommanded in this case)
 either to modify the core files.

 As I understand it, at the first place these `empty()` checks were here
 only when the xprofile field has been marked as 'required', not for the
 purpose of checking the compliance of the value with the field type.

 It seems to me that there are three levels of checks for an xprofile field
 (from the lowest level relevant to data type to the highest level relevant
 to the data semantics)
 - compliance with the type (linked with `is_valid()` method)
 - compliance with the 'required' caracter (determined by the administrator
 when creating the xprofile field) which is a different check than the
 compliance with the field type.
 - another level which has not be treated: to allow the developper to add
 his own control / intelligence over the xprofile fields. Of course, BP
 does not have to deal with all the fields cases as some specific plugins
 can deal with, but it would be appreciated to give the possibility to the
 developper to add his own check routines which are therefore very
 dependant from the data semantics (ie postal codes, telephone numbers, or
 whatever...). What I'm thinking here is to add a simple hook to allow
 other types of controls to be added. This has relation with the way errors
 are rendered which was the subject of #5738.

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