DeckPackerPiefed just got a new "community theme" option, feel free to get creative with it!
lumpenproletariatThis is awesome.
Is there a user option to override it and continue to use the users theme?
Also do themes have to be added to the codeberg? If an admin uploads it directly for their instances directory would that work, and would browsing that from a different instance load it or would they also need the theme in their files?
Yeah, unfortunately it will only work for people, that have the theme in their files, so you would have to propose it to the repo.
This is mainly because of security concerns, because there are a lot of ways to inject malicious Javascript code into a theme, and we don’t want that federating across piefed.
That’s a fair enough reason. Shame it has to be that way, hope it doesn’t lead to bloat with hundreds/thousands of community themes.
LinkThere are a lot of ways to inject javascript into css aswell, unfortunately. With @import, if you just escape css with </style> and so many more. It would be a herculean task to really sanitize css so it’s fully safe unfortunately and if we were to make any mistake, that would pose a massive security risk for our users.
So maybe it’s possible, but I am afraid, that it’s beyond the scope of our project.
And, to your other question, yeah, there is an option in the user settings to disable community themes.
I remember Reddit had a little tick box for each community? There was a benefit to blocking some obnoxious ones but keeping good ones, might be something to look into for a future update.
Yeah, that’s a good idea, I’ll try to implement that in a future update.
wjs018To do this on a per-community basis, it might make sense to store it in the session cookie rather than in the db. Look for instances of response.set_cookie and request.cookies.get to see other examples of where we do that.
Some user settings are stored in the cookie to look at as an example; stuff like the compactness level, low bandwidth mode, etc. Basically anything that is set on a per-device basis rather than stored in the db.
Disabling a particularly annoying theme seems to me like something you would wanna do on every device, no?
Maybey it would make sense to store the user theme in a cookie though, because that is a thing, you may want to be different on different types of devices.
Do you know, how long such a cookie lasts?
My thinking on a per-device basis was that themes might work better/worse in a mobile vs. desktop browser, so people might prefer different experiences, but I could see the other side of things as well. That was also the rationale for making compact mode be in the cookie rather than saved in the db.
I honestly don’t know what the expiration of the session cookie is. It might depend on the browser. I think it is pretty long-lasting unless people clear their cache because I have definitely loaded up piefed instances after a long time and have still been logged in.
As for technical details, to save space, it might make sense to make a key (maybe like ignore_comm_theme) be a comma-separated list of community id’s that people have unchecked the box. That means you can easily convert this to a list with split and then see if the currently requested community id is in that list. Being the id means that it is unique for the instance and avoids name collisions like the actual community name might have (how many linux communities do we have now). It also keeps things relatively small since the cookie has a pretty small size limit iirc.