Posted under General
This topic has been locked.
So people need to pay to skip pages now? Is this really the direction the website's gonna take? Needing a gold account for a bare browsing functionality?
This is getting stupid. You may get a couple people to actually pay for it, but I feel like it will mostly result in people quitting this website, tired of dealing with these ridiculous limitations, who will browse instead some other, more reasonable, website such as Gelbooru.
@sequential pagination
don't know if it's a bug but old pagination still works. just append "?page=$pageNo" to the url where $pageNo is the page of interest. tested in anonymous mode.
example: page 10
ghostrigger said:
@sequential pagination
don't know if it's a bug but old pagination still works. just append "?page=$pageNo" to the url where $pageNo is the page of interest. tested in anonymous mode.example: page 10
Intended, I think. Queries having "order:" clauses will be using regular pagination once fixed, anyway, and gold+ use regular pagination. Technically, it's possible to write a userscript that brings back regular pagination.
Anyway, this should probably have been discussed beforehand. Even github commit comment didn't indicate the changes, it was supposed to kill post count queries for pages that don't require paginators like atom feeds or api.
Still, I think it's possible to integrate sequential paginator with regular pagination for queries besides "order:". Most of time people browse pages sequentially. So, if user is for example on page 3, where first post on page is #900000 and last is #800000, then we could add additional parameter to links to page 2 and 4. Link to 2 would be "page=2&spage=a900000" and 4 would be "page=4&spage=b800000". When danbooru encounters such link, it would use page number for display only, and actually use post number to build next page contents. If user decides to browse to page 5, the old-style query happens, but links to page 6 and page 4 will have "spage" argument so queries would be faster.
What this solution doesn't address is that sequential paging gets rid of count query which times out most often, loads the server incredibly and which is used only to get total page count. It is supposed to be cached, but turns out there was a bug and it didn't work at all - see issue #2439. Perhaps it will be easier on the database now that it's fixed and albert will revert changes. Another way is to always assume there's 4 more pages unless precise count is stored. This will cut the load, give back regular pagination, but will result in the possibility of "blank" pages.
tl;dr this needs thorough discussion, please don't start a flamewar beforehand.
order:score_asc is broken. Clicking "Next" at the bottom doesn't go to the next page of results but just shows a page of posts from the main listings. Probably applies to the other metatags.
tapnek said:
order:score_asc is broken. Clicking "Next" at the bottom doesn't go to the next page of results but just shows a page of posts from the main listings. Probably applies to the other metatags.
It applies to searches with nonstandard order. Type-kun mentioned it on the last page.
albert said:
Numbers should be back although there may be weird bugs with timeouts triggering the sequential paginator. I'll suss those out in the coming days.
Still not showing up for me on all searches. Should I delete cookies?
Notable searches not having the numbers back. Frontpage and touhou.
Updated
theadonicus said:
Is uploading still broken? I have one upload still "processing" for 12 hours
It's not know what causes this bug yet. Just reupload it and it will most likely work now.
theadonicus said:
one that's pending approval (even though I uploaded as a contributor).
You probably checked the "upload for approval" box on accident.
The webm created for post #2072395 is damaged. The original works just fine.
A few months ago I was experiencing this problem: http://danbooru.donmai.us/forum_posts/102430
Toks had posted saying it was something related to the share buttons. It had been fixed temporarily for me, but now I'm having that same issue where I'll open a post page, it will load the image, then it will freeze for up to a second. Trying to open multiple images in tabs greatly applifies the freezing.
I actually haven't been using the site very often but I did notice a couple times I used it in the last few months that this was still happening, so I don't know when the issue "unfixed" itself. If the issue is caused by the share menu, anyways I could disable it for myself since I don't share using those anyways?
Godel said:
A few months ago I was experiencing this problem: http://danbooru.donmai.us/forum_posts/102430
Toks had posted saying it was something related to the share buttons. It had been fixed temporarily for me, but now I'm having that same issue where I'll open a post page, it will load the image, then it will freeze for up to a second. Trying to open multiple images in tabs greatly applifies the freezing.
I actually haven't been using the site very often but I did notice a couple times I used it in the last few months that this was still happening, so I don't know when the issue "unfixed" itself. If the issue is caused by the share menu, anyways I could disable it for myself since I don't share using those anyways?
If it really is the share buttons, you could use an adblocker to get rid of them. I think ublock origin blocks them by default, and for adblock plus there's a custom filter somewhere that does it. Though personally I'm not experiencing the problem since the bug I talked about was fixed.
It might be a userscript you're using.
Toks said:
If it really is the share buttons, you could use an adblocker to get rid of them. I think ublock origin blocks them by default, and for adblock plus there's a custom filter somewhere that does it. Though personally I'm not experiencing the problem since the bug I talked about was fixed.
It might be a userscript you're using.
uBlock Origin ridiculously improved performance for me when I swapped to it from Adblock Plus.
Pretty sure it wasn't a user script or another extension, since I tried with basically all of them disabled.
Anyways, thanks for tip with uBlock.
Feature request, via forum #106676
buehbueh said:
But on another of your statements, I noted your statement on blanks and maybe it would be possible to have blacklisted images not show up as blank on the front page, so that they're not noticeably affecting the user experience. What do you all think? Sometimes I have to select status:active to get around blank images during searches in tags with heavy numbers of deletions, and it is annoying and needs to be addressed in some way.
I get this blanking phenomenon as well due to blacklists on a couple of copyrights. But my understanding of the current design is: the thing about blacklisted images is that you're still able to toggle them visible/hidden from the front page (or any post search results, for that matter). So the way it works now is that they are simply hidden, and the space is 'reserved' for when you choose to unhide them. Whereas with deleted images, you don't actually have any way of toggling them, if you want to see them you have to explicitly do status:deleted or status:any.
What is possible, though, I think, is to add a metatag like blacklist:exclude. This would be a great addition to enable users to explicitly, consciously exclude all blacklisted images in search results, so they don't even turn up (vs. hidden and can be toggled on). And there is one place where I think this could be the default behavior: subscriptions preview on the user profile page -- where the option to toggle blacklisted posts doesn't exist anyway, so I'd definitely rather have a full six non-blacklisted posts shown to me rather than blanks.
The current search behavior can be treated as default (blacklist:hide)
Believe it or not, blacklist:show or blacklist:only are useful too ... I have use cases where it'd be helpful, e.g. bulk tag gardening (so you don't have to worry about accidentally missing something just because it's blacklisted). Currently if I'm planning to do a large amount of tag gardening, I often either: clear my blacklist temporarily and restore it later; or make a first pass for blacklisted content (explicitly, like so: gardening1 gardening2 ~blacklisted1 ~blacklist2) and then do the rest afterward. The second approach doesn't always work (e.g. require a negation somewhere) and suffers when I hit the limit of searching up to 12 tags (yes, it occasionally happens!).
Wouldn't those metatags let people get around the tag limit? e.g. A user puts a 100-tag search into their blacklist then searches for blacklist:only, completely getting around all tag limits for all user levels.
A way to avoid this would be to count blacklisted tags against your tag limit when using blacklist:exclude/only. So if a basic member had 3 tags in their blacklist and search for blacklist:exclude/only they'd get the "too many tags" error. But if that was done, would this feature still be useful? It wouldn't let you do anything you can't already do just by typing the tags manually. Or would it still be useful even if it's just a time saver so you don't need to manually type them?
Toks said:
Wouldn't those metatags let people get around the tag limit? e.g. A user puts a 100-tag search into their blacklist then searches for blacklist:only, completely getting around all tag limits for all user levels.
Yikes, gotta admit I didn't see that loophole/exploit.
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)...
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:hide is current behavior; blacklist:show is simply the opposite i.e. blacklisted images are not initially hidden on page load (class blacklist-active is not applied) and therefore should not cost any more either. I expect blacklist:exclude incurs fairly small additional query cost for filtering and I should hope it's not exploitable like blacklist:only
Another possible solution, maybe, is to require other (non-meta) tags in the search, so you can't just exploit blacklist:only by itself -- you can only use it to restrict results, in the context of some other search. [ The reason for "non-meta" is so that you can't just combine it with an id:m..n or date or rating or whatever ] E: Nah, still exploitable with super common tags, e.g. 1girl blacklist:only or breasts blacklist:only. Just scrap blacklist:only.
Updated
