Danbooru 2 Issues Topic

nonamethanks said:

The report dialogue is unique for all report forms, and it can be found here: help:report_notice. Since it's a wiki page loaded via javascript by the report button, it's editable by any builder.
But there probably should be a different report form for forums and comments, so that more detailed guidelines can be added for each case. Not sure though if that's warranted, as I have no idea how many reports are submitted on average.

For the time being, I've tried putting the link in, it seems to appear just fine even though it highlights the howto link for some reason.
I guess I'll wait to see if something else comes up, but in the meantime thanks for the info.

Is the list of missed searches broken? It contains aliased tags like milf and foot.
Also, deleted wikis count has having a wiki, like for danboru.

kittey said:

Is the list of missed searches broken? It contains aliased tags like milf and foot.

I opened issue #4433 yesterday for this.

I am having an issue where a list of tags with certain tags eg. azur_lane and girls_und_panzer are empty

here is an image of what I am experiencing:
https://i.imgur.com/JVT5G0h.jpg

Site update

Changes

• Bulk update requests now require a reason when making a request.
• Searches that include a single tag now always show the Wiki tab, even if the search includes other metatags. For example, touhou rating:safe now shows the wiki for touhou.
• All search metatags can be negated now. Previously certain metatags like -score:42 or -width:1000 didn't work.
• The "This tag is being discussed" notice is only shown on the first page of searches now.
• Modqueue: "Post is already active" errors aren't shown when disapproving a post that has already been approved by another user. "You have already hidden this post" errors aren't shown when disapproving a post you already disapproved in another tab.

Fixes

• Fixed artist bans not updating the artist history to record the change to the is_banned flag.
• Fixed searching artists by URL not working when the URL had leading or trailing whitespace.
• Fixed bulk update requests redirecting you to an unhelpful error page if the request had a typo.

API Changes

• Removed the undocumented raw param from /posts. This was used to do a "raw" tag search that ignored aliases. Instead you can search for unaliased:<tag> if you need to search for a raw tag without applying aliases. This normally isn't needed except for bugged tags or aliases that are still in progress.

Full changelog: https://github.com/danbooru/danbooru/compare/production-2020.04.28-055724-utc...production-2020.05.04-235019-utc

I've been having this weirdness for maybe a couple of weeks where images on post pages are always scaled to window having "default image width" set to original. Seems to only happen with images that are wider than the window, and not ones that are only taller.

The "resize to window" link on the left sidebar still toggles between fullsize and resized but I thought it was full size by default before.

Seems to behave the same in firefox and edge.

for example, post #3903351 is scaled to fit, while post #3903453 isn't.

I could have sworn it didn't behave like this before, but if I'm mistaken, then just ignore this. Otherwise maybe a toggle for whether to show full size or scaled to fit could be added?

Yuichi_Nietzche said:

I've been having this weirdness for maybe a couple of weeks where images on post pages are always scaled to window no matter how the relevant settings in my account are set.

That became the new default two months ago; see forum #164477. If you want to start out with a full-size image all the time, see forum #166058.

The option to not automatically fitting wide images to the window was removed for several reasons:

• The option defaulted to on (fit images to the window) for new users for several years now.
• It defaulted to off for old users who signed up more than a few years ago. This is a problem because it meant we had two groups of users with two very different Danbooru browsing experiences, based on when they created their account.
• With this option off, you basically had to scroll down and click "resize to window" or double press the V key every time you opened an absurdres or incredibly absurdres post so you could actually see anything. I think this is a bad experience for most people. I think most people didn't know how to do this, or didn't know how to change their settings to fix it. I think this drove people away from the site.
• Few new users turned this setting off (<0.5%), while a relatively large number of old users turned it on (~4%). This tells me that when given the choice, most people want to have this setting on, and not many want to turn it off.
• Forcibly turning the setting on for old users is tantamount to removing the option. So I removed the option.
• Pretty much every other image site or image viewing program works this way. Notice how Pixiv and Twitter work: huge images are fit to the screen by default and you don't have an option to turn it off. Turning it off is not something you would even think of.
• The actual behavior of this option was complicated. We ignored it on the upload page and in the mobile layout. We ignored it because you really don't want to open huge images at full size by default when browsing on your phone. But if you're browsing on something else with a small screen, like a tablet or a laptop, then you probably don't want to see full images there either. Dealing with this means trying to guess when this setting should be ignored, which is impossible to get right.

evazion said:

• Few new users turned this setting off (<0.5%), while a relatively large number of old users turned it on (~4%). This tells me that when given the choice, most people want to have this setting on, and not many want to turn it off.
• Forcibly turning the setting on for old users is tantamount to removing the option. So I removed the option.

The large difference between them is that keeping it as an option allows people to choose the way they'd like to experience the site. 4% is still much too small to draw the conclusion that a strong preference exists.

evazion said:

• Pretty much every other image site or image viewing program works this way. Notice how Pixiv and Twitter work: huge images are fit to the screen by default and you don't have an option to turn it off. Turning it off is not something you would even think of.

Both twitter and pixiv have viewer functionality that danbooru does not in order to compensate for this. Clicking on the image on pixiv brings you to the full-size illustration. Twitter was not made with artwork primarily in mind, but even there if you open the image in a new tab, clicking on the image toggles between two states of zoom.
Most importantly, on both sites, changing your browser zoom does not change the size of the image. Currently on danbooru, if you zoom in the image gets smaller and if you zoom out the image gets bigger until it's at full size. This is clearly bad design because it prevents you from controlling the size at which it displays on your screen if you want to see it at full resolution.

If the behavior of the fit width option can be fixed, there might well not be a need for the other option. If there is something preventing it, then the users' ability to choose should have been preserved.

Let me put it this way: opening something like post #3840194 in full size by default is absolutely useless. You can't see anything at all without resizing it. It's basically a "make absurdres posts unviewable" option. That's not something that I think makes sense to support.

Zurreak said:

Both twitter and pixiv have viewer functionality that danbooru does not in order to compensate for this. Clicking on the image on pixiv brings you to the full-size illustration. Twitter was not made with artwork primarily in mind, but even there if you open the image in a new tab, clicking on the image toggles between two states of zoom.

This is the direction I intend to go. Clicking the image will toggle the image size. This will require changing the click-to-toggle-notes behavior to something else, which is frankly going to be another ordeal in itself, which is why it hasn't been done yet.

evazion said:

You can't see anything at all without resizing it.

But you can resize it. That's an important difference. The problem with full size by default can be worked around in a way that most users are easily capable of.
However, the problem with fit width which becomes apparent on posts like post #3304724 is that you can't zoom in on the image any more past a certain point. Very large posts which are intentionally zoomed out are sacrificed in order to make some other absurdres images more conveniently sized by default. To re-emphasize, with the current default you have no easy or convenient method to look any closer at the image past a certain (insufficient) upper bound.
This wouldn't be a problem if the image simply didn't resize when the browser zoom changes. The vast majority of the time, when someone changes the level of zoom, it's to change their view of the image itself.
Earlier, you mentioned that a people can learn from observing the design of other image sites. That especially applies here. Preserving users' ability to fine-tune their control of how large an image displays will substantially improve user experience. A zoom toggle could be alright, but having exactly two options for your level of zoom will usually not be enough at all.

Could we perhaps table this conversation and have it take place in a new/other topic? This topic should be reserved for actual issues and not in differences of opinion on features. I for one monitor this thread for emerging issues, and all of this debating is just a bunch of chaff. Thanks.

Site update

Changes

• Builders can now approve artist aliases and mass updates. Requests to move artists with more than 100 posts still require admin approval. This may be changed in the future.
• Added Github, Twitter, and Discord links to the site footer.
• Added upload support for HentaiFoundry.
• Removed the wiki edit box from the artist edit page. If you need to edit an artist wiki, you should do so by going to the wiki edit page.

Fixes

• Fixed DeviantArt uploads being broken.
• Fixed not being able to rename artists with wiki pages.
• Fixed searches for aliased tags being counted as missed searches.
• Fixed searches for aliased tags showing the wiki page for the empty aliased tag instead of for the target tag (i.e. searching nekomimi now shows the wiki for cat ears).
• Fixed user-dependent searches returning wrong page counts or wrong tags in the sidebar in some cases. User-dependent searches are searches that return different results for different users, for example, the status:unmoderated tag, search:all, or searches for private favorites.

API Changes

• /counts/posts.json:
• Null is now returned for the count if the count couldn't be determined because of a timeout or other error. Previously if there was a timeout we returned either 1000000 or an error if the raise_on_timeout option was given.
• Removed the raise_on_timeout parameter.
• Added an estimate_count parameter. By default, some searches will return an estimated count. The estimated count may differ from the exact count. You can pass estimate_count=false to override this.

• Added a X-Git-Hash HTTP header to all API responses and a <meta name="git-hash"> tag to all HTML responses. The git hash is the hash of the currently running commit.

Full changelog: https://github.com/danbooru/danbooru/compare/production-2020.05.04-235019-utc...production-2020.05.13-053232-utc

Could you give an example of the sort of search that would give an estimated count so I can compare the two and see if adding that estimate_count=false is worth it?

Currently it's just the empty search, rating:s, rating:q, and rating:e, but this may be expanded to other searches in the future. These searches were actually estimated before, but the estimates were based on outdated ratios and it wasn't possible to bypass them. The current estimates should be more accurate than before.

evazion said:

• Builders can now approve artist aliases and mass updates. Requests to move artists with more than 100 posts still require admin approval. This may be changed in the future.

Is there a post ceiling for mass edits too? What's stopping Builders from brute-forcing changes by approving their own BURs?

Okay, thanks. And I had noticed that the combined total of the three rating searches never added up to what they should.

Hillside_Moose said:

Is there a post ceiling for mass edits too? What's stopping Builders from brute-forcing changes by approving their own BURs?

The ceiling applies to aliases and mass updates. Builders can only approve a request if 1) it contains only aliases for artist tags or mass updates for artist tags and 2) none of the artist tags have more than 100 posts.

Oh, it only applies to artist tags. Thanks for the clarification, I got a bit worried for a moment.

My other concern is Builders rushing it in cases of mistaken identity. Some artists may have similar styles but turn out to be different people, or in worse cases, plagiarists getting lumped with the originals.