* Remove 'Change password' and 'Delete account' tabs.
* Put 'Change password' under the Basic section.
* Put 'Deactivate account' under the Advanced section.
* Add help text to various settings.
DEPRECATION WARNING: Initialization autoloaded the constants
Danbooru::Paginator and Danbooru::Paginator::ActiveRecordExtension.
Being able to do this is deprecated. Autoloading during
initialization is going to be an error condition in future versions
of Rails.
Reloading does not reboot the application, and therefore code
executed during initialization does not run again. So, if you reload
Danbooru::Paginator, for example, the expected changes won't be
reflected in that stale Module object.
`config.autoloader` is set to `classic`. These autoloaded constants
would have been unloaded if `config.autoloader` had been set to
`:zeitwerk`.
Please, check the "Autoloading and Reloading Constants" guide for
solutions.
Fixes issue with newrelic failing to set up rake instrumentation:
ERROR : Error while detecting rake_instrumentation:
ERROR : NameError: uninitialized constant Rake::VERSION
DEPRECATION WARNING: Dangerous query method (method whose arguments
are used as raw SQL) called with non-attribute argument(s): "id =
52664 desc". Non-attribute arguments will be disallowed in Rails
6.1. This method should not be called with user-provided values,
such as request parameters or model attributes. Known-safe values
can be passed by wrapping them in Arel.sql().
Make /favorites redirect to a ordfav:<user> search instead of having a
separate view just for favorites. This duplicated a lot of code for no
good reason.
Comments have three states: visible, hidden, and invisible. Visible
comments are always shown. Hidden comments are not shown until the user
clicks 'Show all comments'. Invisible comments are never shown to the
user. Deleted comments are treated as hidden for moderators and
invisible for normal users. Thresholded comments are treated as hidden
for all users.
Rewrite the implementation of related tags to be simpler, faster, and
more accurate:
* The related tags are now calculated by taking a random sample of 1000
posts, finding the top 250 most frequent tags among those posts, then
ordering those tags by cosine similarity.
* Related tags can generally be calculated in 50-300ms at these sample
sizes. Very high sample sizes (25000+ posts) are still relatively fast
(1-3 seconds), but generally they don't improve accuracy much.
* Related tags are now cached in redis rather than in the tags table.
The related_tags column in the tags table is no longer used.
* Only the related tags in the search taglist are cached. The related
tags returned by the 'Related tags' button are not cached.
* The cache lifetime is a fixed 4 hours.
* The 'Related tags' button now works with metatags.
* The /related_tag page now works with metatags and multitag searches.
Fixes#4134, #4146.
* Drop support for `source:pixiv/artist-name` searches. This was a hack
that only worked on old pixiv urls that haven't been used for years.
* Replace the old SourcePattern(lower(source)) index with a trigram index.
Drop support for https://danbooru.donmai.us/cache/tags.json. This was a
nightly dump of the tags table that was originally added in #1012. It
was never documented and never really used except for by the DanbooruUp
extension.
This fixes InvalidAuthenticityToken errors caused by Reportbooru trying to
use this endpoint to update related tags. Reportbooru uses a secret key
to authenticate rather than using apikey-based authentication, which
makes it fail the CSRF protection.
Bug: if all the comments on a post were deleted then the deleted
comments wouldn't be visible to moderators.
This was because we assumed that if `last_commented_at` was nil it meant
that the post had no comments, but this was wrong. `last_commented_at`
only counts undeleted comments. It's reset to nil if all the commnets
have been deleted.
Previously if a pool had >100 posts then the 'Order' link wouldn't
appear in the navbar, but it was still possible to visit the pool order
page directly. If a user did so, only the first 100 posts in the pool
would be shown in the drag-and-drop widget. If they tried to reorder the
pool anyway, then everything beyond the first 100 posts would be
silently removed from the pool.
Now we always show the 'Order' link, but we disable the drag-and-drop
reordering widget when the pool has >100 posts to prevent posts from
being silently removed.
