* Remove the single alias and implication request forms. From now
on, bulk update requests are the only way to request aliases or
implications.
* Remove the forum topic ID field from the bulk update request form.
Instead, to attach a BUR to an existing topic you go to the topic then
you click "Request alias/implication" at the top of the page.
* Update the bulk update request form to give better examples for the
script format and to explain the difference between aliases and
implications.
* Pick the largest character or copyright tags by post count. Previously
we picked the tags with the longest names, which was nonsensical.
* Remove tag cateogory logic from config file. We can't avoid hardcoding
some knowledge about tag categories here, so there's no point in trying.
This affects tab titles on post show pages as well as filenames in
downloaded images.
https://danbooru.donmai.us/forum_topics/9127?page=283#forum_post_160508
There was a recent outage that was caused by the read replica
(yukinoshita.donmai.us) being temporarily unavailable. The pg driver in
rails got hardstuck trying to connect to the replica, which brought down
the whole site. The app servers stopped responding and could only be
brought down with SIGKILL. Even try to boot the rails console didn't
work.
We only really used this to calculate tag counts inside Post.fast_count,
which wasn't really beneficial since the read replica is slower than the
main database.
Previously the search form on the /iqdb_queries page submitted directly
to the iqdb service (karasuma.donmai.us), which redirected back to
Danbooru with the search results.
This was different than API requests, which submitted to
/iqdb_queries.json which proxied the call to iqdb through Danbooru.
Because of this, searches on the /iqdb_queries page had different
behavior than API requests. Things like filesize limits and referrer
spoofing were handled differently.
Now searches on the /iqdb_queries page submit directly to Danbooru. This
is simpler and it means that API requests and HTML requests have the
same behavior.
Disable the assets pipeline (Sprockets). Sprockets errors out now after
upgrading to Sprockets 4 because of missing config files. We don't use
it any more after switching to Webpack, so we can disable it entirely.
Also disable a few more Rails features that we don't use (ActiveStorage,
ActionCable, ActionMailbox, ActionText).
Previously the page-based (numbered) paginator would always count the
total_pages, even in API calls when it wasn't needed. This could be very
slow in some cases. Refactor so that total_pages isn't calculated unless
it's called.
While we're at it, refactor to condense all the sequential vs. numbered
pagination logic into one module. This incidentally fixes a couple more
bugs:
* "page=b0" returned all pages rather than nothing.
* Bad parameters like "page=blaha123" and "page=a123blah" were accepted.
Remove all infrastructure around approving or rejecting user name
changes. Name changes haven't been moderated for several years.
* Remove status, approver_id, change_reason, and rejection_reason fields.
* Remove approve and reject controller actions.
* Automatically fix all tags with incorrect counts during daily
maintenance (previously only tags with negative counts were fixed).
* Log fixed tags to NewRelic.
* Remove the ability to manually fix tag counts with the "Fix" button on
the /tags listing. This is no longer necessary now that tags are
fixed automatically.
Use git clean to delete stale files from an earlier checkout. These
files interfered with various things (specifically, a comment vote test
failed because there was an old comment_votes/create.json.erb template
hanging around that changed the behavior of the POST /comment_votes endpoint).
Stop maintaining pool category pseudo tags (pool:series, pool:collection)
in pool strings. They're no longer used and the changes to the
`Post#pools` method in dc4d2e54b caused issues with this.
Also allow Members to change the category of large pools again. This was
only restricted because maintaining these pseudotags forced us to update
every post in the pool whenever a pool's category was changed.
Replace the `method_attributes` and `hidden_attributes` methods with
`api_attributes`. `api_attributes` can be used as a class macro:
# include only the given attributes.
api_attributes :id, :created_at, :creator_name, ...
# include all default attributes plus the `creator_name` method.
api_attributes including: [:creator_name]
or as an instance method:
def api_attributes
[:id, :created_at, :creator_name, ...]
end
By default, all attributes are included except for IP addresses and
tsvector columns.
In xml responses, if the result is an empty array we want the response
to look like this:
<posts type="array"/>
not like this (the default):
<nil-classes type="array"/>
This refactors controllers so that this is done automatically instead of
having to manually call `@things.to_xml(root: "things")` everywhere. We
do this by overriding the behavior of `respond_with` in `ApplicationResponder`
to set the `root` option by default in xml responses.
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.
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.
Bug: capistrano didn't update the crontab during deployment. As a result
the crontab still referenced an old deployment. Eventually that
deployment was deleted and cronjobs started silently failing.
Broken in 223e5f1e8. Turns out that `whenever` defaults to running on
servers with the `db` role. Removing kagamihara from the db role meant
that whenever was no longer configured to run anywhere.
Fixes an issue with zero downtime deployments (#4123). Hot restarting
didn't clear out BUNDLER_GEMFILE, which mean that new workers still used
the old Gemfile from previous deployments. This led to mysterious errors
with autoloading libraries (#4138).
Upgrade procedure:
$ echo 2.6.3 > .ruby-version
# upgrade ruby-build to know about the latest ruby versions.
# see also: github.com/rkh/rbenv-update
$ cd ~/.rbenv/plugins/ruby-build && git pull
# install the version of ruby specified in .ruby-version.
# see also: github.com/capistrano/rbenv/issues/83
$ rbenv install --skip-existing
# update the shell to use the latest version of ruby by default.
$ rbenv global 2.6.3
# update rubygems and bundler
$ gem update --system
# update the lockfile to use the latest version of bundler
$ bundle update --bundler
