It's common to have a view that displays the time of an action in "Time ago" format. However, if the view is cached, we can't use a static "time ago" value.

Instead, it would be great to have Timeago Views integration so that we can print a static timestamp in cached view output and update it with the Timeago library.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

IceCreamYou’s picture

Version: 6.x-2.x-dev » 7.x-2.x-dev
Status: Active » Closed (duplicate)

This patch would solve this problem by simply allowing all formatted dates on the site to use Timeago. It's for D7 but backporting should be easy enough. I'd rather do it that way than manually support / override every possible place where any module could display a date.

ezra-g’s picture

Title: Views integration for cached Views » Provide a dedicated date type
Status: Closed (duplicate) » Needs review
FileSize
1.04 KB

Re-titling the issue to be more specific.

Use case: There's currently no way with Timeago module to use timeago for formatting an activity stream (or any other place date types are used such as Views fields) while preserving Drupal's default short, medium and long date types for use in other places (eg, article published on $date) because Timeago module's optional approach is to override one of those date types.

Instead, it's trivial to define a new "Timeago (dynamically updating)" date type as in this patch. That way we could selectively use this date type wherever we need it while preserving the other Drupal core date types.

IceCreamYou’s picture

Status: Needs review » Needs work

Hmm. I like this in principle. In practice I have a few concerns. (First of all, trailing whitespace...)

  1. Admins shouldn't be able to set non-Timeago formats for the Timeago date type.
  2. This patch as written will cause the Timeago JavaScript to be added to the page even when it's not needed by breaking timeago_init().
  3. Having a new date format that is exclusively used as an option in Views but is not explained as such in the interface is confusing, especially since you can use the Timeago date formats for the other date types. It's also useless for sites without Views installed.

The first and third concern can probably be worked-around with some awkward form-altering, but maybe there is a more targeted solution (e.g. directly altering/overriding the Views date selection) that would be easier and clearer.

There's currently no way with Timeago module to use timeago for formatting an activity stream (or any other place date types are used such as Views fields) while preserving Drupal's default short, medium and long date types for use in other places (eg, article published on $date) because Timeago module's optional approach is to override one of those date types.

Well, Timeago does provide node and comment tokens for activity stream modules that build messages that way. In Views, a workaround is to use the Timeago markup directly, e.g. by using Views' ability to rewrite field output, although you may need to call timeago_add_js() manually and it's admittedly not especially easy to get a properly-formatted ISO-8601 timestamp using tokens or Views handlers. Or you could do preprocessing in PHP. But yeah, there is room for improvement.

ezra-g’s picture

Admins shouldn't be able to set non-Timeago formats for the Timeago date type.

We set a default for this when the module is installed. Given that site admins might wish to change to any of the other Time Ago predefined formats, I don't think we should disable the control. This is consistent with other Drupal config in general: if someone has sufficient privileges to administer site-wide date formats and types, we trust them to make configurations that make sense.

Having a new date format that is exclusively used as an option in Views but is not explained as such in the interface is confusing

This is not exclusive to Views. By implementing it as as side-wide date format, it can be used anywhere we display dates. Views just happens to be my use case (and it seems like a fairly common one ;).

This patch as written will cause the Timeago JavaScript to be added to the page even when it's not needed by breaking timeago_init().

The behavior of adding the Timeago javascript to the page in cases when it's not in use (whenever a Timeago date type exists on the site) is already in place in Timeago.module without this patch. The proposed patch doesn't change that behavior.

However, we could make this behavior a configurable option such as "Add TimeAgo JavaScript to the page automatically" that would add to the existing conditional in timeago_init() a check on that configuration setting.

Does that seem like an acceptable approach? I so, I'll re-roll accordingly.

IceCreamYou’s picture

I don't think we should disable the control. This is consistent with other Drupal config in general: if someone has sufficient privileges to administer site-wide date formats and types, we trust them to make configurations that make sense.

Of course we shouldn't disable it, but we shouldn't let people set it to something that makes no sense (i.e. any non-Timeago format). I agree that generally developers don't need to be protected from themselves, but there is no reason to expose something in the UI to admins that makes no sense.

This is not exclusive to Views. By implementing it as as side-wide date format, it can be used anywhere we display dates.

That's not the point. The point is it's confusing to have a date type labeled "Timeago" when any of the other date types can also use (different) Timeago formats. And it's especially confusing to have a Timeago format if it's not used anywhere on your site, which will be the case for the vast majority of websites using Timeago. Explanatory text is probably a good enough solution here.

The behavior of adding the Timeago javascript to the page in cases when it's not in use (whenever a Timeago date type exists on the site) is already in place in Timeago.module without this patch. The proposed patch doesn't change that behavior.

However, we could make this behavior a configurable option such as "Add TimeAgo JavaScript to the page automatically" that would add to the existing conditional in timeago_init() a check on that configuration setting.

What I meant is that if a new Timeago date type is added that always uses a Timeago format, then we have to add the Timeago JS to every page no matter what, even if Timeago is never used anywhere (or more likely, only used on node pages, which is an option provided in the settings) -- so the conditional code in timeago_init() is redundant. I think I'm okay with just loading the Timeago JS on every page, but it would be nice to have an on-by-default setting to "Always add Timeago JavaScript to every page" so people could disable it if they wanted more control.

japerry’s picture

Issue summary: View changes
FileSize
1.21 KB

Re-roll for the latest version of timeago. Keeping needs work per comment #5