This adds two config items: useAbsoluteTimeFormat (boolean) and
absoluteTimeFormatMinAge (string, number + unit ('d'|'h'|'m'|'s')).
When `useAbsoluteTimeFormat` is true, the Timeago component will display
absolute time if the time is at least `absoluteTimeFormatMinAge`
from now. If `longFormat` prop is true, the fully formatted time
is displayed. Otherwise, the format is determined by the `time` prop:
(1) if `time` is on the same day of now, display hour and minute;
(2) if `time` is in the same month of now, display day and hour;
(3) if `time` is in the same year of now, display month and day;
(4) otherwise, display year and month.
If it should display relative time, the format is the same as before.
This adds two config items: useAbsoluteTimeFormat (boolean) and
absoluteTimeFormatMinAgeDays (number).
When `useAbsoluteTimeFormat` is true, the Timeago component will display
absolute time if the time is at least `absoluteTimeFormatMinAgeDays`
days from now. If `longFormat` prop is true, the fully formatted time
is displayed. Otherwise, the format is determined by the `time` prop:
(1) if `time` is on the same day of now, display hour and minute;
(2) if `time` is in the same month of now, display day and hour;
(3) if `time` is in the same year of now, display month and day;
(4) otherwise, display year and month.
If it should display relative time, the format is the same as before.
Every time PleromaFE is used to login it will need to do the OAuth dance and request an app key. If the client name is not stable it will pollute the server's database with entries.
This also happens on every unauthenticated page load at the moment until #1339 is resolved
The Pleroma backend now reports an error when trying to reply to a status it cannot resolve we assume it is deleted or nonexistent. PleromaFE was in_reply_to_id: true as an internal method to trigger populating the post status form with the username of the profile being viewed and this was being submitted to the API as a result.
