Make related tags use a single-column layout on mobile.
Related tags layout is still broken inside the tag edit dialog box, when
the dialog box is too small for multiple columns.
* Use -webkit-text-stroke instead of bold to indicate selected tags.
Bold causes the tag to change width, which is jarring and can cause
the tag to wrap around to a new line. -webkit-text-stroke doesn't
change the tag's width. Despite the name, this property is widely
supported.
* Don't wrap the checkbox in a label. In combination with flexbox, this
made the hitbox for the tag too big. You could click on empty space
outside the tag and it would still toggle the tag.
Instead of changing the background color of the entire page when you
change modes in the post mode menu (which was ugly, and not obvious what
the colors meant), show a notice and make it so that hovering a post
gives it a blue outline. This indicates that clicking the post will do
something different.
Fix issues with note sizing caused by the switch to `box-sizing: border-box`
in 19aea560. Note boxes have a 1px black border, which is counted as
part of the note box width when using border-box. This threw off sizing
and position calculations.
Also go back to 1px borders instead of 2px borders for unsaved and
selected notes. This also messed up note sizing.
* Standardize dialog box and tooltip box shadows.
* Add shadows behind all other floating elements, namely the
autocomplete menu and translation notes (except for embedded notes,
which are usually meant to be seamless).
Remove some rules intended to highlight the currently selected tag in
the autocomplete menu. The selected tag was supposed to be shown with
the tag hover color, but this didn't actually work because of CSS
specificity issues, and it possibly never worked to begin with, so it's
not worth fixing.
Partial revert of b9ea9d2f5. Go back to using a semi-transparent
background to indicate the selected parent/child post, but add more
padding and adjust the transparency to make it more legible.
In the related tags list, use checkboxes and bold to indicate selected
tags, instead of highlighting selected tags with a blue background.
This is so that you can see the colors of selected tags in the related
tags list, and in particular so you can see the artist tag.
Change the new, approved, pending, and rejected labels in the forum to
use an outlined pill style (like user levels in user tooltips) instead
of a filled background style. This is less obtrusive and more readable
in dark mode.
Remove the follow properties:
* clear (wasn't used)
* list-style-* (wasn't used)
* outline (only used a few times; can be achieved with borders or
box-shadow).
* mask (not well-supported in browsers; only used a few times for
effects that could be achieved in other ways).
* text-decoration-* (use the shorthand property)
* text-transform (can be achieved in other ways)
* Fix it so that all edit forms show an error banner if the form
has validation errors. Previously forms had to manually call
`error_messages_for`, which not all forms did.
* Fix it so that the full validation error message is shown next to each
input attribute that had errors. Also update the styling of these
error messages to look better.
* On the post show page, in the parent/child box, change it so that
currently selected post is more visible. Use a light blue outline
around the current post instead of a dark semi-transparent border.
* Fix it so that there's less empty space around thumbnails in the
parent/child box.
Add a new color palette and rework all site colors (both light mode and dark mode) to
use the new palette.
This ensures that colors are used consistently, from a carefully designed color palette,
instead of being chosen at random.
Before, colors in light mode were chosen on an ad-hoc basis, which resulted in a lot of
random colors and inconsistent design.
The new palette has 7 hues: red, orange, yellow, green, blue, azure (a lighter blue), and
purple. There's also a greyscale. Each hue has 10 shades of brightness, which (including
grey) gives us 80 total colors.
Colors are named like this:
var(--red-0); /* very light red */
var(--red-2); /* light red */
var(--red-5); /* medium red */
var(--red-7); /* dark red */
var(--red-9); /* very dark red */
var(--green-7); /* dark green */
var(--blue-5); /* medium blue */
var(--purple-3); /* light purple */
/* etc */
The color palette is designed to meet the following criteria:
* To have close equivalents to the main colors used in the old color scheme,
especially tag colors, so that changes to major colors are minimized.
* To produce a set of colors that can be used as as main text colors, as background
colors, and as accent colors, both in light mode and dark mode.
* To ensure that colors at the same brightness level have the same perceived brightness.
Green-4, blue-4, red-4, purple-4, etc should all have the same brightness and contrast
ratios. This way colors look balanced. This is actually a difficult problem, because human
color perception is non-linear, so you can't just scale brightness values linearly.
There's a color palette test page at https://danbooru.donmai/static/colors
Notable changes to colors in light mode:
* Username colors are the same as tag colors.
* Copyright tags are a deeper purple.
* Builders are a deeper purple (fixes#4626).
* Moderators are green.
* Gold users are orange.
* Parent borders are a darker green.
* Child borders are a darker orange.
* Unsaved notes have a thicker red border.
* Selected notes have a thicker blue (not green) border.
* Render counts in the user profile tooltip the same way as tag counts.
* Render tag counts in the tags index page the same way as tag counts in
the tags list.
Bug: In Postgres 13, getting the count of a blank search underestimated
the page count by a large margin (~700,000 posts).
The query we were executing was this:
EXPLAIN (FORMAT JSON) SELECT * FROM posts ORDER BY id DESC
The `ORDER BY id DESC` clause triggered a parallel seq scan query plan
in Postgres 13, which for some reason causes Postgres to underestimate
the row count by large amount in each parallel branch.
Getting rid of the ORDER BY clause makes it do a regular seq scan, which
gives an accurate estimate.
* Refactor the paginator into a ViewComponent.
* Fix inconsistent spacing between paginator items.
* Fix a bug where the sequential paginator generated the wrong next /
previous page links in the <link rel="{next|prev}"> tags in the <head>.
* Always include the final page as a hidden html element, so that it can
be unhidden with custom CSS.
* Make it easier to change the pagination window.
This makes it so that an element's width includes borders and padding,
so that borders or padding don't cause an element to exceed its
specified width. This is a standard part of most CSS resets.
https://developer.mozilla.org/en-US/docs/Web/CSS/box-sizing
Increase the font weight from 200 to 400 for the IBM Plex Mono font used
in notes. 400 is the standard weight we use for other fonts. 200 made
the font too thin and hard to read at normal font sizes.
Adjust input boxes to fit the screen better on mobile, and to use
consistent sizes throughout the site (no ad-hoc overrides to make
certain input boxes a bit bigger in random places).
On desktop, this makes most input boxes a bit taller and narrower. On
mobile, it makes input boxes the full width of the screen.
This most notably affects the tag edit box, the comment and forum
post box, the wiki page edit box, and the commentary box.
Refactor CSS to use standard Tailwind-style utility classes instead of
ad-hoc rules. This eliminates a lot of single-purpose rules for specific
UI elements and standardizes margins to be more consistent throughout
the site.
Utility classes are defined manually on an as-needed basis instead of
importing Tailwind as a whole. Naming conventions mostly follow
Tailwind's conventions, otherwise they follow Bootstrap.
* https://tailwindcss.com/docs/
* https://getbootstrap.com/docs/5.0/utilities/spacing/
Replace the Google map on the IP address show page with a Bing map. Bing
doesn't require an API key, which makes it easier to deploy. The Google
Maps API requires to you to whitelist the IP addresses and domains you
plan to use with your API key, which is inconvenient for development
because it means maps won't display unless you whitelist your
development IPs.
Remove the api_token field from the response to the login action (POST
/sessions). This doesn't make sense in the presence of multiple API
keys, and is also not generally useful; if you need an API key, create
one yourself and write it down.
Require the user to re-enter their password before they can view,
create, update, or delete their API keys.
This works by tracking the timestamp of the user's last password
re-entry in a `last_authenticated_at` session cookie, and redirecting
the user to a password confirmation page if they haven't re-entered
their password in the last hour.
This is modeled after Github's Sudo mode.
Track when an API key was last used, which IP address last used it, and
how many times it's been used overall.
This is so you can tell when an API key was last used, so you know if
the key is safe to delete, and so you can tell if an unrecognized IP has
used your key.
Add the ability to restrict API keys so that they can only be used with
certain IP addresses or certain API endpoints.
Restricting your key is useful to limit damage in case it gets leaked or
stolen. For example, if your key is on a remote server and it gets
hacked, or if you accidentally check-in your key to Github.
Restricting your key's API permissions is useful if a third-party app or
script wants your key, but you don't want to give full access to your
account.
If you're an app or userscript developer, and your app needs an API key
from the user, you should only request a key with the minimum
permissions needed by your app.
If you have a privileged account, and you have scripts running under
your account, you are highly encouraged to restrict your key to limit
damage in case your key gets leaked or stolen.
* Add an explanation of what an API key is and how to use it.
* Make it possible for the site owner to view all API keys.
* Remove the requirement to re-enter your password before you can view
your API key (to be reworked).
* Move the API key controller from maintenance/user/api_keys_controller.rb
to a top level controller.
Regression caused by the switch from the mobile API to the Ajax API. In
the Ajax API, commentaries have /jump.php?<url> links that we have to strip out.
Fix the Pixiv API no longer working by rewriting the Pixiv strategy to
use the Ajax API instead of the mobile API.
Before we could authenticate in the mobile API by using the OAuth 2.0
grant_type=password authentication flow. This no longer works. Now it
requires logging in through a HTML page, which is protected by Google
reCaptcha. This makes using the mobile API infeasible.
Instead we switch to the Ajax API, which only needs a PHPSESSID to
authenticate. This can be obtained by logging in manually and using the
devtools to extract the cookie.
This also temporarily removes support for Pixiv novels. This should be
moved to a separate source strategy.
Pixiv API client is currently broken. Temporarily disable Pixiv source
strategy so direct image Pixiv uploads can still go through. The
posts.pixiv_id field will need to be backfilled later.
Some of these pages were accidentally crawled because rules like `Allow:
/artist` allowed `/artist_versions` to be crawled (Allow rules are
prefix matches).
Regression caused by the upgrade to Webpacker 6.0 in 90cd3293e. This
caused various Javascript errors in old versions of Chrome, which
somehow resulted in the keyboard shortcut for visiting the next page
being triggered when you pressed any key.
Specifically, the mobx library (used by the TagCounter component) called
`Object.entries`, which isn't available in Chrome 49, and for some
unknown reason this triggered the buggy shortcut behavior.
`Object.entries` is supposed to be automatically polyfilled by Babel to
support old browsers, but something changed in Webpacker 6 that broke
this and I couldn't get it working again. The probable cause is that
Webpacker 6 no longer transpiles code inside ./node_modules by default,
which means that any libraries we use that use new Javascript features
won't get transpiled down to support old browsers, but even after fixing
that it still didn't work. The workaround is to just drop mobx and
preact entirely to avoid the issue.
Fix tests not working in Github. They were failing because the latest
version of Webpack needs a version of Node newer than the version in
shipped Ubuntu 20.04.
Also fix the Docker build failing because of the system timezone
database not being installed in Ubuntu 20.10.
6d867de20 caused an exception in the ApiKeysController, which calls
respond_with with two arguments: `respond_with(CurrentUser.user, @api_key)`.
`options[0]` referred to the second argument, which was incorrect.
On the post show page, define the next page / previous page keyboard
shortcuts in html using data-shortcut attributes instead of in
Javascript. This is consistent with how these shortcuts are defined on
the post index page.
* Factor out the post navbar into a component. The post navbar is the
part of the post containing the current search, the list of pools, and
the list of favgroups, along with next/prev navigation links.
* Change navbar markup: remove various unused CSS classes/IDs, change
pools to use same markup as favgroups, replace nested <div>'s with
flat <ul>/<li> list.
* Use CSS to truncate long searches/pool names/favgroup names if they're
too wide for the screen (especially on mobile).
Like 9efb374ae, allow users to toggle between upvoting and downvoting a
post without raising an error or having to manually remove the vote
first. If you upvote a post, then downvote it, the upvote is
automatically removed and replaced by the downvote.
Other changes:
* Tagging a post with `upvote:self` or `downvote:self` is now silently
ignored when the user doesn't have permission to vote, instead of
raising an error.
* Undoing a vote that doesn't exist now does nothing instead of
returning an error. This can happen if you open the same post in two
tabs, undo the vote in tab 1, then try to undo the vote again in tab 2.
Changes to the /post_votes API:
* `POST /post_votes` and `DELETE /post_votes` now return a post vote
instead of a post.
* The `score` param in `POST /post_votes` is now 1 or -1, not `up` or
`down`.
Change post votes to work the same way as comment votes:
* Make the upvote arrow blue if you've upvoted the post, or grey if you
haven't. Likewise for the downvote arrow.
* Make it so you can click the upvote or downvote arrows to undo the vote.
* Don't show any notices when you vote on a post.
Also fix it so that votes work the same way on the posts page, the
comments page, and in the modqueue. Before it wasn't possible to undo
votes on the comments page or in the modqueue.
evazion
evazion