I think I may see why. I didn’t actually bother to check the main feed before, but it seems like it does have the a.community-link tag the new filter targets in every post - so if a post from leopardsatemyface ever shows up in the main feed, then the filter will think it’s on that community page and fail to block any posts. But the filter should work fine so long as no posts from that community are currently on the main feed. This should be the case regardless of which regex is used - if it wasn’t just a coincidence earlier I’ll have to test around to figure out what happened with that.

It’s a process making a good filter, I guess - I may look into a more reliable and narrower way to achieve the desired effect later on

What happened with .*?leopard.*?? It was still filtering Trump posts even from the community page? My own testing showed that variant working - I never actually even tested the leopardsatemyface variant

To be clear, this filter should allow for Trump posts that mention leopards or come from that community to show up on your main feed - that’s what’s desired here, right?

It also occurs to me that the ? on the .*? isn’t necessary - even just .*leopard.* should work as expected

Hey! I’m pretty sure this one will work:

infosec.pub##:not(a.community-link:matches-attr(title=/.*?leopard.*?/i)) article.row:has-text(/Trump|Elon|Musk|nazi/i):not(:has-text(/leopard/i))

Where now we have three filters. If the community name matches the first regex, then nothing at all will be filtered out - and then the other two work the same as before. So any post that matches the blacklist regex will be filtered out unless it also matches the whitelist regex.

I chose to make the first regex /.*?leopard.*?/i because my thinking is you may want to just copy/paste the other whitelist filter there for simplicity, but it might make more sense to do it like the others, like /leopardsatemyface|second community|third community|etc/i. The “title” of a community for the purpose of this filter should be whatever appears after /c/ in the URL, not counting the @lemmy.world (or whatever instance) part.

Actually it seems to be a difference based on our instances - if I look at the community from infosec.pub then the bit of HTML I quoted above with the mod option isn’t present, and there’s no ‘leopard’, hidden or explicit, for the whitelist filter to find.

As a note, the (s)? on your leopard isn’t needed - just ‘leopard’ will already match the ‘leopard’ part of ‘leopards’

I don’t know how to fix this currently, but I’ll test out a bit more later to see if I can find anything that works well

I’m not sure I follow - the filter seems to work as-is to me. It allows posts on both the front page and the [email protected] to bypass the filter for me.

To be clear, it’s not only applying to the title row - the article tag it targets contains the entire post as it appears in the post feed, including the title, community name, the person who submitted it, the timestamp, etc. So if anything there contains a filtered or whitelisted word it should trigger the filter.

I wouldn’t have necessarily expected the whitelist filter to work directly on the leopards community page, since posts on community feeds don’t include the community name, but it works anyways because, it seems, there’s a hidden mod option in the HTML with the community name in it: <div class="modal-body text-center align-middle text-body">Are you sure you want to transfer leopardsatemyface@lemmy.world to TheBat@lemmy.world?</div>

lemmy.world##article.row:has-text(/word1|word2|word3/i):not(:has-text(/word4|word5|word6/i))

or

lemmy.world##article.row:has-text(/maga/i):not(:has-text(/leopard/i))

will do what you want - it’ll block any posts which contain words from the first regex, unless it also has some words from the second regex

Hey thanks. I just made $2.86! And my mom is owed $1.44!