Mccunn: Carnevale, ‘wp_head’ was the hook
Liebig: Developerjustin: well to be honestly you wouldn’t know if ‘API” wordpress page has this issue because you’re not doing a new WP_Query
Urlaub: Carnevale, also, I didn’t determine – i read the code and saw what it’s doing.
Arkell: My solution was in opsec’s answer – i needed to add the priority argument.
Quach: Guimares: so far I’ve only seen it on this page v1. But, the issue that I reported on the trac is similar but in the admin dashboard. post_type is changed to ‘any’
Gardemal: CrowX-: note that if you made a change to a plugin file that file will be overwrittenwhen you update that plugin next time
Rivett: Yeah, thanks. i won’t update it :
Gilfillan: Fork it or get the author to include your changes in the next update
Reutzel: Developerjustin: i am going to go out on a limb and suggest that there is some other code intervening here. I dont think trac is the right place to put this error as it’s not a care bug
Gilfillan: CrowX-: not a solution. ;
Callendar: CrowX-: thats a stoopid idea
Mintreas: Opsec, i know, i know
Gilfillan: Poor logic in lieu of actually doing things correctly ;
Colonnese: Developerjustin: do you have any code in either a custom plugin OR your functions.php that uses pre_get_posts ?
Poliks: Guimares: I think that may have been it. One second. Triple checking.
Fricker: Guimares: that was it. Someone had added a call to add tag support to ‘pages’
Hal: Guimares: sorry to both you with this. Thanks for the help!
Mainard: Developerjustin: if it is it please make sure to close your trac ticket and try not to post trac tickets until you can verify it’s a CORE bug/
Snively: Guimares: definitely. deleting now.
Treichler: Developerjustin: use the WP support forums or come here if you have a problem with a custom install of WP. If you THINK you might have found a core bug you can come here and feel it out and see what others think.
Pittman: Developerjustin: for there to be a bug in the core THIS huge and no one having seen it yet would be surprising.
Kibler: Guimares: I should have done that in the first place. thanks again for the help
Fail: Developerjustin: also. all of this said. I would look in to NOT using empty WordPress pages at all in general for your endpoints. There are better ways to do it
Blaskovich: Guimares: anything specific that you would recommend?
Faggins: Developerjustin: you can use rewrite rules to create your permalink to the API and then if you need to load a specific file then you can do locate_template but you probably don’t even have to do that since you’re only serving up results of code
Nodland: Developerjustin: template_redirect i think is what you want to use to redirect the endpoint to a function rather than a file
Malo: Developerjustin: https://codex.----escape_autolink_uri:a03ded6cd97ffffa8f7b4e1454f3eecc----.org/Plugin_API/Action_Reference/template_redirect
Ausby: Guimares: this will be a lot more elegant. Thanks!
Dinwoodie: Developerjustin: i’ve done and am currently doing a lot with JSON endpoints and WP lately
Piening: Developerjustin: you should also know that WordPress has it’s own API these days
Shoulder: Developerjustin: https://codex.----escape_autolink_uri:a03ded6cd97ffffa8f7b4e1454f3eecc----.org/Plugin_API
Hoerr: Developerjustin: http://wp-api.org/
Schumer: Guimares: oh, nice. I figured there was something like that in the core somewhere. In this case, the contractor provided the spec so I’m mainly mapping meta
Sachez: Developerjustin: it will be in core starting with 4.4 wordpress-rest-api-is-one-major-step-closer-to-being-merged-into-core">http://wptavern.com/the-wordpress-rest-api-is-one-major-step-closer-to-being-merged-into-core
Roeber: I thought first phase was internal api only
Boyar: Haaga: endpoints will be merged in 4.5
Sachez: Nfrastructure with 4.4, endpoints with 4.6 5 the tl;dr version is at https://make.----escape_autolink_uri:a03ded6cd97ffffa8f7b4e1454f3eecc----.org/core/2015/09/21/wp-rest-api-merge-proposal/