Bannister: So yeah still a year out

Regas: Haaga: the API as a stand alone has plenty to work with though. you can use it as a plugin until its rolled in

Muellner: Guimares: absolutely, just know that some endpoints may change

Dufrane: But v2 is probably going to be really similar to core

Macvane: It’ll really be interesting to see the dashboard start to use the api

Metcalf: Im just sad it couldnt come sooner because i’m building this pretty big social network type of site with WP not using BuddyPress and will probably end up switching a large amount over to the API when its rolled into core

Tieng: Just bad timing. but i guess it’s job security for me :

Scheumann: Yeah we’ve already built components that use the api

Bevers: Just finishing one up now actually

Halon: I’m still on v1 of the plugin though

Media: So it’s going to have to be refactored

Kanthak: Right now i’m just making my own API endpoints because they’re smallish

Carnevale: Is it a bad idea to allow two separate but simultaneous ajax calls?

Schiro: Having each core committer look at it though is awesome

Clatterbuck: Carnevale: why would it be?

Isackson: Carnevale: thats kind of the purpose of ajax in a way. but depends on what the calls are. Are they redundant in any way ?

Carnevale: There will probably be similarities in their queries yes

Carnevale: One call updates available taxonomies in a select list, the other updates actual search results

Vandermoon: Carnevale: doing something similar, it’s fine

Carnevale: So one action will require updates in two areas

Carnevale: This is for a search page where sub-filters change based on their parents selection

Gembarowski: So I’m extending WP_List_Table local copy yeah yeah. but I’m trying to use the hidden columns functionality. That uses some of the screen-based context and requires that columns can be retrieved via a filter before I even instatiate my WP_List_Table-based cl***. What’s the “proper” way to do this?

Carnevale: But the results should update even if a sub-filter is not used

Carnevale: I hope that’s enough context

Gembarowski: Specifically, I understand the basics of filters. I’m looking for a recommendation that keeps the code manageable. This design decision seems to remove my ability to store everything in the cl***. Unless I define a static method equivalent of get_columns.

Lefebvre: Carnevale: just did something similar, it’s fine

Ratti: Carnevale: i’m wondering why you can’t update both in the same “success” response from one query though

Carnevale: I’m considering that

Villani: Demik: just to be sure you saw this on the codex page about WP_LIST_TABLE “This cl***’s access is marked as private. That means it is not intended for use by plugin and theme developers as it is subject to change without warning in any future WordPress release.”

Rensen: Carnevale: if you CAN do that, you SHOULD do that for effeciency’s sake

Carnevale: Yep, this functionality is evolving as I get each piece working so it might be time to refactore a bit

Warsme: Sachez: have you ever loaded custom styles into layerslider’s editor?

Sachez: Haaga: nope. It pretty much worked for us right out of the box.

Delcamp: Yeah mine works fine, I just have some cl***es that get styled in a certain way and I wanted to style that on the admin side

Carney: Hey guys. I’m having a really tough time getting a custom upload location to work. I need to upload files to /wp-content/uploads/podcasts/{user_login}/{Y}/{m}. I’m using the following filters, actions and methods to accomplish this but when I throw a breakpoint in the “save_post” method to dump wp_upload_dir it’s still show the default upload location. Any help would be greatly greatly apprciated.

Carnevale: Guimares: It might make for some inefficient code. I’ll describe the scenario and if you care to weigh in please do but not urgent.