This is longstanding problem, discussed in issue #1039. Basically, the problem is that for mutually exclusive tags (tags that independently have a large number of posts, but that when combined together produce few-to-no results), searches become very slow and likely to time out. Some other examples: solo multiple_girls, banned_artist -status:banned, highres lowres, long_hair no_humans.
There is a trick, however: add order:score to the search and like magic it won't time out. The reason why this works is fairly involved, but the basic explanation is that order:score tricks the database into searching using a different strategy than it normally would, which happens to be faster for these searches.
Thanks for the explanation, it helps a lot. I'll have to remember that in the future.
The 'Save search' button has been moved to the new '+' dropdown next to the search box.
I don't see any + dropdown next to the search box. I disabled all my Greasemonkey scripts and still don't see it. I'm on Firefox 52. There doesn't seem to be any way to add new saved searches.
I don't see any + dropdown next to the search box. I disabled all my Greasemonkey scripts and still don't see it. I'm on Firefox 52. There doesn't seem to be any way to add new saved searches.
Are you using custom CSS to hide the "Go" button by the search box? I was, and I had to tweak it so it wouldn't hide the '+' too
On another note, after cleaning up all (?) posts I found in solo solo_focus, the search only gives me this error.
evazion said:
Basically, the problem is that for mutually exclusive tags (tags that independently have a large number of posts, but that when combined together produce few-to-no results), searches become very slow and likely to time out.
There is a trick, however: add order:score to the search and like magic it won't time out.
An alternate workaround is to add a post ID range to the request. solo multiple_girls times out, but solo multiple_girls id:1..1000000 doesn’t (it even returns some posts...). When you’re done with that range, increase the numbers. If it still times out or is just too slow for your tastes, use a smaller range. This always works, even if order:score doesn’t do the trick.
As I’m too lazy to update the numbers myself, I wrote a user script that displays a second paginator for the IDs whenever it detects an ID range in the search field. I’m usually using 250k ranges, so that’s just ten clicks to go over all currently existing posts.
Btw, here’s what I’m using to hide the “Go” button of the search box. I think it’s a bit more resilient against future changes.
/* Hide the Go button of the search box */
#search-box form input[value="Go"] {display:none!important}
Edit: Background for the code fixed thanks to BrokenEagle98.
You need more spaces between your code blocks and pre and post sentences. It's because you're still in the INLINE ragel machine. To break out to the MAIN ragel machine, you need to have two carriage returns.
Backstory is, when Dtext_RB/Issue 9 was fixed to allow code blocks to be inline, albert used blocks instead of <pre> blocks. <code> blocks currently don't have the grey background CSS styling (but probably should).
h5. Edit:
Created issue #2939.
Did anyone else’s saved searches have all their individual tags reordered as well? For example, if I saved artist -something, it would show up as -something artist. copyright a_thing would turn into a_thing copyright. Both are kind of annoying because it’s harder to find the queries I’m looking for. Ordering the saved searches table by query is also kind of useless now because it orders strictly by ASCII from left to right, so all queries with excluded tags are at the top and few of the others are where I expect them.
Hmm, it looks like tags within saved searches were indeed resorted in alphabetical order (commit #da06bee0). I would consider this a bug. Internally, they're sorted so that if two people have the same search but the tags are in a different order, the site only performs the search once. But they don't have to actually be saved that way.
I don't think it will be possible to undo this, everyone's searches have already been resorted :/.
I don't think it will be possible to undo this, everyone's searches have already been resorted :/.
I have less than 100 saved searches with more than one tag. I’d be fine with reordering all those manually, as long as the site doesn’t undo that again...
Trying to add tags to post #8856 gives me this error:
Magick::ImageMagickError exception raised
unable to open image `/var/www/danbooru2/releases/20170322212609/public/data/f0e32c0e2d906c4932858866346f98b5.gif': No such file or directory @ error/blob.c/OpenBlob/2712
app/models/post.rb:177:in `ping'
app/models/post.rb:177:in `is_animated_gif?'
app/models/post.rb:684:in `add_automatic_tags'
app/models/post.rb:638:in `normalize_tags'
app/controllers/posts_controller.rb:49:in `update'
Thanks, fossilnix and BrokenEagle98. The custom CSS is why I didn't see the + dropdown. I had forgot I ever set that.
Thanks, kittey. That updated code block works.
If anyone uses Danbooru Miscellaneous Tweaks script to move the search bar into the navbar, I made the following change so that it includes the + dropdown. 1. Turn off the tweaks and copy the HTML source for the + dropdown.
2. Edit the script. Go to the line with searchBox.innerHTML =. Paste that into the string before </form>. You may need to remove extra newlines and spaces from what you paste.
Trying to add tags to post #8856 gives me this error:
This is another thing caused by image hosting moving offsite. There's an autotagger that automatically tags animated gifs whenever the post is saved, but that doesn't work now that image files aren't kept on the same server anymore.
I'll make an issue. Currently this should only affect gifs below post #10000.
This is another thing caused by image hosting moving offsite. There's an autotagger that automatically tags animated gifs whenever the post is saved, but that doesn't work now that image files aren't kept on the same server anymore.
I'll make an issue. Currently this should only affect gifs below post #10000.
Funny thing is that I could tag it like normal when I tried from my phone a few hours later.
Moving favorites now gives an upvote to the parent post on behalf of every favoriter who has voting privileges. This includes gold+ and supervoters. For supervoters, these upvotes will be superupvotes (+3).
Previously favorites by member-level supervoters didn't give upvotes. Only gold-level supervoter favs gave upvotes. Now all supervotes favs give a superupvote.
Upvotes are based on the user's current privileges. So normally when a regular member favorites a post, it doesn't give an upvote. But if later they upgrade to gold or become a supervoter, and their favorites are moved, those favs will now give upvotes.
Likewise, if a person loses their voting privileges, moving their favorites won't upvote the parent, even though that favorite may have originally upvoted the child.
Non-favorite votes are not (yet) moved. Voting records only kept for 90 days, so in many cases there won't be many votes left to move. And I'm not sure if downvotes should be moved, since if someone downvotes a post for being an image sample, that shouldn't necessarily translate to the parent.
