Report site bugs here

Came across this while working on a userscript…
 
If you view this webm >>1719848 at full resolution and inspect the video <source> elements, you’ll note the one that’s supposed to point to the mp4 version instead shows src="//derpicdn.net/img/view/2018/4/29/1719848__safe_screencap_twilight+sparkle_horse+play_spoiler-colon-s08e07_alicorn_animated_sound_twilight+sparkle+%28alicorn%29_mp4.webm".
 
This happens because the function handling image scaling uses replace('webm', 'mp4') on the webm source to derive the mp4 version, and the substring ‘webm’ already exists as part of the filename for this particular video (..._twilight+sparkle+%28alicorn%29_webm.webm).
 
While this should not affect the majority of the users under most circumstances, the bug will manifest and cause display issues when these conditions are met:  

@Marker  
Thanks for the detailed report, the fix does seem to be that simple. It will be live after the next deploy.

I am not sure if it has something to do with the error that damages some images or it is a purge in some categories, but today note that, for example in the foalcon category , were deleted more than 100 images of a day to another, what happened?  
For your attention thanks

@Background Pony #4A54  
An artist asked for all their work to be taken down. Many of the images you had favorited were hit by that.

@Derpy Whooves  
Who was it DNPed themselves, so we know not to upload anything of theirs?

@TexasUberAlles  
A couple new DNPs appear every week on average, so it’s really better if you check the artist before uploading.

Why does the onion service require login?

@Background Pony #7F5D  
Abuse

I got notified of my own post just now. Not sure if anyone else has this, if I need a screenshot, or what…

@Zaknel  
Happens pretty frequently if you’re posting as anon, though the notification system has been known to have a stroke from time to time.

Not sure if this has been reported yet. This has to do with advanced search paramaters.
 
When you search something like (twilight sparkle OR rainbow dash) AND canterlot, then view an image, then hit the Random Image button (the one that gives you a random image based on your current search), your search will be misinterpreted as * and the next image will be completely random.
 
This occurs with any search where the first part of the search paramaters is in brackets. In the meantime, the bug is circumvented easily by prefixing your search with * AND, so that would make my example become * AND (twilight sparkle OR rainbow dash) AND canterlot. The other solution (only applies if your search contains a tag that isn’t wrapped in brackets) is to put an unbracketed tag at the start of your search.
 
EDIT: It may also just be my imagination, but it seems with complex searches like this, random image doesn’t display a true random image. I was just searching with these options and I received the same image about 3 or 4 times in a row, despite the search returning over 2000 results. The odds of that happening are 1/1 x 1/2000 x 1/2000 roughly which equate to an absurdly low chance of getting the same image 3x in a row amongst thousands if picked randomly (google has it at 1 in 2.5e-7)
 
EDIT 2: Double checked. It appears search is still misinterpeting the search * AND (twilight sparkle OR rainbow dash) AND canterlot. While this isn’t the exact search I’m using because NSFW reasons, the search I am using (if put in sfw equivilent) is being interpreted as * AND twilight sparkle AND rainbow dash AND canterlot because when I have a window with this search on my other monitor, and randomize in the window with the original search, the images I’m randomly getting are all in the search on my other monitor.

@Background Pony #22E5  
Random is also still not working for galleries. EDIT: Seems to have been fixed at some point. Don’t know if that’s what broke this or anything…

@Wiimeiser  
I think that the issue’s origin is in the search feature. It appears it doesn’t correctly utilize brackets and random uses this faulty search in a specific way. This is pure speculation because I don’t have access to the source code to verify my theory, but it seems the most logical conclusion to come to.

@Background Pony #22E5  
I was more thinking of when it broke, assuming it had ever worked previously…

 
Tested with canterlot AND [(twilight sparkle OR rainbow dash)], works fine, lol  
Welp, random crashes when first tag or expression is in brakes.  
rd || ts — works  
(rd) — nope  
-rd — works  
rd || ts && fs — works

I’m getting notifications for my own comments now, and I can’t tell if it’s a bug or a new feature.

@EyeGuy  
It’s a bug.

@Psy Key  
@EyeGuy  
Pointed it out a while ago.

@Zaknel  
I pointed it out before you. Scroll.

@Zaknel  
If anyone else pointed it out yet, then I’m sorry for being too lazy to look through the whole thread.

@EyeGuy  
It’s alright. Our instinct is to tell the technical team about a problem promptly. Nothing wrong with that. At least, not for me.

@byte[]  
“Abuse” is not an answer.

@Background Pony #7F5D  
Abuse of the service by unauthenticated users - meaning denial of service
 
Happy?

@Background Pony #7F5D  
Like any decently-sized community site on the Internet, we see our fair share of trolls, spammers, shitposters, etc. And because of the nature of how TOR works, IP banning TOR users isn’t exactly possible. And of course, a few people took advantage of that fact, so we require accounts for anyone accessing the site via the .onion address, simply so that if someone starts causing trouble we can just ban the account.
 
Basically, it’s just another case of “somebody had to go and ruin it for everybody”.

FYI: for nearly 2 months (late February to late April) anonymous Tor users could not access Derpibooru, because google refused to show captcha to them on the cloudflare “One more step” page and the onion service requires login.
 
@Blossomforth