[buddypress-trac] [BuddyPress Trac] #5738: Improve error handling for xprofile fields (and non-xprofile fields) during registration and profile edit (was: Required xprofile fields errors management in members/single/profile/edit.php)

[buddypress-trac]

#5738: Improve error handling for xprofile fields (and non-xprofile fields) during
registration and profile edit
-------------------------+------------------
 Reporter:  WCUADD       |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  high         |   Milestone:  2.2
Component:  XProfile     |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  needs-patch  |
-------------------------+------------------
Changes (by boonebgorges):

 * priority:  normal => high
 * milestone:  Future Release => 2.2


Comment:

 Thanks for the comments, WCUADD. You've spelled out some of the
 architectural problems well. I'm changing the name of this ticket to
 reflect the task more accurately, and I'm going to increase the priority
 and put it in the 2.2 milestone.

 My short response: this set of issues is turning out to be a major
 annoyance, but to fix it will require a fair amount of refactoring of the
 registration process as well as some additions to
 `BP_XProfile_Field_Type`.

 Slightly longer response:

 It sounds to me like you are *not* misunderstanding things. The
 registration system was written largely separately from the xprofile edit
 system, and the two were pieced together in a quick-and-dirty way to make
 them work. The introduction of `BP_XProfile_Field_Type` is making this
 already existing problem more obvious, because all our nice type-specific
 `is_valid()` routines are in stark contrast to the total inability to
 display field-specific error messages.

 > Am I wrong thinking that it should belong the BP_XProfile_Field_Type
 classes in a similar way as the is_valid() method?

 I've been thinking the same thing. Field types should be able to register
 their own custom error messages. In fact, if this is the case, we may be
 able to do away with some of the global juggling that we're currently
 doing (since we can create new `BP_XProfile_Field_Type` objects on the
 fly).

 > if all types of checks are performed somehow within the is_valid()
 method, it would say that they are performed when trying to set the field
 data in xprofile_set_field_data() which is relatively late to detect
 errors?

 Yes. We don't actually record the xprofile data during registration - we
 store it in wp_signups. This means that, during registration, we're going
 to have to run `is_valid()` manually on the submitted data.

 > the fact that it has to be extended to other fields than xprofile fields
 (in the registration case)

 Right. Let's design it to work the way we want it for xprofile field types
 first. Then, we can build wrappers that mimic this architecture for error
 reporting related to email address, password, etc.

 So, let's think big for 2.2. I've got some vague ideas for how we could
 build out `BP_XProfile_Field_Type` and use it to do some of the work
 required here, but WCUADD (and others!), you should feel free to put your
 ideas here too, either in the form of comments or rough patches.

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