I'm planning on finally upgrading this site to the new code on February 16, 2013. This site will run in read only mode during the migration period (which should last a day) and after some testing (another day) I'll flip the switch and make the new site live.
If you haven't paid much attention to Danbooru 2, I've scaled back most of my more loftier ambitions and the new site is much closer to what we have now. You can kick the tires and give it a run at http://testbooru.donmai.us.
This is super late but could you add a second sort when you do a sort by count on the tag list?
Currently if you sort by count it sorts by count then if you change pages it reshuffles those. If it sorted by count then alphabetically it would overcome this issue.
If it's too tricky to implement that's fine but it would would be a significant improvement for the few people who sort by count.
There are several issues with Danbooru 2 that weren't resolved back when it still was in an active development/refinement phase. Should we bring them now or wait for the deployment of the new version?
Also, is it better to write about them here or make a new "issue" at Github, or maybe both?
I consider the current list of open bugs on Github to be minor enough to wait after deployment. If there are any in particular that you think should be prioritized post about them here.
It's pretty hard to judge if things are working, when the majority of samples and thumbs are missing. At the very least, the flash thumbnails are all broken, ditto for some samples of posts which *do* have data, such as this one.
One immediately-striking regression is the paginator. Bring back the prev/next page ([<<] and [>>]) buttons, and unless it's a gigantic win for the DB performance (which I submit we won't be able to judge until after the real-life deployment anyway), the buttons for last pages too.
Next page located in a stable position with a fixed, page-unique text is incredibly important for fast, keyboard- and muscle memory-friendly navigation.
Knowing how many pages of results there are is quintessential for any kind of serious moderation or tagging work, and I can't imagine working without knowing whether I'm facing 5 or 500 pages of work. Since the current codebase can handle paginating-until-end, the new one should be able to as well, or if it can't, then it's simply not ready for deployment. Mystery meat moderation will result in a dramatic drop in the volume and quality of tagging work, because it means we won't be able to judge whether queries are tight enough, and whether we simply can spend enough time and energy to do X, and you want to start from the last page if you do. It will also make it next to impossible to discuss any non-trivial tagging change, because judging the impact of any multiple-tag scenario is not longer viable. Caching performance as mentioned in bug 332 is a nice goal, but things being fast will be useless if tagging is too painful to do.
i support the page browsing system to remain the same as well. like the japanese letter person said (stuck on my wii, can't copy/paste -_-), it makes tagging easier. i wouldn't bother with tagging and tag clean up at all if i didn't know what i was in for in terms of page numbers.
also, i couldn't find where to make pools so i'll ask here, will users be able to delete pools that they made or will pool deletion remain mod and up only? i think it was at one point users could delete their own and janitors could delete pools though im not 100% on the last one.
Edit: thank you log. I remembered some some complaining about that a while back but i didn't know if that was resolved or not. appearantly its still going.
The Testbooru server has a limited amount of disk space so I couldn't copy over every image. It's sufficient to know that it works for 100 or so.
I can add the arrows back.
The last page link currently doesn't even work for tags with 1,000+ pages (or 20,000 posts). I'm assuming people don't care about large searches like this. What are the search sizes people are working with? 10 pages? 50? 100? In any case I still consider this a minor view change and I can handle it after deployment.
Being able to know how many results you got for your search is too useful to be left out of the UI.
A little note that tells me how many posts are in the list I'm looking, above or below the search bar depending on space, would give us everything we needed.
Optionally, a "last page" button on the end of the page numbers would help make the UI feel more complete. If the issue with displaying a link to the last page is generating the last page, then this saves the database calculating the page every search.
albert said: The last page link currently doesn't even work for tags with 1,000+ pages (or 20,000 posts). I'm assuming people don't care about large searches like this. What are the search sizes people are working with? 10 pages? 50? 100? In any case I still consider this a minor view change and I can handle it after deployment.
If it's above the size the paginator cuts off at, it's entirely reasonable to remove the link, it won't be useful anyway. Otherwise, there's no good limit, because different things are "searches people work with" at different times. If I'm doing a quick fix, >10 pages might be too much for me to be able to do it during my morning coffee. If I'm judging the impact of a tagging change, 100 might be "alright" but 300 "too much", and I need to know these sizes. And in several instances, we've actually had brave souls go through 500+ pages of results and retag/review things. The limit of 1000 is already a natural boundary, and introducing ones below that will be harmful to important work.
Serlo said: Optionally, a "last page" button on the end of the page numbers would help make the UI feel more complete. If the issue with displaying a link to the last page is generating the last page, then this saves the database calculating the page every search.
It's all about knowing the number of pages, and if the DB counts until the last page, getting numbers before that is free. So that wouldn't be a real fix for either the DB or the UI.
EDIT: artists.xml seemed to be responding, but how to you access the artist's url fields which seemed to be missing?
EDIT2: since github is accessible again, i was reminded the correct way of accessing notes and comments were notes.xml?group_by=note and comments.xml?group_by=comment respectively. however, how to access the wiki and correct way of accessing the artist api parameters (urls)?
Question : is there any system to be implemented in Danbooru2 preventing users from uploading prohibited artists or just giving them a hint that it's a prohibited one before they upload such piece of artwork ?
