WordPress.org

Make WordPress Core

Opened 13 months ago

Last modified 5 months ago

#44267 new enhancement

Privacy Request List Table: A way to show the time of request when it's older than 24 hours.

Reported by: birgire Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 4.9.6
Component: Privacy Keywords: has-patch needs-testing needs-refresh
Focuses: accessibility, administration Cc:

Description

When the request is older than 24 hours, then we can't see time of the request. An example:

May 18, 2018

The related methods are:

  • WP_Privacy_Requests_Table::get_timestamp_as_date().
  • WP_Privacy_Requests_Table::column_default().

For comparison, here's an example from the posts list table in list view:

<abbr title="2018/05/14 8:41:52 am">2018/05/14</abbr>

and in the excerpt view:

Published
<br/>
2018/05/14 8:41:52 am

Here's an example from the comments list table:

2018/04/20 at 5:35 pm

I'm not sure the <abbr> is suitable here, after reading:

https://stackoverflow.com/a/32892825/2078474

Attachments (10)

datetime-v1.jpg (38.8 KB) - added by birgire 11 months ago.
datetime-v2.jpg (38.3 KB) - added by birgire 11 months ago.
datetime-v3.jpg (36.5 KB) - added by birgire 11 months ago.
datetime-v4.jpg (39.7 KB) - added by birgire 11 months ago.
current.jpg (35.7 KB) - added by birgire 11 months ago.
datetime-v5.jpg (37.6 KB) - added by birgire 10 months ago.
44267.diff (1.3 KB) - added by birgire 10 months ago.
44267-2.diff (1.5 KB) - added by birgire 9 months ago.
datetime-v6-mobile.jpg (30.4 KB) - added by birgire 9 months ago.
datetime-v6.jpg (29.4 KB) - added by birgire 9 months ago.

Download all attachments as: .zip

Change History (38)

#1 @desrosj
12 months ago

  • Focuses accessibility added
  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to 4.9.8

@afercia can you confirm the correct way to display this for a11y? A new ticket will most likely be required if the other occurrences need changing to be consistent (which I am more than happy to open), but would like to confirm that approach for this ticket first.

@birgire is your goal to always see the time for privacy requests? If so, the comments approach seems best.

#2 @birgire
12 months ago

@desrosj, I don't mind if it's always displayed or not, just that we have a way for the user to find the exact time, but I think we should consider the way that's better for accessibility. Yes, the comments' way looks good.

This ticket was mentioned in Slack in #core by joshuawold. View the logs.


11 months ago

#4 @afercia
11 months ago

@desrosj hi, as a general rule if the information is important enough and relevant for all users, then it should be displayed in plain text. Using a title attribute is just a good way to hide the information from some users.

In the last couple years, there's been an ongoing effort to remove title attributes from core. We've made a very few exceptions, and the posts list table is one of them. It was discussed in #35313 and #35391 and decided to keep the <abbr> with its title as is. In that case it was an acceptable trade-off, also considering the limited space (we couldn't find a better solution too).

In this case, I'd say the requests table has enough room to display the full date + time. I see it's now based on the date_format user setting. That means changing the setting under "General Settings" in the admin to something like F j, Y g:i A would make the time appear. However, that would change all the dates displayed in the admin.

I'm not a lawyer :) but since this is something related to legal stuff, always displaying the full date + time could be beneficial. I'd consider to not use a formatting based on date_format and always show date + time.

@birgire
11 months ago

@birgire
11 months ago

@birgire
11 months ago

@birgire
11 months ago

#5 @birgire
11 months ago

@afercia thanks for looking into it.

The status column can also contain a date.

Here are some various versions, that display the time as well:

  • current.jpg - Shows the current version with date_i18n( get_option( 'date_format' ), $timestamp );
  • datetime-v2.jpg - Shows the 'Y/m/d g:i:s a' format and the Completed datetime in a new line without parentheses.
  • datetime-v3.jpg - Shows the 'Y/m/d' at 'g:i a' format and the Completed datetime in a new line without parentheses.

@birgire
11 months ago

#6 @desrosj
11 months ago

  • Milestone changed from 4.9.8 to 4.9.9

4.9.8 RC is out. Punting to 4.9.9.

#7 @desrosj
11 months ago

@birgire I like version 3 best.

This ticket was mentioned in Slack in #core-privacy by desrosj. View the logs.


10 months ago

@birgire
10 months ago

@birgire
10 months ago

#9 @birgire
10 months ago

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

datetime-v5.jpg is similar to v3, but it:

  • uses @ in a similar way as in the dateformat within the Publish metabox and for revisions.
  • doesn't use bold on the status date.

44267.diff is an example implementation for that version.

#10 @afercia
9 months ago

Not sure using @ adds any value. Instead, I doubt it's announced correctly from assistive technologies in other languages. In Italian, for example, the @ symbol is called chiocciola and its main meaning is "snail" :) Or it's a particular type of stairs.

Firefox and NVDA do read out @ as "chiocciola". This makes sense only in the context of email addresses, where we usually say "xyx chiocciola xyz.com". However, "chiocciola" doesn't make any sense in the context of a date format. I guess this happens also in many other languages.

I guess only in English there's an association between the @ symbol and the word at. I'd tend to think @ doesn't have an universal meaning in the context of dates and it shouldn't be used this way. I'd rather just use the word at like, for example, in the Comments screen.

We should also try to remove @ in all the places in WordPress where it's used for dates, but I guess it should be addressed in a separate ticket.

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


9 months ago

#12 @birgire
9 months ago

@afercia Thanks for the review and the "snail" info ;-)

I just assumed the Publish metabox was battle-tested and safe as a reference :-)

I will look into updating the patch with a translatable at instead of @.

#13 @afercia
9 months ago

@birgire thanks :)

I just assumed the Publish metabox was battle-tested and safe as a reference

I wish it was. There are just so many things to do :)

@birgire
9 months ago

#14 @birgire
9 months ago

I found a list here for the meaning of the @ symbol in various countries, often related to food or animals :-)

44267-2.diff is a suggestion (similar to the comments lists table) for using the at word and skipping the zoo :-)

See attached screenshots for datetime-v6.jpg and datetime-v6-mobile.jpg.

Last edited 9 months ago by birgire (previous) (diff)

@birgire
9 months ago

#15 @xkon
8 months ago

@desrosj / @birgire If we consider what @afercia mentioned on not using the Settings for a date format I wouldn't personally go for a full digit display. Different locales could be used on having different formats and that might be confusing if it's "hardcoded" for example 2018/08/08 to some could mean 2018 August 08, and to others 2018 08 August, so I'd personally go for the month in either M or F for a display instead of a digit. Does that make sense at all?

Last edited 8 months ago by xkon (previous) (diff)

#16 @pento
8 months ago

  • Milestone changed from 4.9.9 to Future Release

This ticket was mentioned in Slack in #core-privacy by webdevlaw. View the logs.


8 months ago

#18 @birgire
8 months ago

@xkon thanks for your comment, that makes sense, but these are now translatable.

I think there could be a little guessing game for the user to find out what e.g. 2018/08/09 means; August 9th or September 8th ;-)

The latest patch was based on the comments list table, but there are so many date string versions in core :-) We can e.g. see some date variations on the Dashboard too.

Here are some variations:

Aug 20, 2018 at 16:31
Aug 20th, 2018 at 16:31
August 20, 2018 at 16:31
August 20th, 2018 at 16:31

and without at:

Aug 20, 2018 16:31
Aug 20th, 2018 16:31
August 20, 2018 16:31
August 20th, 2018 16:31

that we might consider.

This ticket was mentioned in Slack in #core-privacy by birgire. View the logs.


8 months ago

#20 follow-up: @TZ Media
8 months ago

Couldn't we just use whatever format was set under Settings -> General?

get_option('date_format');
get_option('time_format');

#21 in reply to: ↑ 20 @birgire
8 months ago

Replying to TZ Media:

Couldn't we just use whatever format was set under Settings -> General?

get_option('date_format');
get_option('time_format');

@afercia had concerns about that here:

https://core.trac.wordpress.org/ticket/44267#comment:4

I see it's now based on the date_format user setting. That means changing the setting under "General >Settings" in the admin to something like F j, Y g:i A would make the time appear. However, that would change all the dates displayed in the admin.

What do you think? Should the user be able to change the request date format that way? As far as I remember, that's not the case for the other list tables.

Version 3, edited 8 months ago by birgire (previous) (next) (diff)

#22 follow-up: @TZ Media
8 months ago

Missed that before. As there are no consistent date/time formats in wp-admin even in core, not to speak of plugins and themes, this asks for a way to have more consistency through either a setting, or some other means to provide a standard format. But this is not part of this ticket.

As I'm no native speaker in English, I'm probably not the best person to suggest the best format to use. That being said, I'd go for "Aug 20, 2018 16:31" or "August 20, 2018 16:31" just for the sake of simplicity.

#23 in reply to: ↑ 22 @birgire
8 months ago

Replying to TZ Media:

Missed that before. As there are no consistent date/time formats in wp-admin even in core, not to speak of plugins and themes, this asks for a way to have more consistency through either a setting, or some other means to provide a standard format. But this is not part of this ticket.

As I'm no native speaker in English, I'm probably not the best person to suggest the best format to use. That being said, I'd go for "Aug 20, 2018 16:31" or "August 20, 2018 16:31" just for the sake of simplicity.

Thanks for your suggestions, adding the at makes it a little more involved, but I wonder if it's better for the screen readers?

The "August 20, 2018 16:31" would be similar to the current date format with the time format appended.

The "Aug 20, 2018 16:31" is e.g. similar to the date format (excluding the weekday) of the *WordPress Events News* dashboard widget.

#24 @garrett-eclipse
8 months ago

Hi @birgire reviewing core implementations I'd suggest adopting the format found in the Comments table;
https://github.com/WordPress/WordPress/blob/4.9.8/wp-admin/includes/class-wp-comments-list-table.php#L717-L740

This provides the default en_US standard for date time and makes it translatable as well as places the word 'at' between date and time.

With the use of word based month instead of numeric you'll end with varying lengths which can affect the table widths.

In the other list tables for posts, etc they provide a slightly different format for the time portion but all dates are the same 'Y/m/d';
https://github.com/WordPress/WordPress/blob/4.9.8/wp-admin/includes/class-wp-media-list-table.php#L432-L457
https://github.com/WordPress/WordPress/blob/4.9.8/wp-admin/includes/class-wp-ms-sites-list-table.php#L340-L384
https://github.com/WordPress/WordPress/blob/4.9.8/wp-admin/includes/class-wp-ms-users-list-table.php#L278-L295
https://github.com/WordPress/WordPress/blob/4.9.8/wp-admin/includes/class-wp-posts-list-table.php#L962-L1040
*In most of the above the datetime is formatted as 'Y/m/d g:i:s a'

Although there's more conventions as 'Y/m/d g:i:s a' rather than 'Y/m/d at g:i a' I would drop the seconds and follow the convention presented in comments list table as comments similar to requests are seen as more user submitted rather than admin created so following that over the posts datetime convention would make more sense.

#25 @garrett-eclipse
8 months ago

Aside from following the comments convention, it might be useful to provide a filter similar to post_date_column_time.
https://github.com/WordPress/WordPress/blob/4.9.8/wp-admin/includes/class-wp-posts-list-table.php#L1019-L1039

#26 @birgire
8 months ago

Thanks @garrett-eclipse

So it looks like you favor the version 3 in the list here:

https://core.trac.wordpress.org/ticket/44267#comment:5

that would look like this: datetime-v3.jpg.

It's a good argument regarding the "fixed" column width and the Y/m/d similarity to other list tables. Thinking of it, it's also nice to read when it's date ordered, skimming through the year changes first, then the month changes and finally day changes.

But for other column orderings and if the user doesn't know the exact date-time format, then the suggested formats by @xkon and @TZ Media sounds more readable.

If the g:i a is the en_US time standard then it makes sense to use that.

(personally though, I find it much easier to read the H:i time format instead of the g:i a)

I like your filter idea, as we can see in this thread, there are many different preferred ways regarding the date-time format :-)

#27 @garrett-eclipse
8 months ago

Thanks @birgire, that is the format I was indicating.

Following an existing format be it the one indicated or another will remove the need to translate a new format in core.

A concise format will help on smaller screens and when additional columns are added via plugins. With months being varying lengths they will often cause the column contents to wrap at different points making it hard to follow/scan the dates.

#28 @garrett-eclipse
5 months ago

  • Keywords needs-refresh added
  • Version set to 4.9.6
Note: See TracTickets for help on using tickets.