Skip to:
Content

Opened 2 years ago

Last modified 13 days ago

#5500 new enhancement

Date xprofile field enhancement

Reported by: sooskriszta Owned by:
Milestone: 2.6 Priority: normal
Severity: normal Version:
Component: Component - XProfile Keywords: needs-patch
Cc: vivek@…

Description

I can't claim that this will useful for all or most communities. I do believe that many communities, especially "social networking"-type communities will find it valuable.

This could be formed by 3 dropdowns: one each for date, month and year. The sequence of the dropdowns should be dictated by the date format selected by admin in WordPress settings.

There should be 2 mutually exclusive options (checkboxes):

  • Show year in public profile (unchecked by default) - so by default the public profile shows only date and month.
  • Show age instead of date of birth (unchecked by default) - overrides previous option..if checked the profile shows calculated age in years (today - dob), instead of the date of birth

The admin should also have the right to limit registration/profile access by age. e.g. A checkbox and a textbox in admin panel
Only allow members over years of age (unchecked by default)
In frontend, the dropdowns only list dates that would make the member's age over the admin-specified minimum age. If admin has not selected any minimum, then the member's age should be at least 0 days.

Standard validation rules for dates apply.

Attachments (10)

enhanced-date-field.png (78.6 KB) - added by sooskriszta 23 months ago.
Suggested "enhanced" date xprofile field UI wireframe
buddypress-15-07-24--10-25.zip (1.9 MB) - added by axelskynet 10 months ago.
The file contains a version of the plugin and the patch file for it.
1.PNG (53.1 KB) - added by sooskriszta 9 months ago.
Date of birth (actual screenshot)
2.PNG (52.7 KB) - added by sooskriszta 9 months ago.
Age (actual screenshot)
date-field-patch#1.zip (7.1 KB) - added by abweb 4 weeks ago.
date_field_patch#1_abweb.patch (30.1 KB) - added by DJPaul 4 weeks ago.
5500.diff (19.3 KB) - added by boonebgorges 4 weeks ago.
5500_update.patch (21.8 KB) - added by abwebstudio 3 weeks ago.
Updated patch
screen_patch1_01.png (35.4 KB) - added by abwebstudio 3 weeks ago.
Screenshot of new UI
screen_patch1_02.png (24.8 KB) - added by abwebstudio 3 weeks ago.
Screenshot of working field value examples

Change History (51)

#1 @boonebgorges
2 years ago

Thanks for the detailed request.

IMO, this is too specific for a field *type*. Date of Birth might be of interest to many communities, but the underlying logic - a field that allows for date input, and can display it in a number of different ways - could be used for many other purposes.

So, I'm going to propose that instead, we use this ticket to discuss ways of improving our existing Date field. I can imagine adding the following:

  • Show "time elapsed" instead of the date. This would be roughly equivalent to the "Age" feature requested above. So you'd enter "September 4, 1934" and the display value would be, say, "80 years ago"
  • Options for which dates to show. Past only, present only, specific year ranges
  • Time + date

The stuff about restricting site membership based on age/DOB does sound useful, but I think it's pretty straightforwardly plugin territory. On the bright side, if we built an enhanced Date field type, extending this to cover Age more specifically would be extremely easy.

What do you think?

#2 @sooskriszta
2 years ago

Your note makes perfect sense to me.

We should build in the "privacy" filter - don't show year - if possible, though.

Last edited 2 years ago by sooskriszta (previous) (diff)

#3 @sooskriszta
2 years ago

  • Cc vivek@… added

#4 @sooskriszta
2 years ago

  • Summary changed from Custom xprofile field: Date of birth to Date xprofile field enhancement

#5 @DJPaul
2 years ago

  • Milestone changed from Awaiting Review to Future Release

#6 @DJPaul
2 years ago

My gut feeling is many simple fields will be a better/less complicated UI than just a few field types with various options to configure behaviour (I imagine power users would appreciate the fine-grained control, but we're trying to build for the 80%).

#7 @boonebgorges
2 years ago

I agree with that idea in general, but I think that a simple toggle for setting beginning and ending dates for the date field might be an exception. It's hard to think of a use case for the date field where these settings *wouldn't* be useful. That said, I'm willing to listen to the wisdom of the crowds on this point.

#8 @DJPaul
23 months ago

See also #5646

We should agree how we want to approach this sooner rather than later, because we've had tickets from multiple people for each approach.

#9 @sooskriszta
23 months ago

I am convinced that DOB is too specific.

Let every date field have 3 additional features:

  • Show year (On by Default). If admin switches this off, then in the public front-end only date and month are shown, e.g. 1 January
  • Dates to list: year x to year y, or from x years before today to y years before today (accept negative values for x and y to allow for future dates)
  • Show time elapsed i.e. Today - Date. I differ from Boone on the language used though. I'd say simply 80 years, not 80 years ago. Here's why: Showing age: 37 years makes more sense than 37 years ago Showing countdown: If Today - Date is negative, i.e. we are counting down to an even in the future (say birthday party) then we don't want to grapple with a separate text string...we just want to say 15 days

#10 @boonebgorges
23 months ago

sooskriszta - Thanks for the feedback. But the UI you're suggesting here, as I'm envisioning it, would be several times more complex than what I think we're leaning toward. Those three additional features will translate into four or five different settings of different types. Any chance you might want to mock up how you imagine the interface looking?

The options laid out by sooskriszta are helpful in that they show all the different ways that date fields might be used. It's pushing me more in the direction of DJPaul's position that we should probably just have separate field types. That said, I do think that (eg) a DOB field still should have some settings; some sites will want to set the earliest date to be 12 years ago, while others may want it to be 21 years ago, etc. I also think there's some merit to having the option for a DOB field to display as age.

Would it maybe be helpful if we came up with three or four examples of how date fields might be used. That would help us to get a sense of where the use cases intersect, and what if anything would go into a general "Date" field in terms of settings/UI.

@sooskriszta
23 months ago

Suggested "enhanced" date xprofile field UI wireframe

#11 @sooskriszta
22 months ago

  • Keywords dev-feedback added

This ticket was mentioned in IRC in #buddypress-dev by OC2PS. View the logs.


22 months ago

#13 @boonebgorges
18 months ago

#6038 was marked as a duplicate.

This ticket was mentioned in Slack in #buddypress by oc2ps. View the logs.


17 months ago

#15 follow-up: @johnjamesjacoby
14 months ago

A few ideas here:

  • Is there an existing date-picker JavaScript library we can lean on?
  • Is there an existing PHP library that would map date & time formats to fields with appropriate boundaries?
  • Date & time fields could have many different usages and permutations of combinations. Are there any event calendar plugins that are doing this really well we can learn from or partner up with?
  • I think I would ultimately like to see our "Date" field replaced by a more robust "Date/Time" field. One with a few popular options to choose from (date only -- all day, date & time, date range, date & time range, etc...)
  • Make it so fields are mapped to WordPress's format, and not hard coded to Day/Month/Year order

In general, I think there is good discussion happening here. Our current Date field is not ideal, but exactly what is ideal likely needs to influenced by other successful projects that use dates & times.

#16 in reply to: ↑ 15 @sooskriszta
14 months ago

Replying to johnjamesjacoby:

  • I think I would ultimately like to see our "Date" field replaced by a more robust "Date/Time" field. One with a few popular options to choose from (date only -- all day, date & time, date range, date & time range, etc...)

JJJ, I feel date (date only) and date range (event - all day, datetime range) have very different use cases. Date seems more appropriate for profile fields. While date range is more of an event-based field - perhaps more suited to a new "Events" component.
e.g. Profile field: Date of Birth
Events field: Birthday party date/time

@axelskynet
10 months ago

The file contains a version of the plugin and the patch file for it.

#17 @sooskriszta
10 months ago

  • Keywords has-patch added; dev-feedback removed

In my testing patch works well.

#18 @DJPaul
9 months ago

  • Keywords needs-testing added
  • Milestone changed from Future Release to 2.4

Thanks again for the patch. Not convinced that we should do this yet, but we'll definitely take a look at your work.

Can whoever tests this first attach some screenshots of the UI changes to this ticket? They'd be interesting to see.

#19 @sooskriszta
9 months ago

The UI is very similar to my wireframes actually.

@sooskriszta
9 months ago

Date of birth (actual screenshot)

@sooskriszta
9 months ago

Age (actual screenshot)

#20 @axelskynet
9 months ago

We have added the text note "Note: Year range is allowed between 1902 and 2037 years only." because the core has year restriction http://share.redix.ru/s/?file=andreyivanov/2015-07-25_0115.png&w=598&h=366. Even if user selects the year out of this range it will be saved but will not be shown on Frontend. BuddyPress developers can fix this issue if it will be needed.

This ticket was mentioned in Slack in #buddypress by oc2ps. View the logs.


9 months ago

#22 follow-up: @boonebgorges
9 months ago

I'm coming around to the idea of including these features, but I think the suggested UI needs some refinement. Some thoughts/ideas, for discussion:

  • Let's break out the options into a separate metabox - "Field Options" or something like that. Or maybe even two separate metaboxes: "Range" and "Format"
  • The year/no-year checkbox is kinda arcane. If we're going to support this, let's make a more general set of formats, so that admins can decide in a more fine-grained way how they want dates to be formatted. The easiest way to do this would be to provide a set of hardcoded formats: "February 25, 2015", "February 25", "2015-02-25", etc. More complex would be a free-form field with swappable placeholders, akin to PHP's date() (but more user-friendly). Defaults should be sensitive to localized date values/WP settings.
  • We could use better labels for the two radio buttons related to Range. I suggest something like "Fixed" and "Dynamic".
  • If we're going to make these improvements, we can remove the 1902-2037 restriction, which I'm sure was implemented to avoid problems with freeform data entry.

Thanks for your work on this so far!

#23 @DJPaul
9 months ago

The 2037 thing was to prevent bugs based on how PHP handles dates on 32bit operating systems. I know it was a UI-only "fix" because people can send whatever value in the form submission, but figured that was a harmless edge case. See https://en.wikipedia.org/wiki/Year_2038_problem (I took one year off of that for safety).

I forget why I took it down to 1902, but probably a related reason.

As long as we can dynamically find out the maximum year supported in PHP, we should be able to implement the restriction only for affected sites.

#24 in reply to: ↑ 22 ; follow-up: @sooskriszta
9 months ago

Replying to boonebgorges:

  • The year/no-year checkbox is kinda arcane. If we're going to support this, let's make a more general set of formats, so that admins can decide in a more fine-grained way how they want dates to be formatted. The easiest way to do this would be to provide a set of hardcoded formats: "February 25, 2015", "February 25", "2015-02-25", etc. More complex would be a free-form field with swappable placeholders, akin to PHP's date() (but more user-friendly). Defaults should be sensitive to localized date values/WP settings.

Can't say I understand what you mean. Could you rephrase/elaborate?

At the moment year/no-year checkbox literally does exactly what it says on the tin.
If year shows 1 Jan 2016 (based on WordPress date format), then no year shows 1 Jan.

#25 in reply to: ↑ 24 @boonebgorges
9 months ago

Replying to sooskriszta:

At the moment year/no-year checkbox literally does exactly what it says on the tin.
If year shows 1 Jan 2016 (based on WordPress date format), then no year shows 1 Jan.

Yes. But what I'm suggesting is that this checkbox is too specific to your use case for us to adopt in BuddyPress. What if I only want to show years? Only months? Only month + year? There are valid use cases for all of these. So I'm suggesting one of the following:

  1. A curated list of format options. Maybe a radio button of options like:
* February 23, 2015
* February 23
* February 2015
* February
* 2015
  1. A parameterized system for defining your desired format. Perhaps we'd define some subset of PHP's date() syntax, maybe something like this:
Enter your desired date format. Use the following placeholders for various parts of the date:
  - %F - Full month name (eg, January)
  - %m - Month number, with leading zeroes (eg, 04)
  - %d - Day number, with leading zeroes (eg, 13)
  - %j - Day number, without leading zeroes (eg, 4)
  - %Y - Year number
  etc

Format: [ %F %d, %Y ] (February 23, 2015) // this would maybe update dynamically as a preview

These are just some ideas. It would be very valuable to see what existing form-building plugins do. We don't necessarily need (or want) to build a full date-format system, but perhaps looking at examples would give us a sense of what would be a useful subset of such a system.

#26 @boonebgorges
7 months ago

  • Milestone changed from 2.4 to Future Release

I like what's happening here, but it's not ready for prime time. At a minimum, we need to have the curated list of format options, as described above. The patches here are a good start, but need a champion to be core-worthy.

#27 @sooskriszta
3 months ago

So, preferred solution:
http://i.imgur.com/wAiFiKt.jpg
?

#28 @DJPaul
3 months ago

That looks decent.

#29 @boonebgorges
3 months ago

  • Keywords needs-patch added; has-patch needs-testing removed

Oh right, I forgot that WP had this built into options-general.php. That means (a) we don't have to invent a new interface, and (b) we can use their validation. Let's do it.

buddypress-15-07-24--10-25.zip needs a refresh (and ideally to be regenerated from the buddypress directory) before it can be properly tested.

#30 @DJPaul
2 months ago

  • Keywords good-first-bug added
  • Milestone changed from Future Release to 2.6

Would be got to get this in 2.6; not a bad ticket for a new contributor who knows their way around WordPress development and wants something snack-size.

#31 @sooskriszta
4 weeks ago

This is what the new patch does:
http://i.imgur.com/DdHSuFR.png

#32 @DJPaul
4 weeks ago

I uploaded a copy of that patch extracted from the ZIP

#33 @DJPaul
4 weeks ago

@abweb Thanks for your patch!

It does need a lot of tidy-up and adjustments for our code style; but any progress is great! Are you interested in iterating on your patch, if we let you know what needs to be changed?

@boonebgorges
4 weeks ago

#34 follow-up: @boonebgorges
4 weeks ago

  • Keywords good-first-bug removed

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 :)

#35 in reply to: ↑ 34 @sooskriszta
4 weeks ago

Replying to boonebgorges:

  • Idea: "Show time elapsed" ... there's no way to add future dates

I had imagined putting negative numbers for future dates, but I can see how this could be confusing to some BuddyPress admins

@abwebstudio
3 weeks ago

Updated patch

@abwebstudio
3 weeks ago

Screenshot of new UI

@abwebstudio
3 weeks ago

Screenshot of working field value examples

#36 @abwebstudio
3 weeks ago

I have uploaded new version of this patch.

  1. Fixed UI. Now it is more standard for WP.
  2. Added changes in range settings.
  3. It was fixed a bug when creating a field value. They just were not created. The problem was the method is_valid() absence and in the code at this place:"// Turn the concatenated value into a timestamp. "

Happy testing. I hope you will enjoy. Waiting for an answer

This ticket was mentioned in Slack in #buddypress by boone. View the logs.


2 weeks ago

#38 follow-up: @boonebgorges
2 weeks ago

Thanks very much, @abwebstudio. I think the UI is getting close to being very good. There are a few things I would change with the wording ("Custom" instead of "Arbitrarily"; add a link to date formatting rules, like WP has; "Range" instead of "Year Range"; etc) but I really like the general workflow here. Very powerful, and quite usable.

The internals of the patch still need lots of reworking, in accordance with some of the comments I made above about coding standards, data storage, and so forth. In addition to this, I'd like to consider a few more pieces before considering for merge:

  • It would be nice to have unit tests for some of the range stuff. We don't need extensive tests for PHP's date format functions, but the range stuff is custom, so I think it's worth testing.
  • In Edit mode, Month should only be shown when Month will show in the interface, etc.
  • Validation for custom date formats. WP does this using AJAX, in the form of a preview - it doesn't tell you when you've entered an "invalid" date format, since there's no real "invalid" - unrecognized characters are interpreted by date() as literals. I think we should copy what WP does here.

@abwebstudio If you're willing to continue working on these items, it'd get this ticket done faster. Otherwise I'm interested in shepherding it along myself, though it may not happen for this release if it's solely in my court.

Thanks for your continued work! Cool feature!

#39 in reply to: ↑ 38 ; follow-up: @sooskriszta
2 weeks ago

Replying to boonebgorges:

If the date_format selected doesn't include year (or month or day), we shouldn't include it in the front-end interface.

@boonebgorges I don't have a specific use-case in mind, and this may be inapplicable for this particular ticket, but I'd like to see in BuddyPress a decoupling of the input data and the output information.

#40 in reply to: ↑ 39 @boonebgorges
2 weeks ago

Replying to sooskriszta:

Replying to boonebgorges:

If the date_format selected doesn't include year (or month or day), we shouldn't include it in the front-end interface.

@boonebgorges I don't have a specific use-case in mind, and this may be inapplicable for this particular ticket, but I'd like to see in BuddyPress a decoupling of the input data and the output information.

I see this point, and I guess I don't feel strongly about my suggestion. My main thinking is that it's awkward to ask someone for, say, their birthday, knowing that you're not going to show the year on the front end, but requiring that the user provide it when editing the profile. I guess in some ideal world (though is this really ideal? seems like a potentially very confusing interface) the site admin would be able to say "collect the year, but don't display it", or "make the year optional" or "require the day and month, make the year optional, and only display the month and year" or whatever. Maybe, as a compromise, the validation should work like this: fields that are not going to be displayed on the front end should be de facto optional - that is, the validation routine will not throw an error if you don't include a Year, if the year is not part of the display format.

#41 @DJPaul
13 days ago

@abwebstudio I spend a few hours helping you get part of this patch more ready. Are you developing this change on Github (doesn't matter if you are not) and, more important, what would you like me to tackle? Hopefully more precise than "everything". ;)

Note: See TracTickets for help on using tickets.