Interesting discovery for sure. I'm specifically using strip_tags() currently but decided to just try swapping htmlspecialchars() in which does fix the submission you linked. The problem is that it then breaks instances where potentially formatted text is displayed without formatting by displaying the HTML instead of just removing the tags. That's not the end of the world and I'm content to leave it for now but definitely keep an eye out for any odd display issues.

Yeah, I think you've caused a problem now. For example, the title at https://www.sounds-resource.com/pc_compu...xpansions/.

Edit: Though I'm not quite sure how you're managing this. "&" turns into "&" in the HTML. Some double-escaping is going on?

That was because I forgot to take out the explicit search for & which I was replacing with & manually. That replacement was running first and then htmlspecialchars() was replacing the & in & with another &.

Thanks for pointing that out! Should be good now.

We could do with some sort of limit on the resolution of sheets to avoid devices running out of memory. Currently in the Discord chat two people have tried to load a sheet on their computers without success, and on mobile I certainly didn't have any luck. On PC it seemed fine for me - this particular sheet is only 381MB as raw pixel data, though it uses quite a bit more in memory in reality.

I don't know what the limit should be - maybe 25MP? Regardless, it only seems fair to ensure that people on mobile or low-end PCs can view all the sheets.

We don't typically upload or approve enormous sheets these days but there are probably plenty of old ones still floating around. What's the sheet in question in this case? Because 381 MB shouldn't have even been possible.

381MB decompressed in order to be viewed or edited by everything that takes the "load the entire image into memory" approach - not the actual download size. It was https://www.spriters-resource.com/mobile...eet/78857/.

It seems to load fine on my iPhone but I can definitely see why an image that large could be problematic. As expected though, looking at the ID of that sheet (78857), it was submitted quite a while ago (the end of April 2016 to be specific) and we have long since revised the standards we accept new submissions with. As for this one in particular, I'm not sure there's much to do about it now. It's been on the site for over three years and is a good rip barring the loading issues some might experience.

The ability to click and search sections would be a tremendous help and make finding particular items a lot more easier.

Can you elaborate a bit?

Hey necrobump time

I was thinking for the resource site's Christmas themes, we combine the "old" and "modern designs". The old design just uses christmas lights around the boarders of the sheet, and the modern design uses the little santa and snowman overlay. Combining both elements would surprisingly make for a decent holiday UI.

(Example) https://web.archive.org/web/201412161633...com:80/nes

We were actually never crazy about those lights which is why they didn’t make it into the revision of the Christmas theme you see now. We did add a bunch of other things as well as cleaned up the background to be more in line with the site though and I definitely prefer this new version.

It would be more user-friendly if logging in on the websites returned the user to the page s/he was previously viewing.

The websites frequently log me out due to third-party cookie preferences and it's annoying being redirected to the homepage after logging in to leave a comment or something.

The login page already has this flexibility - it just needs to be passed the proper address. The login page always appends a trailing slash to the return redirect, which I'd personally do away with to avoid a bit of headache, but you wouldn't have to do away with it.

If you are willing to make the login page not append a slash on the return redirect, you can achieve this functionality by sticking something like this after where the Spriters etc. pages spit out the current login path:
...or something like this if you'd rather leave the login page alone:

Also, I don't know what sort of hosting you have, but if you can enable HTTP/2 that could help pages with many resources a fair bit performance-wise, especially on high-latency connections. Just thinking of those pages that have hundreds of sheet icons.

(01-21-2020, 01:47 PM)Simpsons Dumper Wrote: It would be more user-friendly if logging in on the websites returned the user to the page s/he was previously viewing.

The websites frequently log me out due to third-party cookie preferences and it's annoying being redirected to the homepage after logging in to leave a comment or something.

The login page already has this flexibility - it just needs to be passed the proper address. The login page always appends a trailing slash to the return redirect, which I'd personally do away with to avoid a bit of headache, but you wouldn't have to do away with it.

If you are willing to make the login page not append a slash on the return redirect, you can achieve this functionality by sticking something like this after where the Spriters etc. pages spit out the current login path:

PHP Code:

echo ($_SERVER['PHP_SELF'] != '/index.php') ? $_SERVER['PHP_SELF'] : '/'; 


...or something like this if you'd rather leave the login page alone:

PHP Code:

if ($_SERVER['PHP_SELF'] != '/index.php') echo rtrim($_SERVER['PHP_SELF'], '/'); 


Also, I don't know what sort of hosting you have, but if you can enable HTTP/2 that could help pages with many resources a fair bit performance-wise, especially on high-latency connections. Just thinking of those pages that have hundreds of sheet icons.

I don't want to get into too many technical specifics here but I will answer these as well as I can without them. For the login redirect, I get what you're saying but it can't be done the way you're suggesting. I originally looked into returning to the originating page but ran into some issues and set it aside. I'm pretty sure I have a working solution for it which I'll try to add in shortly.

As for HTTP/2, again without going into specifics, I can't enable it at this time though I'd definitely like to.

Some submissions like anything to do with Sans or Grand Dad are unfortunately not immune to the meme comments, no matter how many get reported
So I was thinking, would it be possible to implement a feature that disables comments on certain submissions where their meme status is significantly high?

I don't really see that as a necessary change. Yes, the spam comments are annoying but those who post them are warned and those who continue are banned.