Usando wp_remote_get para recuperar la URL propia en localhost

8 dic 2011, 01:58:27
Vistas: 17.1K
Votos: 1

Tengo un sitio web en desarrollo local en test:8888 y estoy intentando que funcione lo siguiente en mi archivo functions.php.

$response = wp_remote_get( 'test:8888/?p=1' );
print_r($response);

Desafortunadamente esto imprime:

WP_Error Object ( [errors] => Array ( [http_request_failed] => Array ( [0] => A valid URL was not provided. ) ) [error_data] => Array ( ) )  

¿Es posible hacer una petición a tu propia URL mientras desarrollas en localhost?

0
Todas las respuestas a la pregunta 5
1

Tiempo de espera de anuncios

Deberías poder evitar el tiempo de espera usando un filtro

add_filter( 'http_request_timeout', 'wpse35826_timeout_extd' );
function wpse35826_timeout_extd( $time )
{
    // El tiempo de espera predeterminado es 5
    return 10;
}

Elige el protocolo/esquema correcto

Sobre tu problema con el protocolo/esquema: Si es tu instalación local, puedes usar el condicional.

function wpse35826_remote_get( $args )
{
    $protocol = is_SSL() ? 'https://' : 'http://';
    $response = wp_remote_get( "{$protocol}test:8888/?p=1" );
    if ( is_wp_error( $response ) )
        return "{$response->get_error_code()}: {$response->get_error_message()}";

    return print htmlspecialchars( var_export( $response, true ) );
}

// Disparar la solicitud
wpse35826_remote_get();

Si estás haciendo solicitudes a tu propio servidor local, entonces podría haber un problema con la verificación SSL. WP usa un filtro para activar su configuración:

add_filter( 'https_local_ssl_verify', '__return_false' );

Este filtro no(!) se activa para servidores locales que hacen solicitudes a un servidor en la web. Para servidores externos usa el siguiente filtro:

add_filter( 'https_ssl_verify', '__return_false' );

Problemas con solicitudes locales

También pueden haber problemas con solicitudes locales bloqueadas:

add_filter( 'block_local_requests', '__return_false' );

Otras cosas que pueden influir en tu capacidad para hacer solicitudes locales son constantes configuradas incorrectamente en tu archivo wp-config.php:

WP_HTTP_BLOCK_EXTERNAL
// Si WP_HTTP_BLOCK_EXTERNAL está definido puedes añadir hosts que no deberían ser bloqueados.
WP_ACCESSIBLE_HOSTS

En caso de que estés usando Proxies:

// Te permite definir algunas direcciones que no deberían pasar a través de un proxy.
// El núcleo establece tanto www como no-www como bypass.
// get_option('siteurl') y localhost son bypass por defecto.
WP_PROXY_BYPASS_HOSTS

¿No hay cURL?

Si no está disponible cURL y no estás transmitiendo datos a un archivo, WP recurrirá a usar Fsocketopen() en su lugar. De un comentario del núcleo, que lo resume muy bien:

Fsocketopen tiene problemas con 'localhost' con IPv6 en ciertas versiones de PHP, intenta conectarse a ::1, lo cual falla cuando el servidor no está configurado para ello. Por compatibilidad, siempre conéctate a la dirección IPv4.

El punto es que WP solo interviene si tenemos el nombre de host localhost. El host fsocketopen se establecerá entonces a '127.0.0.1'.

19 ene 2013 12:33:42
Comentarios

¡Excelente respuesta! La magia para mí fue cambiar de http://localhost a http://127.0.0.1 - ninguna otra parte de esta respuesta importó después de hacer ese cambio.

random_user_name random_user_name
28 dic 2016 01:32:42
4

'test:8888/?p=1' no es una URL válida.

Prueba con 'http://test:8888/?p=1' en su lugar.

8 dic 2011 02:16:32
Comentarios

que da este WP_Error Object ( [errors] => Array ( [http_request_failed] => Array ( [0] => La operación ha excedido el tiempo de espera después de 5001 milisegundos sin recibir ningún byte ) ) [error_data] => Array ( ) )

Mike Mike
8 dic 2011 04:50:05

Estoy ejecutando MAMP

Mike Mike
8 dic 2011 04:50:15

¿Es "test:8888" una URL válida en tu máquina? No hay problema con acceder a recursos locales, pero esos recursos deben existir realmente y ser accesibles.

Otto Otto
8 dic 2011 16:06:25

sí, eso se resuelve correctamente en mi máquina.

Mike Mike
8 dic 2011 18:22:28
0

Tuve um problema semelhante e resolvi assim:

function wpse35826_remote_get() {
    $response = wp_remote_get( 'http://test:8888/?p=1' );
    echo 'Resposta:<pre>';
    print_r($response);
    echo '</pre>';
}
add_action('admin_init','wpse35826_remote_get');
18 abr 2012 09:26:06
0

Creo que en realidad tienes dos problemas aquí. La respuesta de Otto resolvió tu primer problema, porque omitir el http:// lo convirtió en una URL inválida, por eso recibiste el error No se proporcionó una URL válida.

El segundo problema es algo diferente y no relacionado, y te está dando el error Tiempo de espera agotado. No puedo decirlo con certeza sin ver todo tu código, pero supongo que la llamada a wp_remote_get() está dentro de una función de callback que está registrada en un hook que también se dispara en la página que se está solicitando con wp_remote_get(). Esa situación crea un bucle recursivo que finalmente agota el tiempo de espera.

Debes asegurarte de que la llamada a wp_remote_get() no se ejecute en la página que estás solicitando. Puedes hacerlo registrando el callback en un hook diferente o usando etiquetas condicionales para evitar llamar a wp_remote_get() en la página solicitada.

Aquí tienes un ejemplo, asumiendo que siempre estarás llamando a páginas que no son del administrador:

if( !is_admin() )
    return;

$response = wp_remote_get( 'http://test:8888/?p=1' );
print_r($response);
28 ago 2012 01:29:13
0
add_filter( 'http_request_host_is_external', '__return_true' );

add_filter( 'http_request_args', function ( $args ) {
    $args['reject_unsafe_urls'] = false;
    return $args;
}, 999 );

add_filter( 'https_local_ssl_verify', '__return_false' );

add_filter( 'block_local_requests', '__return_false' );

Prueba cualquiera de los filtros... me funcionó a mí

22 jul 2024 21:30:29