* Fix#2922 - Load stylesheet from "custom.css" entrypoint when present
This is pretty much the same way it worked as before, albeit with
having to create app/javascript/packs/custom.js with
require('../styles/custom.scss') (or whatever you want really), which
will be a blank slate for you to import whatever you want
* Remove old assets directory
* Extract font-awesome into common.css and always load it
* Update nl strings for 1.4
* Update nl strings for 1.4
* Update nl strings for 1.4
* nl strings (+1)
More new OTP strings will be translated another time
* Update nl strings for 1.4
* Update nl strings for 1.4
* Update nl strings for 1.4
* nl strings (+1)
More new OTP strings will be translated another time
* Fix nil input not handled well in AuthorExtractor concern
* Fix hard error in ProcessFeedService when replied-to status has been deleted
* Fix nil errors in ProcessInteractionService when favourited status
cannot be found
* Fix nil input not handled well in AuthorExtractor concern
* Fix hard error in ProcessFeedService when replied-to status has been deleted
* Fix nil errors in ProcessInteractionService when favourited status
cannot be found
because it may causes flicker on the conversation when it contains blocked/muted user's status.
We use `/api/v1/statuses/{id}/context` to obtain status ids in the
conversation which filters blocked/muted user, but also uses internal
cache constructed from `in_reply_to_id` by `normalizeStatus()` in
`reducers/timelines.js` on each status loading which doesn't filter.
So statuses appears in conversation if those are cached, even those
statuses are from blocked/muted user. Then context cache will be updated
with the result of the context API and those statuses will be removed.
I have left the `normalizeStatus()` function itself which is called many
functions in the file as a placeholder for now, but maybe it should be
removed completely.
because it may causes flicker on the conversation when it contains blocked/muted user's status.
We use `/api/v1/statuses/{id}/context` to obtain status ids in the
conversation which filters blocked/muted user, but also uses internal
cache constructed from `in_reply_to_id` by `normalizeStatus()` in
`reducers/timelines.js` on each status loading which doesn't filter.
So statuses appears in conversation if those are cached, even those
statuses are from blocked/muted user. Then context cache will be updated
with the result of the context API and those statuses will be removed.
I have left the `normalizeStatus()` function itself which is called many
functions in the file as a placeholder for now, but maybe it should be
removed completely.
In single user mode, visitors are redirected to the single user's
profile page. So, if you are the owner without a session, you start
from that page, click the login button and authenticate yourself
expecting you'll soon get started with the home page, but in reality
you'll get redirected back to where you started from -- your own
profile page.
This fixes the behavior by redirecting you home after login if you
have started from your own profile page.
In single user mode, visitors are redirected to the single user's
profile page. So, if you are the owner without a session, you start
from that page, click the login button and authenticate yourself
expecting you'll soon get started with the home page, but in reality
you'll get redirected back to where you started from -- your own
profile page.
This fixes the behavior by redirecting you home after login if you
have started from your own profile page.
I've found this issue when I clicked replies to muted user on the timeline.
Properties I've removed in here were added with lazy loading using
IntersectionObserver (5efcea69), but those statuses are not need to be
tracked anyway because it will be rendered as only empty div.
I've found this issue when I clicked replies to muted user on the timeline.
Properties I've removed in here were added with lazy loading using
IntersectionObserver (8e4d1cba), but those statuses are not need to be
tracked anyway because it will be rendered as only empty div.
There are many spots throughout the codebase which are showing as covered by
specs in the simplecov output -- but which are not actually run, because they
are on the same line as a guard clause.
I plan on fixing some of these issues, but don't want to keep triggering this
rubocop style violation.
My preference would be that we use the PR review process to identify places
where a guard clause might be appropriate, but that we leave this cop turned off
by default.
There are many spots throughout the codebase which are showing as covered by
specs in the simplecov output -- but which are not actually run, because they
are on the same line as a guard clause.
I plan on fixing some of these issues, but don't want to keep triggering this
rubocop style violation.
My preference would be that we use the PR review process to identify places
where a guard clause might be appropriate, but that we leave this cop turned off
by default.
