[buddypress-trac] [BuddyPress Trac] #5500: Date xprofile field enhancement

[buddypress-trac]

#5500: Date xprofile field enhancement
----------------------------------+------------------
 Reporter:  sooskriszta           |       Owner:
     Type:  enhancement           |      Status:  new
 Priority:  normal                |   Milestone:  2.6
Component:  Component - XProfile  |     Version:
 Severity:  normal                |  Resolution:
 Keywords:  needs-patch           |
----------------------------------+------------------
Changes (by boonebgorges):

 * keywords:  needs-patch good-first-bug => needs-patch


Comment:

 [attachment:5500.diff] regenerates the patch from the `buddypress`
 directory, so it can be properly applied, and removes a PHP short tag that
 was throwing a fatal error on my installation.

 A lot of the work here is really good. Aside from coding standards, the
 one thing that's making the patch hard to follow is the data storage. Some
 settings are stored in an `option` called `BPOptRegData` (which seems to
 set the defaults for the fields?), while other settings are stored in
 child fields of the date field. Neither of these seem well-suited to the
 purpose. I think it's probably appropriate to store all settings related
 to a field in a single array (which will be auto-serialized by WP) using
 `bp_xprofile_update_meta( $field_id, 'field' ... )`. Fallback values
 (`BPOptRegData`) can be defined in code.

 As for the UI:
 * I am convinced that the `date_format` stuff is good, and should go in
 with just a few tweaks.
 * Idea: "Show time elapsed" should be one of the date formats instead of a
 separate checkbox. To make things consistent, instead of using today's
 date to demonstrate the formats, always use the same one - say, March 1
 2012 - and then the "elapsed" option can be dynamic - "4 years" or
 whatever. We could also have an additional one that is formatted as "4
 years ago".
 * The "range" stuff seems like a good feature, but I think it should be
 simplified: just have a start year and an end year. I understand why you
 might want to have the dynamic "ago" feature, but the UI here is
 confusing, and incomplete - there's no way to add future dates. Forcing
 the user to enter years makes it more flexible and clearer. If we
 absolute, positively must have more complex options here, I suggest the
 following option format:

 {{{
 () from { 1982 } to { 2023 }
 () from { 34 } [ years ago ] to { 7 } [ years from now ]
 }}}

 where {brackets} are text inputs and [brackets] are dropdowns.
 * Another idea. If the `date_format` selected doesn't include year (or
 month or day), we shouldn't include it in the front-end interface.

 Is this sufficient feedback for another go-round? My gut feeling is that
 we will have a better chance of getting something done for 2.6 if we scale
 back a bit: if we, say, do the date format stuff first. But if
 @sooskriszta and @abweb feel that it's possible to do it all at once,
 let's go for that :)

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