Hershman: I can create the widget to be as flexible as i want then
Verzi: Wtf are you talking about
Gormley: What would your widget do that the main WP query couldnt?
Degonia: This request would cause wordpress to perform a query that founds posts in the foo category, right ?
Blecker: As an example, pretend i have a custom taxonomy
Poppe: We’ll call it “flags”
Varanda: And a couple of “foo” posts get the “featured” flag
Gragert: Ok. your over use of the enter key is getting annoying. Just typw your use case
Kroesing: I want “featured” posts to float to the top
Slisz: So i have to alter the main query
Garczynski: Altering the main query is annoying
Nopachai: And. that is the exact purpose of the “goofy hooks” you talk about
Leitzinger: Right but i’m asking if i can avoid those
Gaters: How is using a simple hook annoying
Praska: And just write my own WP_Query from scratch
Moises: Because that’s way easier
Kampen: Nak: no. its really not
Boarts: Its not easier and it’s certain;y not a good idea.
Dorough: The hook is not as flexible as a widget
Huver: If i drop a widget in, each widget can have its own configuration/parameters
Mcmartin: Nak: then you simply have no idea how to use the hook
Lampel: Nak: the hook can be used under a number of different conditions
Raymo: How can i add a pre_get hook for a specific category
Vaudreuil: Nak: https://codex.----escape_autolink_uri:a03ded6cd97ffffa8f7b4e1454f3eecc----.org/Conditional_Tags
Gamble: I’ve already made an uncontestable point in a way
Ewy: Because the theme should have no awareness of such things
Floerchinger: The theme shouldn’t know of a particular category/tag that exists
Malabe: Wtf are you talking about?
Degiacomo: Nak: well, that’s a core problem with wordpress.
Reinholt: What if the client wants to create a new tag and then query based on that tag
Naeve: Nak: you can’t ***ume that when it comes to wordpress because that’s simply not how wordprss works
Orren: The client would have to go edit the php files and do is_something’my_tag’
Weeden: Nak: you can make a UI to manage the pre_get_post conditionals if you wanted the same way you would make a UI to manage yourt million and one new queries
Luz: Nak: you could also have a config page for your plugin that handles this
Donoghue: Nak: is_something$myvar
Drouse: Bu***and the ‘my_arg’ there is my point
Lynchj: The theme couldn’t possibly know “my_arg” exists
Dzierzanowski: Because the client made it
Gienger: Nak: you have no point.
Prattella: Nak: yea. you grab the arg from where ever you stored it
Bieberle: In your wacky idea the arg would be stored in a widget instance. in mine it would be stored with the data object you want the code to reun on
Vicoy: Either a post, a category term, etc
Partenope: Or even as a generic option in wp_options
Triller: It all depends on where you actually want this to trigger, when, and how
Chaney: Bu***and how do you expect me to write code in the template for a client variable that doesn’t even exist yet
Furnari: But making a new query for every archive page because you want some configurable variables is a terrible terrible idea.
Feltman: Nak: WHAT ARE YOU TALKING ABOUT!
Schum: Nak: you’re being stupidly stubborn and making it impossible to help you. so either lose the attitude or I’m done