Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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.
Comment | File | Size | Author |
---|---|---|---|
#6 | 1427226-timeago-date-type-6.patch | 1.21 KB | japerry |
#2 | 1427226-timeago-date-type.patch | 1.04 KB | ezra-g |
Comments
Comment #1
IceCreamYou CreditAttribution: IceCreamYou commentedThis 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.
Comment #2
ezra-g CreditAttribution: ezra-g commentedRe-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.
Comment #3
IceCreamYou CreditAttribution: IceCreamYou commentedHmm. I like this in principle. In practice I have a few concerns. (First of all, trailing whitespace...)
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.
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.
Comment #4
ezra-g CreditAttribution: ezra-g commentedWe 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.
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 ;).
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.
Comment #5
IceCreamYou CreditAttribution: IceCreamYou commentedOf 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.
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.
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.
Comment #6
japerryRe-roll for the latest version of timeago. Keeping needs work per comment #5