-
-
Notifications
You must be signed in to change notification settings - Fork 114
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add extension: hide_tags #917
base: master
Are you sure you want to change the base?
Conversation
* in regards to loading the config from a non-core extension). Maybe | ||
* it's just execution ordering. (and I would guess it's core before ext) | ||
*/ | ||
class HideTagsConfig |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this one is malplaced... didn't quite know how to make the ext/hide_tags/config.php load before / in time for usage in this file, so i put it at the top of it just to get it to work... :'(
array_push($terms, '-hidden'); | ||
} | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wasn't entirely sure about this implementation... it's a bit strange to inject user query terms they never entered... but it was a very easy way to create the feature I wanted 🤔
Rather than "add querylet or do nothing", moving more code into the event means that event handlers are able to add a positive or negative querylet, add a positive or negative tag, or do nothing This means that events can respond to the `null` search term by adding a tag, which would be useful for #917
This seems like a useful feature - as to the implementation, adding a new search term into the query behind the scenes is probably the cleanest way; but right now it's only possible to add a whole extra condition to the database query, not possible to add a tag in among the other tags -- #920 should make this possible (and then in your own extension, you can react to |
Rather than "add querylet or do nothing", moving more code into the event means that event handlers are able to add a positive or negative querylet, add a positive or negative tag, or do nothing This means that events can respond to the `null` search term by adding a tag, which would be useful for #917
why this extension
I made this feature for my booru so I could arbitrarily "soft hide" posts, while still making them visible if you have the post_id (eg if you link to an image hosted on the booru elsewhere). I wanted this because I wanted to essentially treat my booru mostly like a themed booru, but I also wanted the ability to treat it a bit like a generic image host, but if I post whatever on it, then people who come to the booru for the theme will see all the non-themed posts! This will not do! I know the "private" addon does the same thing but that opens the booru up to be more of a "private image host", and that's not quite what I want either, I just want to be able to casually hide images without too much fuss. It's not "well hidden", and it's not fully visible, just something in between :)
It can probably be used for other things too? 🤔
I don't suggest merging it in as is, because It's not "clean enough" imo. I kinda "hacked it together" without too much thought. I'll try annotate the code with some PR comments of my own.
features
hidden
the post will be hidden! (the way it does this is by injecting the string-hidden
to all searches)show_hidden
, it will let you search normally across allhidden
tagged posts as well.