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.