Danbooru 2 Issues Topic

I've been experiencing the same issue that 90sAnimeFan and MyrMindservant have mentioned, but there's something important to note: it only works incorrectly for me when I search for a URL which doesn't have a corresponding artist entry. Searching for existing artists works just fine.

Site update

Changes

• Pool versions: added a new search page (/pool_versions/search). Improved diffs of pool descriptions.
• DText: links to artist tags now link to the artist page instead of the wiki page.
• Tag scripts: changed how tag scripts are stored. If you had tag scripts before, they will have been cleared.
• Builders: removed the Aliases and Implication pages from the main menu. These are now found under the Tags page instead.
• Mods: removed the down voting report option on post pages. This hasn't been working for a while. You can use the /post_votes page to investigate downvoting activity instead.
• Removed the Meta Searches page (previously found under the Tags page). This was a page that let you search for tags, aliases, and implications at the same time. It was broken and never got much use.

Fixes

• Fixed artist search not working with new Pixiv profile urls.
• Fixed incorrect uploader column on post votes page.
• Fixed title option not working on forum search page.
• Fixed bug with newly promoted approvers immediately getting demoted for inactivity.

Full changelog: https://github.com/danbooru/danbooru/compare/production-2020.01.07-085853-utc...production-2020.01.09-200853-utc

evazion said:

• Tag scripts: changed how tag scripts are stored. If you had tag scripts before, they will have been cleared.

Does the numpad no longer provide a separate set of tag scripts?

No, that was unintentional behavior and has been removed.

Minor update

• Fixed issue with Members not being able to tag posts.
• Mods: removed IP addresses from most pages. If you need to check for sockpuppets, you can check the IP in the user's profile or use the /ip_addresses page.

Possible bug.

I tried using strikethrough on a now dead link on a Wiki page. The [/s] got treated as part of the link and didn't negate, thus striking through all links.

Putting a space after the link worked, though.

Jigsy said:

Possible bug.

I tried using strikethrough on a now dead link on a Wiki page. The [/s] got treated as part of the link and didn't negate, thus striking through all links.

Putting a space after the link worked, though.

When the URL formatting grabs too much, you can put the URL in < > brackets to tell it where the link ends. For example:

[s]Homepage: <http://blogs.yahoo.co.jp/moonknives>[/s] (dead)

Homepage: http://blogs.yahoo.co.jp/moonknives (dead)

Favorite group visibility is not always consistent with the user's preference. Currently users must turn on privacy mode for the "is public" checkbox to take effect. Otherwise all of their favorite groups are made public regardless of what they have set the visibility to on the individual groups.

This issue was already touched on by evazion in pull request #3436, but I wanted mention it again because the behavior of this checkbox as an override for privacy mode only is somewhat confusing. A user who didn't understand the behavior of the checkbox could end up exposing favorite groups they thought were private without realizing it should they ever decide to switch out of privacy mode. Also, as was mentioned in the pull request, users are discouraged from switching out of privacy mode if they are relying on it to keep a favorite group private, even if they might otherwise be happy to share the rest of their profile and favorite groups.

Site update

Changes

• Pools:
• Removed the recent pools section from the Add to Pool dialog.
• Removed the full pool list dropdown from the Add to Pool dialog.
• Removed the pool 'active' flag. This flag was only used to determine which pools showed up in the full pool list in the Add to Pool dialog.
• Flags: removed the restriction against flagging too many posts by the same uploader. This sometimes interfered with legitimate flagging, especially with old legacy content. This is not to say that harassment of specific uploaders is okay, rather that harassment will be judged manually.
• Inactive approvers are now demoted monthly instead of weekly. The deadline is the 1st of the month at midnight, UTC time.
• Notes: in note edit boxes, the title was moved to the body so that the note id can be copied.
• Removed the /explore/posts/intro page. This was an old concept for an alternate frontpage that never got used.
• Disabled browser autocomplete in most edit forms. This is to fix Firefox not clearing edit forms after reloading the page. This should only affect Firefox users.

Fixes

• Approvers: fixed not being able to tag a post after approving it. This only affected Firefox 72 users.
• Fixed the deleted pool search option not working on the /pool_versions/search page.
• Fixed the diff button on wiki history pages page to always compare versions in the right order (newest version vs oldest version).
• Fixed false positives in the artist finder when searching for Pixiv fanbox urls.

API Changes

• Added more data-post-* attributes to <body> tag on post pages.
• Added more IDs and CSS classes to <table> tags.
• Removed the 'DELETE /pool_element' endpoint (used to remove a single post from a pool).

Full changelog: https://github.com/danbooru/danbooru/compare/production-2020.01.09-200853-utc...production-2020.01.14-172839-utc

eyedrops said:

Favorite group visibility is not always consistent with the user's preference. Currently users must turn on privacy mode for the "is public" checkbox to take effect. Otherwise all of their favorite groups are made public regardless of what they have set the visibility to on the individual groups.

This issue was already touched on by evazion in pull request #3436, but I wanted mention it again because the behavior of this checkbox as an override for privacy mode only is somewhat confusing. A user who didn't understand the behavior of the checkbox could end up exposing favorite groups they thought were private without realizing it should they ever decide to switch out of privacy mode. Also, as was mentioned in the pull request, users are discouraged from switching out of privacy mode if they are relying on it to keep a favorite group private, even if they might otherwise be happy to share the rest of their profile and favorite groups.

Filed this as issue #4257.

When I browse my sent and received (personal) messages, there seems to be an error affecting the recipients column (the "To" column). Instead of showing the recipients, the "To" column is mirroring the "From" column.

When browsing the received messages, this is only a minor distraction. However, it is genuinely hard to browse the sent messages when I have seemingly sent every single one to myself.

As I view the messages themselves, both the sender info and the recipient info are correct, so I hope this is a minor issue.

Is anyone else experiencing the same?

Katajanmarja said:

When I browse my sent and received (personal) messages, there seems to be an error affecting the recipients column (the "To" column). Instead of showing the recipients, the "To" column is mirroring the "From" column.

I’m seeing this as well.

Fixed.

I can't seem to add images to favorite groups by pressing ''g'' shortcut or using ''Add to fav group'' option. Tested in both Firefox and Chromium.

Edit: Seems like it's fixed now, that was quick. Thanks.

The favgroup bug has been fixed.

Edit: Seems like it's fixed now, that was quick. Thanks.

My thanks for the fixes as well.

Don't know if this is intentional or not, but the wiki diff revisions changed color. It was green for added things and red for removed, but it seems to have flipped.

edit: apparently an issue was already filed

I've suddenly noticed thumbnails (and sometimes entire images) are failing to load without multiple refreshes. While attempting to load images it says "waiting for cdn.donmai.us". Is anyone else noticing this?

Investigating, the thumbnail server appears to be under high load for some reason.

It resolved itself. Probably someone downloading images too aggressively. I will likely have to add some rate limits to throttle over-aggressive downloaders.