[ home ] [ site / arch ] [ pony / oat / anon ] [ rp / art ]

/site/ - Site Issues

The board for discussing site related issues, questions, concerns, and suggestions.
Name
Email
Subject
Comment
File
Flags
Password (For file deletion.)

Site maintenance in progress! Posts made now may be lost.

Ponychan-MLPchan Merger >>>/site/15219

File: 1402617587278.png (44.59 KB, 250x250, explicit.png)

Mature Dammit Userscript Skybrook!8MDcALmdno 14203

I couldn't keep the cookies or whatever that keep the mature setting set, so I went and made a userscript that does it more permanently and decisively. (Hard not to notice your browser deleting user script files). If you too can't figure out why your browser keeps treating them like session cookies and making you click Show Mature every gosh darn time, then this may be helpful to you.

It's a little weird since it runs the script from the page context, not the userscript context… easiest way to get at setSettings that I could find.

http://pastebin.com/wGy4tVyA

It doesn't break any rules I think, since installing this is a conscious effort as much as clicking the "Show Mature" button is. Just gets around buggy persistence errors.

Anonymous ## Mod 14204

Thanks you.

This is just fine, yes.

Anonymous 14304

Hey OP, could you make one of these for derpiboo.ru too?

Every day it resets to the default filter for no reason and I'm tired of having to switch the filter back whenever I want to look at some horse vaginas.

>inb4 make an account

I clear cookies on browser exit so I'd have to log in all the time

Skybrook!8MDcALmdno 14618

File: 1407314590634.png (1.63 MB, 879x1300, 277843__safe_solo_rainbow+dash…)

>>14304

Derpibooru is extremely hostile in their website design. They use jQuery as a way to confuse just what a piece of code is doing, and also obfuscate all their code scrambling variable names, removing whitespace, etc. Their code has no interface, and exposes no (legible) variables, as much as possible out of reach of any userscript (or other script for that matter).

The vast majority of all the code of their website does nothing but attempt to confuse anyone as to what the rest of the code actually does. This allows them to, for instance, disable the downvote button for people not willing to view the thumbnails of diaper fetish pictures, and show a message chiding you for attempting to downvote it. They try really hard to make sure nobody is in-the-know enough to be able to change that.

They regularly change their code too, randomizing all the obfuscated variable names, and rearranging everything possible into a different order. That's why you see a link to application-8ee2b09edeb44db21308d5ee05295a26.js and not just application.js.

They're one of the hardest sites to write userscripts for. Whoever is coding the thing should be dragged out into the street and shot. Along with whoever is programming Google Docs.

Not saying I couldn't, but it probably wouldn't keep.

Silver Strength!TwiDasH7n2 14620

>>14618
You certainly wouldn't want a script tampering with the vote values or the tags of images en masse.

Skybrook!8MDcALmdno 14687

>>14620

I personally would not, but that doesn't make them any less jerks for making my life harder in order to stop those who do.

Scripts can only tamper with your own vote values btw. What are you going to do, change all your favorites to downvotes en-masse?

Instead of all that time they spent writing javascript obfuscation, they could have written a thing to 503 anyone who hammers the server too fast. Other than that, I don't see as they'd have any problem w/ scripting.

Macil!/5s/Techmk 14692

>>14618
>application-8ee2b09edeb44db21308d5ee05295a26.js
That's for cache-busting. The number is just a random number or maybe a hash of the file. Whenever the file changes, the number changes so that it's at a new URL, and browsers know they have to re-request it.

Skybrook!8MDcALmdno 14700

>>14692

Right, but the file changes every time they re-obfuscate it, even if they never changed anything. So they update it more often than needed, is what I'm trying to say. If they only updated when needed, then they could respect caches, no busting needed.

(really, if you're going to modify a file tons, is it too hard to say, add a last-modified header, or an expires header? oh well...)

Macil!/5s/Techmk 14701

>>14700
They do use both of those headers. The problem with the last-modified header is that a browser still has to make a round-trip to the server to know if it can still use its cached copy of the script. The problem with the Expires header is that if you update the site, you have to wait for that period of time before you know all the users have the updated version. By changing the file's URL when there's an update, they force browsers to disregard their cached copy immediately and download the new version, and then cache it as long as possible with a long Expires header. This site does the same thing.

Skybrook!8MDcALmdno 14710

>>14701

>> the problem with the Expires header is if you update like a caffeinated weasel in a bounce house you're going to have a bad time


I agree that links should support more metadata than just the URL, like modified time, but I ain't the w3 sadly. In particular it'd be nice to be able to tell the browser what referrer to use when following a link. My complaint is that they update too often, and not to improve anything. A good site shouldn't need to change its javascript every month.


Delete Post [ ]
[ home ] [ site / arch ] [ pony / oat / anon ] [ rp / art ]