an actual deployment with real fixes, this saved my entire nonexistent lineage
Posted under Bugs & Features
an actual deployment with real fixes, this saved my entire nonexistent lineage
new uploaders can now only upload at most one post per minute, until they have at least one approved upload
Finally, the new-user limitation I've yearned for.
news updates are now soft-deleted and their expiration date is customizable
Pardon? What news updates? Are those the tiny banners at the top of the site sometimes?
baconmeh2 said:
news updates are now soft-deleted and their expiration date is customizablePardon? What news updates? Are those the tiny banners at the top of the site sometimes?
Yeah. It used to be that they ran for 2 weeks and if you wanted to stop them earlier you had to delete them permanently. It was a huge pain with raffles.
Updated by nonamethanks
new uploaders can now only upload at most one post per minute, until they have at least one approved upload
You could probably increase the cooldown to like, 2 or 3 minutes and get away with it. If you're a newb it encourages more thorough tagging while the timer winds down, and if you're a troll its an additional annoyance.
baconmeh2 said:
I only just realized- What's to stop a user from opening multiple browsers and logging in on all of them to spam a bunch from different accounts?
Probably nothing aside from their own like, conscience or diligence or whatever. you'd hope after a certain point that trolls would realize an endeavor isn't worth it and go take a walk outside or do something actually productive with their time I don't think there's an IP-ban system in place for danbooru but I know there is a way for admins to check the IP addresses of accounts.
I just noticed one of my saved searches has been frozen for at least 30 days now (there have been posts for the query since), is there anyway I can force it to refresh?
Update: I tried changing the labels to see if it helped. No luck. Fully re-creating the saved search also didn't fix it.
The query is simply: "narmaya_(granblue_fantasy)"
Updated by Meeplee
Saved searches are kind of a wonky garbage feature, though I don't see anything out of the ordinary when I try. I saved narmaya_(granblue_fantasy) with the label "savedtest" and put "search:savedtest" into the search bar to return the posts. I'm not sure how you're accessing it where it causes a freeze.
WRS said:
Saved searches are kind of a wonky garbage feature, though I don't see anything out of the ordinary when I try. I saved
narmaya_(granblue_fantasy)with the label "savedtest" and put "search:savedtest" into the search bar to return the posts. I'm not sure how you're accessing it where it causes a freeze.
I just access my searches through the "Saved Searches" button that appears on the website header. I have 60ish searches saved and that's the only one that's frozen. Not doing anything different for this one.
Edit 1: Tried again, same query, different label with just "testing", still stuck.
Edit 2: I fixed it temporarily by changing the query to exclude an unrelated tag, so now it refreshes properly. I'm guess there's some caching problem with the old one. I'll give it a few days to clear and then maybe try restoring it to see what happens.
Updated by Meeplee
Bug: Starting a line with a spoiler makes the spoiler a block element instead of inline. I had this problem with an artist commentary and made it work by adding a zero-width space to the start of the line but I didn't feel good about that.
It happens in comments and forum posts too. Just needs to be the very first line or after a blank line. It looks like any time a spoiler starts at the same time as a <p> tag, the spoiler goes outside it as a div instead of inside it as a span.
Example:
There should be no line break before
the rest of this sentence.
There's a zero width space before this spoiler which is an unpleasant workaround.
If there's a non-blank line preceding it also works fine.
Super_Affection said:
Bug: Starting a line with a spoiler makes the spoiler a block element instead of inline. I had this problem with an artist commentary and made it work by adding a zero-width space to the start of the line but I didn't feel good about that.
It happens in comments and forum posts too. Just needs to be the very first line or after a blank line. It looks like any time a spoiler starts at the same time as a
<p>tag, the spoiler goes outside it as a div instead of inside it as a span.
This is by design. All combination tags which support both inline and block mode ([tn], [spoiler], [code], [nodtext]) are considered block tags when they are at the beginning of a line. Inline mode for these tags only begins when they are positioned beyond the beginning of the line. For myself, when I need to place one of the quasi-tags at the beginning of a line and have them treated as inline, I'll just put a NOP tag combination using one of the inline-only tags, like a [b][/b] at the beginning of a line.
Admittedly, there should be a better way to do this, like an implicit marker that shows that the intent is to use one of those quasi tags using inline mode when at the beginning of a line, rather than using something that looks funny or is hidden, which carries with it the risk having some other user inadvertently deleting it and then messing up the format of the dtext.
On a side note, I'm also forced to use the [b][/b] method when doing other things that trigger when they're at the beginning of a line but you don't want them to, like having an actual asterisk instead of a list item. Unfortunately, [nodtext] would be perfect for this, but it's one of those quasi-tags that get messed up when they're at the beginning of the line as well, which leaves me having to the use the NOP tags like I've already discussed.
BrokenEagle98 said:
Admittedly, there should be a better way to do this, like an implicit marker that shows that the intent is to use one of those quasi tags using inline mode when at the beginning of a line, rather than using something that looks funny or is hidden, which carries with it the risk having some other user inadvertently deleting it and then messing up the format of the dtext.
I believe you can also work around it by just... adding a regular space at the beginning of a line? Because the danbooru parser doesn't trim whitespace at the beginning or ends of lines for better and for worse.
[spoiler]this is a block mode spoiler[/spoiler] but [spoiler]this is not a block mode spoiler[/spoiler]
results in:
this is a block mode spoiler
but
this is not a block mode spoiler
This also works for other things, like keeping asterisks at the starts of new lines instead of making a bulleted list.
* Like this.
Alright, in terms of bugs—I've noticed within the last day or so that when refreshing a search on mobile my blacklist toggle vanishes. Like when I first load a page with blacklisted posts (usually via pagination) it's there no problem, but then when I refresh it to update it the toggle poofs out of existence. The blacklisted posts are still hidden on my end, but the ability to have them re-appear is just… kaput. I can make them reappear by paginating back and forth again, but this just feels wack, especially since I don't have this problem on desktop.
Ylimegirl said:
I believe you can also work around it by just... adding a regular space at the beginning of a line? Because the danbooru parser doesn't trim whitespace at the beginning or ends of lines for better and for worse.
Danbooru does trim spaces at the beginning of the commentary or end of the commentary though when it gets saved (the preview will be incorrect). So if you need to use one of those quasi tags as inline for the very first item, then there is no other way than to use a zero-width space or a NOP tag. It only seems to do this for commentaries though, as it doesn't do it for forum posts or comments.
Also, I don't know if something recently changed with the CSS, but in the past if you put a space in front of the asterisk, the asterisk would be inset due to that space. But that no longer seems to be the case?
Iroshi2020qsound said:
Lofter artist entries are now automatically created with a "permanent inner ID redirect" URL, like Twitter entries. This did not happen before. When exactly was this implemented?
Brightlight said:
Thank you !
Made BUR validation errors display in a more sensible and user-friendly way (see pull #5965 for visual examples)
thank you github coders ilove you