Danbooru

Danbooru 2 Issues Topic

Posted under General

This topic has been locked.

evazion

Site update

Changes
  • Builders now have unlimited tag searches. This means you can search for an unlimited number of tags at once. However, timeout limits still apply, so searches that are too complex may not work.
  • Builders now have unlimited favorite groups. There is still a limit of 10,000 posts per favgroup.
  • Builders now have unlimited saved searches.
  • Builders can now browse an unlimited number of pages. Before you couldn't go past page 5000. Now there is no limit. However, timeout limits still apply and going too deep may be too slow to work.
  • Builders can now approve renames or aliases for artists with up to 200 posts. Before the limit was 100 posts.
  • Changed it so that wildcard searches match the top 100 tags. For example, *_legwear will match the top 100 legwear tags. Before it only matched the top 25. This means things like thighhighs -*_legwear work better.
  • Added a "childlike" font for use in notes by translators. Usage: <span style="font-family: childlike;">text goes here</span>.
  • Changed autocomplete to show a wavy red underline beneath misspelled tags.
  • Added an option for Mods to regenerate post thumbnails.
Fixes
  • Fixed an issue with post replacements that prevented being able to replace a post with its own source.
  • Fixed an issue with not being able to see image previews for Weibo uploads on the uploads page.
  • Fixed an issue with Gelbooru sources being broken in the post sidebar.
  • Fixed issues with the artist finder returning incorrect results for certain Baraag and Pixiv URLs.
  • Fixed it being possible for Builders to approve aliases for non-artist tags if they were both empty.
  • Fixed browsers marking tags as misspelled in the tag search box, among other places.
API
  • Removed the data-is-favorited attribute from post thumbnails.
  • Removed the is_favorited attribute from the /posts.json API.

Full changelog: https://github.com/danbooru/danbooru/compare/production-2020.12.25-082830-utc...production-2021.01.05-083520-utc

wisedog

evazion said:

API
  • Removed the data-is-favorited attribute from post thumbnails.
  • Removed the is_favorited attribute from the /posts.json API.

Any replacement or alternative for this? I've been using it in my custom css to darken thumbnails for images that I favorite.

Akiraka8

wisedog said:

Any replacement or alternative for this? I've been using it in my custom css to darken thumbnails for images that I favorite.

The only workaround I know of for now is to add -fav:<your_name> to your tag searches, which will omit images you already favourited. This isn't ideal though, because it means having to type it into the query manually in situations that used to just be a mouse-click away, and it also means running a second search after you click on a tag and see the search results if you want to omit your favourites.

skylightcrystal

Akiraka8 said:

The only workaround I know of for now is to add -fav:<your_name> to your tag searches, which will omit images you already favourited. This isn't ideal though, because it means having to type it into the query manually in situations that used to just be a mouse-click away, and it also means running a second search after you click on a tag and see the search results if you want to omit your favourites.

I used it for a special coloured border around my favourites which meant I could easily see, for instance, if an identical (or near-identical) parent/child post was already favourited, and thus prevent me from making duplicate favourites, without having to manually check every image. Unfortunately, after this change the only way to do this I can think of would be to blacklist my own favourites, which is just silly.

Akiraka8

skylightcrystal said:

I used it for a special coloured border around my favourites which meant I could easily see, for instance, if an identical (or near-identical) parent/child post was already favourited, and thus prevent me from making duplicate favourites, without having to manually check every image. Unfortunately, after this change the only way to do this I can think of would be to blacklist my own favourites, which is just silly.

I did the same, often to "upgrade" a favourite from child to parent. I'd personally like to have this functionality back because the workarounds all involve having to manipulate tags and run unnecessary searches, and none of them quite get us back to where we started. I don't know why it was removed though, and there must be a reason for it.

kittey

Akiraka8 said:

I don't know why it was removed though, and there must be a reason for it.

See issue #4652. The old system was bugged and the new system is not bugged but performs worse. I guess the is_favorited information was removed to counter the performance issues.

Login to view

"Bumping" my previous suggestion, since it went unnoticed.

Should updates and update/bug report discussion be kept in separate threads, to keep them more clean? We already do it with other things such as topic #15855/topic #16337.
I personally would appreciate the change, since i tend to miss important updates between bug reports.

rooooosk

evazion said:

Site update

Changes
  • Builders now have unlimited tag searches. This means you can search for an unlimited number of tags at once. However, timeout limits still apply, so searches that are too complex may not work.
  • Builders now have unlimited favorite groups. There is still a limit of 10,000 posts per favgroup.
  • Builders now have unlimited saved searches.
  • Builders can now browse an unlimited number of pages. Before you couldn't go past page 5000. Now there is no limit. However, timeout limits still apply and going too deep may be too slow to work.
  • Builders can now approve renames or aliases for artists with up to 200 posts. Before the limit was 100 posts.
  • Changed it so that wildcard searches match the top 100 tags. For example, *_legwear will match the top 100 legwear tags. Before it only matched the top 25. This means things like thighhighs -*_legwear work better.
  • Added a "childlike" font for use in notes by translators. Usage: <span style="font-family: childlike;">text goes here</span>.
  • Changed autocomplete to show a wavy red underline beneath misspelled tags.
  • Added an option for Mods to regenerate post thumbnails.
Fixes
  • Fixed an issue with post replacements that prevented being able to replace a post with its own source.
  • Fixed an issue with not being able to see image previews for Weibo uploads on the uploads page.
  • Fixed an issue with Gelbooru sources being broken in the post sidebar.
  • Fixed issues with the artist finder returning incorrect results for certain Baraag and Pixiv URLs.
  • Fixed it being possible for Builders to approve aliases for non-artist tags if they were both empty.
  • Fixed browsers marking tags as misspelled in the tag search box, among other places.
API
  • Removed the data-is-favorited attribute from post thumbnails.
  • Removed the is_favorited attribute from the /posts.json API.

Full changelog: https://github.com/danbooru/danbooru/compare/production-2020.12.25-082830-utc...production-2021.01.05-083520-utc

I use the is_favorited attribute from the /posts.json API, please add it back. My custom Android TV screensaver app is now throwing uncaught exceptions because the tag is missing. How am I supposed to know, via the JSON object, if I have previously favorited a post?

nonamethanks

rooooosk said:

I use the is_favorited attribute from the /posts.json API, please add it back. My custom Android TV screensaver app is now throwing uncaught exceptions because the tag is missing. How am I supposed to know, via the JSON object, if I have previously favorited a post?

See https://github.com/danbooru/danbooru/issues/4652#issuecomment-754803065 - you should query /favorites.json. The fav string was removed because it was unreliable and added a layer of complexity to mantaining the code.

Akiraka8 said:

I did the same, often to "upgrade" a favourite from child to parent. I'd personally like to have this functionality back because the workarounds all involve having to manipulate tags and run unnecessary searches, and none of them quite get us back to where we started. I don't know why it was removed though, and there must be a reason for it.

You can see all of your child favorites with fav:Akiraka8 parent:any FYI, which is just one search.

Updated

rooooosk

nonamethanks said:

See https://github.com/danbooru/danbooru/issues/4652#issuecomment-754803065 - you should query /favorites.json. The fav string was removed because it was unreliable and added a layer of complexity to mantaining the code.

That is not an acceptable solution. It would greatly complicate my code, and more than double the number of API requests I would have to make. I don’t understand how rearchitecting how you internally track user favorites necessitated a change to how you report them within query results. Who makes a breaking change to a publicly facing API on a whim? And then tells the affected users that they will just have to work around it? And to do so, they will have to use an undocumented endpoint?

Also, I just played around with that endpoint, trying to figure out how to use it, and it is very slow, and most of the queries I tried timed out. And, why is it user ID instead of user name?

Laethiel

I also used data-is-favorited in my CSS so I could see my favourites at a glance when searching. As Akiraka8 said, adding -fav:<name> is far from ideal, especially since I don't want to remove them from the results most of the time; it can be nice to happen across an old favourite and take another look. And while the search that NNT suggested is certainly helpful for the specific case of intentionally looking for child favs to swap to their parent images, it doesn't do anything for normal browsing.

I'd be fine with a UserScript solution to bring this functionality back, but I don't know how to make one that does more than just interact with page elements, and it seems this would now need to use the API.

Nacha

VSD02C said:

Yeah, there's an issue.

The deletion appeal thread is locked.

It's locked, because you should post in the Feedback request thread. The deletion appeal thread is only for the appeal function.

1 310 311 312 313 314 315