Danbooru 2 Issues Topic

r0d3n7z said:

Thinking more about it, blacklist:only isn't actually necessary, blacklist:show would suffice for the tag gardening use case. I'd be okay if we only had blacklist:hide/show/exclude.

blacklist:exclude can be abused the same way as blacklist:only can. The user simply needs to negate every tag. e.g. If they want to search for test1 test2 test3 -test4 they put into their blacklist:

-test1
-test2
-test3
test4

and search blacklist:exclude.

r0d3n7z said:

Insofar as query cost goes, as things are currently we already incur the cost of joining tag search results with user blacklist tags in order to style the <article> tag with class blacklisted, so I reasoned that the only additional cost for blacklist:exclude/only would be an additional restriction (in the relational algebra sense of the word)...

Not sure I understand what you mean. Current blacklist implementation incurs no sql query costs at all. It's all javascript.

Toks said:
blacklist:exclude can be abused the same way as blacklist:only can. The user simply needs to negate every tag. e.g. If they want to search for test1 test2 test3 -test4 they put into their blacklist

Hm, that's true. Does it make sense to blacklists to have rows that contain only negations?...

If we also scrap blacklist:exclude, then it's all pretty moot I guess.
blacklist:show alone should be doable purely with a userscript that removes the blacklist:active class shortly after page load. ...actually, maybe I should just do that sometime, it'd only be a couple lines of code and much better than temporarily clearing my blacklist when bulk tag gardening.

Toks said:
Not sure I understand what you mean. Current blacklist implementation incurs no sql query costs at all. It's all javascript.

Welp, that's what I get for making assumptions without checking the source code.

The main problem with blacklist:exclude is that it'll add lots of conditions to "where" clause, often causing query, especially count query, to time out. If this gets implemented by some miracle I would rather have a user setting like for deleted post filter, or, even better, a quick toggle in sidebar, to switch exclude/hide/only modes, rather than a metatag.

Exclude/Only should simply count against tag limit. It'll make enough sense as an additional feature for gold+.

Not sure about this but would adding a default blacklist of certain tags for anons and above be too heavy on the servers?

tapnek said:

Not sure about this but would adding a default blacklist of certain tags for anons and above be too heavy on the servers?

Blacklists don't put load on the server. They're all javascript.

But removing results that are blacklisted put a load on the server, right? I guess we can go with default blacklists as a new feature then.

tapnek said:

But removing results that are blacklisted put a load on the server, right?

r0d3n7z' idea of removing blank spots could put a load on the server, yes. Would vary a lot by the specific blacklist I imagine.

Type-kun said:
Exclude/Only should simply count against tag limit. It'll make enough sense as an additional feature for gold+.

Nah, kind of defeats the purpose if it counts against tag limit. Let's say I have four individual tags blacklisted, that reduces you to 8 with blacklist:exclude on. And if you blacklist is not just individual tags but also tag combinations, it adds up even faster.

Exclude doesn't really deliver enough benefit for the cost, if it is going to have to increase server load so much. Its purpose is outright removal of blacklisted posts rather than just hiding them, so you can fill a page of search results (or subscriptions displayed on user profile page) with only posts that you care about -- this would be 'nice to have' but I don't think it's important to warrant the additional cost.

The more important use case, blacklist:show, is better and more easily dealt with client-side anyway.

r0d3n7z said:

The more important use case, blacklist:show, is better and more easily dealt with client-side anyway.

Wouldn't a sidebar button to temporarily disable blacklists be more handy, though?

Type-kun said:
Wouldn't a sidebar button to temporarily disable blacklists be more handy, though?

That'd work, just not sure how much utility the average user would get out of that, though.

Type-kun said:

Wouldn't a sidebar button to temporarily disable blacklists be more handy, though?

Or maybe a keystroke

Not much of an issue, but I thought I'd mention it: deleted comments are still counted and appear in the comment list of users, with the post thumbnail and a blank space where the text would be, which I guess only mods can now see.

Noticed it when I deleted an old comment of mine and posted a new one in post #1848669 (since editing doesn't bump).

Fred1515 said:

Not much of an issue, but I thought I'd mention it: deleted comments are still counted and appear in the comment list of users, with the post thumbnail and a blank space where the text would be, which I guess only mods can now see.

Noticed it when I deleted an old comment of mine and posted a new one in post #1848669 (since editing doesn't bump).

The fix to issue #2435 will hide the thumbnails for deleted comments.

Though I can't tell from the diffs whether you end up with fewer than the usual comments per page when there are deleted comments...

RaisingK said:

Though I can't tell from the diffs whether you end up with fewer than the usual comments per page when there are deleted comments...

It just hides them, leaving blanks on the page.

How do you fix the order of posts in a pool now as I noticed the order pool option is gone now. Do we have to manually change the order in the big number listing instead of the old interface?

Zelinkokitsune said:

How do you fix the order of posts in a pool now as I noticed the order pool option is gone now. Do we have to manually change the order in the big number listing instead of the old interface?

The order link doesn't appear for pools that have more than 100 posts.

Just noticed Danbooru now counts how many times a post has been viewed, which is cool and something I've been wishing for. There's also now a data-views item between data-score and data-favcount on all of the article.post-preview elements on search pages, but it doesn't actually show a number.
I'd like to be able to see a post's view count without incrementing it; could that be added to the thumbnail tooltip? Also, perhaps the view count shouldn't increment when a user views their own post.

hemoglobin said:

I'd like to be able to see a post's view count without incrementing it; could that be added to the thumbnail tooltip?

this page has it in the tooltip http://danbooru.donmai.us/explore/posts/popular_view

Toks said:
this page has it in the tooltip http://danbooru.donmai.us/explore/posts/popular_view

So since views can already be used like this, I'm guessing we'll be seeing an order:viewcount metatag eventually?