Danbooru

Danbooru 2 Issues Topic

Posted under General

This topic has been locked.

Site update (2017.06.23 - 2017.07.11)
Changes
  • Wiki pages and artist entries show the list of recent posts under that tag.
  • Disallowed creation of redundant implications. If we already have a -> b -> c, then don't allow requesting a -> c.
  • The artist commentary versions listing now shows thumbnails and properly formats commentaries as DText.
Uploading
  • The batch upload bookmarklet now shows a thumbnail preview of every image in the gallery you're uploading.
  • Added Tumblr support:
    • Tags are fetched.
    • Commentary is fetched.
    • Uploading via the HTML page (e.g. http://kuvshinov-ilya.tumblr.com/post/162863747905) now works. You can either use the bookmarklet on the HTML page, or you can put the HTML page in the Source field on the upload page to have it download the image.
  • Twitter: fixed the upload page uploading the :large image instead of the :orig image for certain tweets.
Post replacements
  • Posts below post #1000000 can be replaced.
  • Added a Tags field to the replacement dialog. This lets you remove tags at the same time as you replace the image.
  • Save the image URL as the replacement URL, not the HTML page URL.
  • Fixed broken source links in the post replacements listing.
  • Fixed thumbnails of deleted posts not showing in the post replacements listing.
Notes
  • Make note ID links in the notes listing take you directly to the note inside the post.
  • Added "»" links that open the full history of a given note.
Fixes
  • Fixed translated tags suggesting certain bad tags, most notably photoshop and sai for Pixiv posts.
  • Fixed multiple pages unnecessarily denying access to logged-out users / users without accounts. Most notably, the "?" link next to artist tags now works.
  • Fixed banned users not being able to read dmails, edit account settings, or manage saved searches or API keys.
  • Fixed missing blacklist controls on multiple pages.
  • Possibly fixed the bug with the post flags listing sometimes showing everyone's flags instead of your own when searching for your own flags.
  • Approving posts in the modqueue properly hides the post when the approval fails because someone else approved it first.

Full changelog: https://github.com/r888888888/danbooru/compare/production-2017.06.23-210758-utc...production-2017.07.11-000708-utc

Unbreakable said:

I can see 10 posts on the bottom of the page you linked to.

Ah... freak... this is related to issue #3121 and the CSS I developed in forum #132142. Basically, if there are no blacklist controls, than that CSS will keep all posts hidden. I'll add another exception for that like I did the other two pages I found until that issue gets resolved for the artist page as well.

Edit:

Added the artist page to issue #3121.

Updated

Seems like the latest post expunge wave (ricegnat case) has corrupted some post relations:

Example:

post #2512784 + screenshot (NSFW):

{
	"id": 2512784,
	"parent_id": null,
	"has_children": false,
	"has_visible_children": false,
	"children_ids": null,
}

post #2512800 + screenshot (NSFW):

{
	"id": 2512800,
	"parent_id": 2512784,
	"has_children": false,
	"has_visible_children": false,
	"children_ids": null,
}

Noticed this while trying to find out which of my favorites have been expunged. Q_Q

reiyasona said:

Seems like the latest post expunge wave (ricegnat case) has corrupted some post relations:

issue #3229. When a parent post is expunged, the children are reparented to the first child, but due to a bug the has_children flag wasn't set for this new parent. I resaved the post to reset the flag.

I just noticed that some of the images and their thumbnails are missing in a few of my posts. These were all from the same artist (Matilda Vin, not a banned artist), and each deleted image sample post was parented to its active post. There were tumblr uploads that had undergone successful image replacement about a month ago. Is this a bug or related to the recent expunge?

The posts affected by this, ordered by date, are:

post #2763625 (deleted)
post #2763618 (deleted)
post #2763617 (deleted)
post #2756839 (active)
post #2756837 (active)
post #2646013 (active)

These are the only posts I am aware of, but I wouldn't be surprised if there are more that are affected.

It's a replacement bug. By the time the scheduled deletions of the replaced files went through a month later, the files were in use again by other posts and so shouldn't have been deleted. There is a safeguard to prevent this, but a bug prevented it from working.

edit: issue #3235.

Updated

Not really an issue per se, but after like the twentieth time, it'd be nice if, when an artist's name arbitrarily changes, the old name could be aliased to the new, thanks much. Life would be easier without spending minutes fumbling around trying to find the artist's new name when all you have is the old one, especially in regards to scans and 3rd-party sources such as dengekionline.

CodeKyuubi said:

Not really an issue per se, but after like the twentieth time, it'd be nice if, when an artist's name arbitrarily changes, the old name could be aliased to the new, thanks much. Life would be easier without spending minutes fumbling around trying to find the artist's new name when all you have is the old one, especially in regards to scans and 3rd-party sources such as dengekionline.

I always make it a habit to include the old name in the other names list -- Try searching your old artist names there and it should work.

Aliases for artists take exceedingly long to go through, so a number of contributors have set their sights on just manually updating them accordingly, as most of them aren't worth the cost for a move, especially when the artist tag is wrongly named to begin with.

Mikaeri said:

I always make it a habit to include the old name in the other names list...

That's a great idea... I'm going to start doing that from now on.

Aliases for artists take exceedingly long to go through...

Not to mention the disallowance of alias chaining. So if A->B already exists from a previous artist update, and the artist name changes to C, you'd have to first unalias A->B before setting up the alias for B->C. Basically, it's a royal PITA, which is why not many contributors bother with it.

BrokenEagle98 said:

Not to mention the disallowance of alias chaining. So if A->B already exists from a previous artist update, and the artist name changes to C, you'd have to first unalias A->B before setting up the alias for B->C. Basically, it's a royal PITA, which is why not many contributors bother with it.

Exactly. And if the alias points in the wrong direction to begin with, then we're basically sitting like ducks waiting for an Admin to respond to it.

I get the nagging feeling that issuing these aliases used to be a more regular thing, but then it took a backseat as we started not being able to trust the proposals some users came up with. For one thing, there are artists that have names so ubiquitous that they deserve the unqualified name (at least, in my opinion), but instead those names were taken up by no-name entries that have only ever had one post attributed to them and/or the lack of an artist entry to accomodate, so it's hard to find them to begin with.

In a few days, perhaps, I'll be proposing a huge revision to howto:artist to be up to date with how artists currently update all their personal sites and webpages, how to read and romanize names, how to pick good names (with a list of priority, accordingly), and also which URLs should be up to date and which shouldn't (as a number of Twitter/blog links are sometimes incorrect due to the case anyone can swoop in to grab an old handle/domain/etc). I'll try to write it as I did a number of the other howto pages, so instead of having it be an unappealing word sandwich, I'll see if I can rewrite things to be as concise and easy to understand as possible.