Good question, I should have included more information.
We updated WordPress to 4.6 and that broke our integration with an internal api we have.
That integration, written by a third party agency, uses the WP_HTTP class to make “ajax” calls. We believe this broke when we updated a few weeks ago. That module is timing out and we can’t figure out where.
checked plugins that could override the timeout setting
did a curl on our server to be sure WordPress was the blocker and not the api
checked filters for overrides
checked for competing processes on the server that could be causing a timeout or delay
var_dump’d every possible call our custom module is making to see what the timeouts are
Something in WordPress is caching or overriding the API calls and we can’t seem to figure out what. I even had the original developer on a call to help but we ran out of time. He broke up with us.
After some deliberation, the solution was to “simply” revert back to a previous version of WordPress when the API was functioning properly.
I’m currently looking through Varnish and Memcache.
If you’re using Trellis with Bedrock you can change the WordPress version in /site/composer.json where it includes WordPress as a dependency
I hate to say I told you so but Bedrock ships with DISALLOW_FILE_MODS enabled by default to encourage you to test WordPress updates locally before committing the change to the repo and deploying it to production.
(I’m a bit late, it looks like you’ve already rolled WordPress back but I’m posting this for future readers)