Hmm, I just discovered that it's possible to get a "Search Timeout" page when navigating to a wiki page (Kotobuki Tsumugi, for the curious).
Posted under General
This topic has been locked.
Hmm, I just discovered that it's possible to get a "Search Timeout" page when navigating to a wiki page (Kotobuki Tsumugi, for the curious).
I'm not sure if it's an issue but I appealed the post #3085233 it tells me that user 525419 approved it but the status is still in pending.
Below273 said:
I'm not sure if it's an issue but I appealed the post #3085233 it tells me that user 525419 approved it but the status is still in pending.
https://danbooru.donmai.us/posts/3085233/events
It was approved and then flagged.
nonamethanks said:
https://danbooru.donmai.us/posts/3085233/events
It was approved and then flagged.
Oh I see, thank you for the answer.
https://danbooru.donmai.us/posts/2136751
Why this image just disappeared from danbooru without being deleted?
<span style="font-family: childlike;">text goes here</span>
.data-is-favorited
attribute from post thumbnails.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
741qwe852asd963zxc said:
https://danbooru.donmai.us/posts/2136751
Why this image just disappeared from danbooru without being deleted?
What exactly is your problem with that post? It shows up just fine for me.
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.
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.
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.
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.
"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.
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?
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
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?
https://danbooru.donmai.us/favorites.json?search%5Buser_id%5D=508240&limit=1000 has a runtime of 0.09 seconds, so I'm not sure what you're doing to end up with a slow query.
BTW it accepts ranges too, so you can do something like
https://danbooru.donmai.us/favorites.json?search%5Buser_id%5D=508240&limit=1000&search%5Bpost_id%5D=1..500000
or
https://danbooru.donmai.us/favorites.json?search%5Buser_id%5D=508240&limit=1000&search%5Bpost_id%5D=<500000
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.