How do you want disabeling community themes to work?

submitted by
edited

UPDATE:
The feature is now fully implemented! It shows up as an extra option in the community sidebar and saves the result in the database (as was decided by the poll). It is not merged with main yet, but you can look at the pull request , if you are interested.

In a previous post , I talked about the new community themes feature.

From a lot of the commentors, I heard, that you wish, that you would like to have the ability to disable community themes from specific communities and not just in general.
I am currently planning on implementing that feature, but I am not quite shure, if you would like to be able to disable certain community themes on some of your devices, but not on others (which would mean storing that setting in a browser cookie) or if you want to disable community themes of certain communities for your entire user account, so that the setting is applied to all your devices at once (which would mean storing that setting in the database.

Feel free to share your opinion in more details in the comments!

No votes have been cast yet.

Show voting form

View results

Total votes: 0.

Poll closes a day ago.

13
19

Log in to comment

Hot Top New Old
Piefed.social Staff

I would think entire account personally. I can’t think of when I’d want it to be visible on my phone but not my PC.

 reply
7
OP

Alright, thanks for the feedback!

 reply
1

I wrote previously about how to put this in the session cookie, but if it is going to end up in the db, it probably makes sense to have it be a new table rather than adding a new column onto the user table. It can probably be a really simple table like CommunityBlock since this is essentially a style-only version of that (CommunityStyleBlock perhaps).

Some things to take note of while working on this:

  • Make sure to remove any of these rows that reference the user in User.delete_dependencies so that users can still be deleted. Just do it the same way we do for community blocks or any number of other tables.
  • Similarly, you need to add this to Community.delete_dependencies so that communities can still be deleted
  • To make things efficient, you can make a function to return all the blocked community styles for a particular user that can be cached (see app.utils.blocked_communities() as an example)
  • Make sure that whenever the community style blocks change (added or removed) that the cache is busted (again, using community blocks as an example): cache.delete_memoized(blocked_communities, user.id). This makes the next call refresh the result from the db rather than just pulling stale data from redis.

As for the UI (often the hardest part), I guess you will probably need some kind of button or form-control in the sidebar. Maybe a button like we do for Join/Leave currently or a checkbox and submit button? Not sure what would be best there.

All of that is just my idea for how to put this in the db anyway. @rimu@piefed.social probably has ideas as well or could tell you why all of this is crap.

 reply
5
OP

Thank you so much, for this advice!
I was also planning on doing a separate table for the blocked communities, I didn’t think about the deleting part though, so thank you for telling me how that works.
As for the UI, I have currently implemented it as an extra section in the community info card at the side (which only shows up if the community has an active theme).
I will now be working on implementing this within the database.

NxSKpJ9aUCGZ7Ko.png

 reply
2

Looks awesome! I always find the UI to be the hardest part, but that looks great.

 reply
1
OP

Do you know, if there is a way to be able to get the result of my function community.utils.get_community_theme_allowed in the jinja base template when any relevant route is rendered?

Because including this as a parameter in every route seems really inefficient.

 reply
1

The user and community are generally accessible across pretty much every relevant view function and template, so that might work well to stick those kinds of getter functions.

So, you could have a function for these models that returns whether the style is allowed for that user/community. See something like User.has_blocked_user() as an example. It could look something like this in the User class:

def allow_community_theme(self, community_id: int):
    # Need to do the import here to avoid circular import error
    from app.utils import function_you_made

    # Do the call to your function and logic here and return True/False
    # Make sure that anything you do also works for anonymous users

Similarly, you just swap some stuff around to add a function under the Community model where it would take the user_id as an argument.

 reply
2
Wiki editor

I also agree with skavau. i often delete cookie. so i prefer a more lasting solution.

 reply
4

Speaking as someone who primarily used this option through RES when I used to browse Reddit, I generally would be fine with making it per device as a cookie BUT I found it increasingly helpful to simply be able to toggle it in the extension bar without leaving the page, so it’d be nice if it worked the same way in Piefed.

(Longshot; maybe the ability to do both? Toggle it once per session or forever on your account in your list of communities? That’s more of a nice to have not a necessity, though).

 reply
3
Wiki editor

Maybe switch button located somewhere in the topbar ? Or something like mbin for theming (they do a quite good job) ? :)

 reply
2

The top bar would be nice but I feel like it should go somewhere in the sidebar to show that it really is per community.

 reply
2
edited

Deleted by author

 reply
1
Insert image