Report site bugs here

@Background Pony #62CA  

Error in the Textile to Markdown converter, not the Markdown renderer. Fixed, awaiting deploy.
 
this wouldn’t have happened if we were using typespecs, maybe I should get on that

@byte[]  
So basically the converter is getting stuck in an infinite loop?

@Wiimeiser  
No, it was just a matching error. You can read the changelog if you’re interested.

Isn’t the tagging system supposed to automatically reject uploads which include artist:___ tags for artists who are on the DNP, or am I misremembering that?

@TexasUberAlles  
Both artworks you showed were initially uploaded without an artist tag.

@Princess Celestia  
Ah, that makes sense. It’s not the first time recently I’ve seen her art uploaded here despite the DNP, so I was concerned that something might have gotten borked in the shift to Markdown.

Re: Login button not working in Firefox
 
I haven’t figured this problem out yet, but I don’t think it’s a case of script or cookies being blocked. I can log into any other site, and I just discovered that when I save the login-independent settings on Derpi, that save button works fine. I think the problem is something with that sign in button specifically.
 
For now, I need to use Chrome to login to Derpi—and that’s all I use it for. I’ll continue looking for a solution, but if anyone else has seen this before, please share how you worked through it.

Just ran into the same cursor-over-one-link,-actually-clicked-another-link issue on a forum post, so it seems this is an issue with the site style in general, not just in the quick tagging UI.

Unfortunately, at least with my amateur knowledge of CSS, I don’t know of a way to shrink the clickable height of inline text links - I could only find that undoing the site’s global line-height: 1.15 or making a tags display:inline-block negates the overlap, both of which obviously have major side-effects…

I have been having a weird issue for the past few days where everything on the site has a weird delay before it decides to load.

From what I can tell it seems to only be on Firefox but I don’t wanna have to use a different browser just for this site since it seems only Derpi is affected by the issue.

What is happening though is that while browsing or opening up any image page or trying to download (via the button) any image there’s this weird 5-20 second delay before things decide to actually load. They load/download at expected speeds, but don’t do anything until after that odd delay. It also seems that it’s a shared delay even between tabs as well as I can open and click to download multiple images with a few second delay between each click and after that delay the download box for each pops up at the same time. Download speeds and everything like that are unaffected though so it’s not a network speed issue but something either with the site, Firefox, or Firefox’s interaction with the site.

@runner2
I’m not experiencing any issues on 92.0.1 (win10); do you have any add-ons that could be trying to interact with the site (download helpers, userscripts for styles or ponymotes, whatnot)? I’d recommend trying to disable any add-ons one by one to see if any might be failing for some reason.

@runner2
https://derpicdn.net/cdn-cgi/trace ; what is the value of colo=?

ORD is what it shows for me.

I haven’t had any other add ons enabled/disabled for several years but all I have are an ad blocker, password manager, and a video downloader. I’m not aware of any others that I really have though. Not certain why one would randomly be causing an issue now after this many years.

In the section about fuzzy matching on the search help page, the example fluttersho~0.8 links to a search for fluttersho~1.0

Also, I’m not sure the search works as described, for 0.0≤value≤1.0 - for example, actually trying the search for fluttersho~0.8 finds no results, when it says it’s supposed to match fluttershy. Similarly, on the tag search page, fluttersho~0.8 finds nothing while fluttersho~1.0 does (where 1.0 is supposed to be more strict than 0.8).

[edit] I see that I’d previously reported the text/link mismatch, along with several other errors that are still present

Just checking in to see if there’s any solution for my issue above here. Still having that hard delay on loading all images on the site and it’s becoming rather tedious to even browse on here now with the problem. Just a general search takes me almost half a minute per page to see if there’s anything of interest to me there and then another delay of up to 30 seconds to open the image before it actually loads in. Sizes of the images or videos doesn’t matter either as it’s just a sitewide delay for loading things for me overall.

@runner2
Have you been able to check if the same issue occurs on other browsers?

@The Smiling Pony
@runner2
And to add to that, other network connections? Even though you maybe don’t think it’s a network issue, it is still possible there is some sort of throttling going on.

Other sites and booru’s work fine and as expected. Like I mentioned before though I tried it on Microsoft Edge on the same computer without the issue. It’s something specifically with Firefox that seems to cause this issue. It’s not as if they are loading up slowly or anything, it’s that they don’t load at all for X amount of seconds and then load in as normal after that. It’s the same when downloading images as well. Clicking on the download button causes an indicator of it loading but does nothing for a while before actually popping up the download window for me. Trying this with different image tabs with a small delay on each results in them doing nothing for a while and then the download windows for each tab pops in nearly all at once as if there’s some sort of timer active for all of this going on.

@runner2
Can you try in a private Firefox window? That should disable add-ons, unless they were specifically set to run in private mode. As well, is Firefox using custom network settings? FF can be set to use a proxy separately from any proxy defined by the OS (which others browsers will use).

As is, what your experiencing can’t be reproduced by others with latest Firefox, so we need your help eliminating possible causes and identifying what separates your set up from the average / default.

Alright then. I initially tried the private window with the same issue. I wasn’t aware Firefox had built in network settings but after finding it, it showed that auto detect proxy settings for this network was checked. Toward the bottom of that window was a checked box for “Enable DNS over HTTPS”. After unchecking that one box it seems to have fixed the issue for me. Images are now popping in almost instantly now as they should so I’m not certain if the last Firefox update enabled that or if something with the recent markdown thing on the site caused some sort of conflict with it but it works as it should now after disabling that.

No clue overall with that one, but thank you for directing me to peek at settings I didn’t know I had. :P

@runner2
Aha! Glad to see things working now.

The culprit would likely be the Lets Encrypt certificate expiry, then. Whichever DNS service you* had selected there probably was likely out of date or having some other issue; you can check some recent news articles regarding “lets encrypt” about the issue. For Cloudflare, at least, it works (on my end). Unfortunate coincidence that the timing (6-7 days ago) coincided closely with the Markdown stuff.

It seems there has just been some kind of website slowdown in that some images needed to wait over 10 minutes before their miniatures were generated. All seems to be good now.

Perhaps not a bug, but what I think might be a methodological shortcoming:

If I’m interpreting the relevant code correctly, the reported average report time-to-close has a chance to omit reports that take an unusually long time to close: because it’s sorted by created_at, a report that is not closed by the time 250 newer reports are closed will never factor in. Granted, that’s pretty unlikely considering Derpibooru got about 310 reports in the past 12 days (archive.org).

It seems to me that a more complete measure would be to instead take the newest 250 closed reports sorted by updated_at, and rephrase the statistic as “On the last 250 reports we’ve closed”.

I think there’s a bug with the SVG uploads, none work currently.