Menos que uma resposta, mas apenas uma lista de coisas diretamente da minha experiência com ela - talvez você tenha esquecido algo.
Depurando o pedido & seus resultados
Sem aprofundar muito no processo de atualização, mas a API HTTP do WP usa a classe WP_HTTP . Também oferece uma coisa legal: um gancho de depuração.
do_action( 'http_api_debug', $response, 'response', $class, $args, $url );
Onde $response também pode ser um objeto WP_Error que talvez lhe diga mais.
Nota: A partir de um teste breve, este filtro parece funcionar (por algum motivo) apenas se você colocá-lo como perto de onde você está realmente fazendo a solicitação. Então, talvez você precise chamá-lo de dentro de um retorno de chamada em um dos filtros abaixo.
WP_HTTP Argumentos da classe
Os argumentos de Classes em si são filtráveis, mas alguns são redefinidos pelo método internals de volta para o que o WP assume que é necessário.
apply_filters( 'http_request_args', $r, $url );
Um dos argumentos é ssl_verify , que é verdadeiro por padrão (mas para mim causa problemas enormes ao atualizar de - por exemplo - GitHub). Editar: Após a depuração de uma solicitação de teste, encontrei outro argumento que está definido para verificar se o SSL está definido como true . É chamado sslverify (sem separar o sublinhado). Não faço ideia de onde isso entrou no jogo, se está realmente em uso ou abandonado e se você tem uma chance de influenciar seu valor. Eu achei usando o filtro 'http_api_debug' .
Completamente personalizado
Você também pode "simplesmente" substituir todos os componentes internos e usar uma configuração personalizada. Há um filtro para isso.
apply_filters( 'pre_http_request', false, $r, $url );
O primeiro argumento precisa ser definido como verdadeiro. Do que você pode interagir com os argumentos dentro de $r e o resultado de parse_url( $url ); .
Proxy
Outra coisa que pode funcionar é a execução de tudo por meio de um proxy personalizado. Isso precisa de algumas configurações no seu wp-config.php . Eu nunca tentei isso antes, mas eu repassei as constantes há algum tempo e resumi alguns exemplos que o deveria funcionar e incluí alguns comentários no caso de eu precisar dele algum dia. Você precisa definir WP_PROXY_HOST e WP_PROXY_PORT como min. configuração. Caso contrário, nada funcionará e simplesmente ignorará seu proxy.
# HTTP Proxies
# Used for e.g. in Intranets
# Fixes Feeds as well
# Defines the proxy adresse.
define( 'WP_PROXY_HOST', '127.0.84.1' );
# Defines the proxy port.
define( 'WP_PROXY_PORT', '8080' );
# Defines the proxy username.
define( 'WP_PROXY_USERNAME', 'my_user_name' );
# Defines the proxy password.
define( 'WP_PROXY_PASSWORD', 'my_password' );
# Allows you to define some adresses which
# shouldn't be passed through a proxy.
define( 'WP_PROXY_BYPASS_HOSTS', 'localhost, www.example.com' );
EDITAR
A classe WP_HTTP normalmente atua como classe base (será estendida para diferentes cenários). As classes WP_HTTP_* de extensão são Fsockopen , Streams , Curl , Proxy , Cookie , Encoding . Se você ligar um retorno de chamada ao 'http_api_debug' -action, o terceiro argumento informará qual classe foi usada para sua solicitação.
Dentro da classe WP_HTTP_curl , você encontrará o método request() . Esse método oferece dois filtros para interceptar o comportamento do SSL: um para solicitações locais 'https_local_ssl_verify' e um para solicitações remotas 'https_ssl_verify' . O WP provavelmente definirá local como localhost e o que você recebe em relação a get_option( 'siteurl' ); .
Então, o que eu faço é tentar o seguinte logo antes de você fazer essa solicitação (ou de um retorno de chamada que esteja ligado à solicitação mais próxima:
add_filter( 'https_ssl_verify', '__return_true' );
# Local requests should be checked with something like
# 'localhost' === $_SERVER['HTTP_HOST'] or similar
# add_filter( 'https_local_ssl_verify', '__return_true' );
Sidenote: na maioria dos casos, WP_HTTP_curl será usado para lidar com proxies.
