@Howdy_McGee, all software development should start with a use case that it answers. The rest API use case is about "lets do naked wp_query that outputs json to the network" This is how you get after few years of development into a situation in which the rest api returns a post without its thumbnail and you need to make another request to get it.

Since it is a front end tech, caching should have been a big priority, but as far as I know W3TC supports it.

it is just a half assed big pile of code doing good to almost no one, and I thought that antucrist supposed to be actually bad, and not just "no good" ;)

@MarkKaplun good intentions are the opposite of "good".

@David Any videos?

come on guys, stop starring everything I write here!

I should star that ^

I should ban you

If someone indeed decides to star that comment. That will increase the probably of me getting banned >_< since stars are anonymous

exactly. prepare for a vacation

I wish you were my boss!

unpaid vacation

commit a bug before going to vacation. Good luck finding it while I am relaxing on a sunny beach..

is it friday

@Sisir I don't know about any.

@MarkKaplun I mean, it has to do good to someone, why do so many people want it in core? I honestly don't know much about the REST API but feel like if you need an API endpoint you could just create one instead of one being built in automatically right? Plus, since you can disable it - is it really that big of a deal if they want to put some time into it?

hmmm, but can you disable it?

Oh, I thought I saw that you could via hook. Like automatic updates and such.

Can you not?!

Now im doubting whether I saw it or not

rest api is for big sites that need server to server communication or for "app" style of site. It will do nothing for 99.9% of wordpress sites

it is not in core, so we don't realy know how will it be possible to disable it

people are ecstatic becuase some other people promised that it will change wordpress forever

Like WPMU Dev "The REST API (and How It Could Change WordPress Forever)"

lol

since no details were given exactly how (back to no definition of use case for the feature) everybody can dream that it will be a change which is good for him :)

"true separation of client and server" from that lWPMU article, but most sites don't need any real logic on client side

It seems more or less it's trying to appeal to bigger businesses

It's still a ridiculous amount of people who still think WordPress is just a blogging platform.

yes, for them it will be good, but I will be surprised if the end points as defined in 4.5 will be good enough

IMO just the infrastructure that lets it be easier to create end points should go into core

I 100% agree with that. It took me a bit to understand how to put together endpoints.

yes, understanding rewrite rules is hard, but after that doing the wp_query on server or client side (via the rest api) should not make a lot of difference in development time

is ajay-shanker just answering questions to answer them?? every answer I've looked at appears he has never read the question.

lol: wordpress.stackexchange.com/questions/216028/…

When writing a plugin, if you have some functionality that just deals with hooks, should that be inside a class or standalone like another funcitons.php( but inside your plugin folder )? I've made the assumption that when creating a plugin everything should be wrapped in this general class just so you don't run into function name conflicts.

@Howdy_McGee registering callbacks is a separate task. you can just do that with a regular function, a lambda or in a dedicated controller. depends on context.

@Howdy_McGee add_action( 'bla' [ $this, 'foo' ] ); is almost always wrong

T-T

That's all I've seen though. What's an alternative?

orr, those globals … come on!

Why is it wrong?

becuase that's procedural code

you are mixing the callback registration with business logic

don't

Alright... Do you know any good references to look over as a start? I have like, 100x questions about best practices

hmm, no reference

start here: r.je/this-keyword-isnt-oop.html

What do you mean by business logic?

ELI5?

hm?

I don't understand what you mean by mixing registration with business logic :/

registering callbacks is management. doing the work in the callback is business.

you must be able to substitute the object whose methods you are registering. that's not possible with $this

Reading that r.je link, adding that extra layer seems to make the code less readable and more convulted. I could see the issue becoming worse in larger examples ( those example here were very minimalistic ). That being said I'm not sure how to implement what he suggests in the context of registering hooks without the use of $this.

:/ now I feel like I'm back to square one

I'm assuming this is a decent example of adding hooks in a fashion similar to the r.je link