Menos que una respuesta, pero solo una lista de cosas directamente de mi experiencia con él, tal vez haya pasado por alto algo.
Depurando la solicitud & sus resultados
Sin excavar demasiado en el proceso de actualización, pero la API HTTP de WP usa la clase WP_HTTP . También ofrece una buena cosa: un gancho de depuración.
do_action( 'http_api_debug', $response, 'response', $class, $args, $url );
Donde $response también puede ser un objeto WP_Error que quizás te diga más.
Nota: de una breve prueba, este filtro parece funcionar solo (por algún motivo) si lo coloca como cerca en el lugar donde está realizando la solicitud. Es posible que necesite llamarlo desde una devolución de llamada en uno de los siguientes filtros.
WP_HTTP Argumentos de la clase
Los argumentos de las Clases en sí son filtrables, pero algunos métodos internos se restablecen a lo que WP supone que es necesario.
apply_filters( 'http_request_args', $r, $url );
Uno de los argumentos es ssl_verify , que es verdadero de forma predeterminada (pero para mí causa problemas masivos al actualizar desde, por ejemplo, GitHub). Editar: Después de depurar una solicitud de prueba, encontré otro argumento que está configurado para verificar si SSL está configurado como true . Se llama sslverify (sin separar el guión bajo). No tengo idea de dónde entró esto en el juego, si está realmente en uso o abandonado y si tienes la oportunidad de influir en su valor. Lo encontré usando el filtro 'http_api_debug' .
Completamente personalizado
También puede "simplemente" anular todas las partes internas e ir con una configuración personalizada. Hay un filtro para eso.
apply_filters( 'pre_http_request', false, $r, $url );
El primer argumento debe establecerse en verdadero. Entonces puedes interactuar con los argumentos dentro de $r y el resultado de parse_url( $url ); .
Proxy
Otra cosa que podría funcionar podría ser ejecutar todo a través de un Proxy personalizado. Esto necesita algunos ajustes en su wp-config.php . Nunca había intentado esto antes, pero hace un tiempo repasé las constantes y resumí algunos ejemplos en los que debería funcionar e incluí algunos comentarios en caso de que lo necesite algún día. Debe definir WP_PROXY_HOST y WP_PROXY_PORT como un mínimo. ajuste. De lo contrario, nada funcionará y simplemente pasará por alto tu 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
La clase WP_HTTP normalmente actúa como clase base (se ampliará para diferentes escenarios). Las clases WP_HTTP_* extendidas son Fsockopen , Streams , Curl , Proxy , Cookie , Encoding . Si enlaza una devolución de llamada a la acción 'http_api_debug' , entonces el tercer argumento le dirá qué clase se utilizó para su solicitud.
Dentro de la clase WP_HTTP_curl , encontrarás el método request() . Este método ofrece dos filtros para interceptar el comportamiento SSL: uno para solicitudes locales 'https_local_ssl_verify' y otro para solicitudes remotas 'https_ssl_verify' . Es probable que WP defina local como localhost y lo que obtenga a cambio de get_option( 'siteurl' ); .
Entonces, lo que haría es intentar lo siguiente justo antes de que hagas esa solicitud (o de una devolución de llamada que esté conectada a la solicitud más cercana:
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: En la mayoría de los casos, WP_HTTP_curl se usará para manejar Proxies.
