Менше, ніж відповідь, але лише перелік речей, що випливають із мого досвіду роботи, - можливо, ви щось не помітили.
Налагодження запиту та його результати
Без кодування занадто глибоко в процесі оновлення, але WP HTTP API використовує WP_HTTPклас. Також пропонується приємна річ: гак для налагодження.
do_action( 'http_api_debug', $response, 'response', $class, $args, $url );
Де $responseтакож може бути WP_Errorоб’єкт, який, можливо, розповість вам більше.
Примітка. Якщо короткий тест, цей фільтр, здається, працює лише (чомусь), якщо розмістити його якнайближче до того, де ви справді робите запит. Тож, можливо, вам потрібно зателефонувати за допомогою зворотного дзвінка на одному з наведених нижче фільтрів.
WP_HTTP Аргументи класу
Самі аргументи класів є фільтруваними, але деякі з них афаіки скидаються внутрішніми методами до того, що WP передбачає, що потрібно.
apply_filters( 'http_request_args', $r, $url );
Один з аргументів - ssl_verifyце істинно за замовчуванням (але для мене викликає величезні проблеми при оновленні з - наприклад, GitHub). Редагувати: Після налагодження тестового запиту я знайшов ще один аргумент, встановлений для перевірки, чи встановлено SSL true. Це називається sslverify(не відокремлюючи підкреслення). Не маю уявлення, куди це потрапило в гру, якщо вона насправді використовується або покинута і якщо у вас є шанс вплинути на її значення. Я знайшов це за допомогою 'http_api_debug'фільтра.
Повністю на замовлення
Ви також можете "просто" переосмислити цілі внутрішні сторінки та перейти із власною установкою. Для цього є фільтр.
apply_filters( 'pre_http_request', false, $r, $url );
Перший аргумент потрібно встановити на true. Чим ви можете взаємодіяти з аргументами всередині $rта результатом parse_url( $url );.
Проксі
Інша річ, яка може працювати, може запускати все через користувацький проксі. Для цього потрібні деякі налаштування у вашому wp-config.php. Я ніколи раніше цього не пробував, але я пробігся через константи деякий час назад і підсумував кілька прикладів, які повинні працювати, і включив кілька коментарів у випадку, якщо мені це буде потрібно одного дня. Ви повинні визначити WP_PROXY_HOSTі WP_PROXY_PORTяк хв. налаштування. В іншому нічого не вийде, і він просто обійде ваш проксі.
# 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' );
EDIT
WP_HTTPКлас зазвичай виступає в якості базового класу (буде розширено для різних сценаріїв). Виступаючі WP_HTTP_*класи Fsockopen, Streams, Curl, Proxy, Cookie, Encoding. Якщо ви підключите зворотний виклик до 'http_api_debug'-action, третій аргумент підкаже, який клас використовувався для вашого запиту.
Всередині WP_HTTP_curlкласу ви знайдете request()метод. Цей метод пропонує два фільтри для перехоплення поведінки SSL: один для локальних запитів 'https_local_ssl_verify'і один для віддалених запитів 'https_ssl_verify'. WP, ймовірно, визначатиме localяк localhostі що ви отримуєте взамін від get_option( 'siteurl' );.
Тому я б спробував виконати наступне право перед тим, як зробити цей запит (або від зворотного дзвінка, підключеного до найближчого запиту:
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' );
Сторона: У більшості випадків WP_HTTP_curlбуде використовуватися для обробки проксі.