Nak: you’re being stupidly.

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:

Gamble: I’ve already made an uncontestable point in a way

Corkill: Ifis_archive’taxonomy’

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.


Schum: Nak: you’re being stupidly stubborn and making it impossible to help you. so either lose the attitude or I’m done