[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.7
Component:  Extended Profile         |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |
-------------------------------------+------------------
Changes (by boonebgorges):

 * keywords:   => has-patch needs-testing
 * milestone:  Future Release => 2.7


Comment:

 [attachment:5500.2.diff] reworks the most recent patch from @abwebstudio1
 for better accordance with coding standards and other WP/BP conventions.
 @abwebstudio1, I hope I haven't stepped on your toes too much by doing
 this myself - I thought it would be instructive for both of us ;) Here's a
 summary of changes I made:

 - Instead of storing some options as field children, I've moved them to
 xprofile meta.
 - I've overhauled the routines for validating and fetching settings, and
 renamed settings to make the naming conventions clearer.
 - Made strings localizable.
 - Some improvements to markup in the Edit form.
 - Moved inline scripts and styles to enqueued files.
 - Removed some parts of the patch that appear to be left over from an
 earlier implementation (stuff like 'show-time').
 - Removed some purported bugfixes. One was related to the 2038 bug. The
 other appears to be related to the way that d/m/y dropdowns are converted
 to date-time and then saved on profile edit. For one thing, I'm not
 convinced that either one fixes a real bug, or at least doesn't fix in
 quite the correct way. (For example, 2038 is only a problem on 32-bit
 systems.) More importantly, they don't seem to be directly related to this
 ticket, so I'd like to handle them separately if they are indeed issues.

 Most of the functionality is the same. A few small changes:
 - Instead of "example" text after the custom format, I've mirrored what WP
 does on Settings > General, and render an example dynamically. It looks
 like you had originally done it this way, but abandoned it for some
 reason.
 - Changed some styling.
 - Moved the Documentation link so it's right after the 'Date format'
 block.

 Looking for general feedback on the following:

 1. I feel that the 'Date format' section is pretty good, but I feel less
 confident that the Range interface makes sense. Does the difference
 between the two radio buttons make sense to others? Is there a better way
 to do this?
 2. Related: the 'years ago'/'years from now' dropdown poses some
 localization problems. I'd like feedback from a polyglot on how they're
 implemented. I'm pretty sure they'll work for French and Russian (two
 languages I speak well enough to judge) but I have no idea about other
 languages.
 3. I made a few small mods to the `BP_XProfile_Field(_Type)` API to make
 it all work. Specifically, I introduced
 `BP_XProfile_Field::admin_settings_save()`, which is called during the
 admin save routine; this method then calls `admin_settings_save( $field_id
 )` on the field-type object. I figure that this is a good way to suggest
 the convention that field-types should be responsible for how their
 settings get saved. (`BP_XProfile_Field_Type()` has a stub
 `admin_settings_save()`, which should be overridden by subclasses.)
 @DJPaul Does this approach make sense to you?

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