Pregunta sobre Arreglando WordPress de Wordpress:

WP_SITEURL y WP_HOME diferentes – aplicaciones internas

Un usuario preguntó 👇

Hubo un problema con la instalación limpia de WordPress v5.3.2. Sin plugins.

Estoy desarrollando un sitio con WordPress sin cabeza y con interfaz desacoplada. Ambos viven en su propio dominio y la interfaz recupera datos de WordPress a través de la API REST de wp. Así que definí en wp-config.php WP_SITEURL y WP_HOME de manera diferente.


define('WP_SITEURL', 'http://localhost:8069');
define('WP_HOME',    'http://localhost:8070');

A primera vista todo se veía bien. Los enlaces permanentes de publicaciones dan como resultado el lanzamiento de WP_HOME como se esperaba. REST API está bajo WP_SITEURL como se supone que debe estar.

Pero una cosa apesta. ¿Por qué las aplicaciones internas de WordPress apuntan a la URL WP_HOME? Por tanto, no es posible, por ejemplo, guardar un trabajo. ¿Qué me estoy perdiendo?

Vea también la siguiente imagen con el problema. https://ibb.co/QPw0Bxh

Este tema fue modificado hace 1 año, 1 mes por.

(@cuongnd)

Hace 1 año, 1 mes

Creo que cambiaste algo en la base de datos, mira la imagen. https://prnt.sc/qk08dq

Lanzador de hilos

(@ vavra7)

Hace 1 año, 1 mes

Aquí está el resultado de la consulta de la base de datos: * SELECT FROM wp_options DONDE choice_name IN (‘siteurl’, ‘home’);

2	home	http://localhost:8069	yes
1	siteurl	http://localhost:8069	yes

Creo que está bien, ¿no?

(@autotutorial)

Hace 1 año, 1 mes

si se utilizan constantes, se evita la consulta en la base de datos (de lo contrario, el valor se sobrescribe temporalmente). WP_HOME es el que se muestra para el navegador. técnicamente, tiene CORS (error del navegador) que se puede resolver en el resto de la API, pero si usa WP_SITEURL, no entiendo por qué cambia la URL.

Lanzador de hilos

(@ vavra7)

Hace 1 año, 1 mes

Entonces responde a lo que escribes. La base de datos contiene un valor fundamental:

2	home	http://localhost:8069	yes
1	siteurl	http://localhost:8069	yes

Estos valores se sobrescriben con mis constantes.

define('WP_SITEURL', 'http://localhost:8069');
define('WP_HOME',    'http://localhost:8070');

Por lo tanto, en settings-> general puedo ver estos valores actualmente válidos.

WordPress Address (URL)  http://localhost:8069
Site Address (URL)        http://localhost:8070

Que es exactamente lo que quiero. Volviendo a mi pregunta original. ¿Por qué las aplicaciones internas de WordPress llaman a la URL WP_HOME?

editar: La solicitud no daría como resultado CORS (error del navegador) si la solicitud resultó en WP_SITEURL.

Esta respuesta fue modificada hace 1 año, 1 mes por.

(@autotutorial)

Hace 1 año, 1 mes

Su servidor admite $_SERVER['HTTP_ORIGIN'] https://github.com/WordPress/WordPress/blob/5.3-branch/wp-includes/rest-api.php#L572 función rest_send_cors_headers( $value );

¿Puedes ver los encabezados de las direcciones desde tu navegador? (Encabezado de origen: http: // localhost: 8069) en el caso de un cambio de dominio que incluya el puerto, $ debe ser una base http: // localhost: 8069
vea también los filtros de guardado, tal vez configure WP_HOME.

Lanzador de hilos

(@ vavra7)

Hace 1 año, 1 mes

De acuerdo, debo admitir que no estoy seguro exactamente de lo que quieres que haga, pero …

Encuentro que es un problema específicamente en Gutenberg. En una página editada con un editor clásico, todo funciona bien. Entonces, el problema no es CORS, sino url. WordPress intenta acceder a la API REST en mi WP_HOME y no en WP_SITEURL, lo cual es completamente incorrecto.

Después de horas de buscar en Google, encontré el siguiente hilo: https://github.com/WordPress/gutenberg/issues/1761

No sé por qué está cerrado, ya que este es claramente un error clave de WP de 2017.

Para aquellos con un problema similar, no existe una solución que funcione.

add_filter('rest_url', function ($url) {
	$url = str_replace(home_url(), site_url(), $url);

	return $url;
});

De todas formas, gracias por la ayuda.

(@autotutorial)

Hace 1 año, 1 mes

si su servidor está configurado para recuperar la Fundación: http: // localhost: 8069 un encabezado que lanza el navegador, lo hace con la variable $_SERVER['HTTP_ORIGIN'], el resto de api es compatible con CORS, pero su servidor necesita crear esta variable. y, sin embargo, debe usar WP_HOME para relajar la API y si la API toma el encabezado, lo agrega a su encabezado. la ruta suele ser WP_HOME / wp-jsons / si hay muchos permalik habilitados, muchos plugins usan esta codificación porque WordPress 3.5 puede traer su propio directorio modificando WP_HOME. Endpoints / wp / v2 / posts https://developer.wordpress.org/rest-api/reference/ actualmente, si usa el lenguaje http solicitado pero no tiene soporte para php o javascript (para nonce) dentro de WordPress desde aquí, busque https: //wordpress.org/support/topic/cant-connect-to-wordpress-rest-api-without-a-plugin/

Lanzador de hilos

(@ vavra7)

Hace 1 año, 1 mes

@autotutorial Todavía no entiendo cuál es tu punto.

¿Por qué debería cuidar CORS? Está previsto enviar una solicitud de WP_SITEURL a WP_SITEURL (desde http: // localhost: 8069 a http: // localhost: 8069). No es necesario CORS.

En su lugar, Gutenberg envía una solicitud de WP_SITEURL a WP_HOME (desde http: // localhost: 8069 a http: // localhost: 8070). Sí, como resultado, falla en CORS, pero ese no es el punto en absoluto. WP_HOME no es el punto final de WP REST API de todos modos. Entonces, ¿cómo me ayuda aprobar CORS? ¿Cual es tu punto?

Aquí está la configuración de mi servidor.

    [SERVER_SOFTWARE] => Apache/2.4.38 (Debian)
    [REQUEST_URI] => /
    [HTTP_AUTHORIZATION] => 
    [HTTP_HOST] => localhost:8069
    [HTTP_CONNECTION] => keep-alive
    [HTTP_CACHE_CONTROL] => max-age=0
    [HTTP_UPGRADE_INSECURE_REQUESTS] => 1
    [HTTP_USER_AGENT] => Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.88 Safari/537.36
    [HTTP_SEC_FETCH_USER] => ?1
    [HTTP_ACCEPT] => text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
    [HTTP_SEC_FETCH_SITE] => none
    [HTTP_SEC_FETCH_MODE] => navigate
    [HTTP_ACCEPT_ENCODING] => gzip, deflate, br
    [HTTP_ACCEPT_LANGUAGE] => en-GB,en;q=0.9,cs;q=0.8,sk;q=0.7,en-US;q=0.6
    [HTTP_COOKIE] => wordpress_test_cookie=WP+Cookie+check; _hjid=cd70cc16-f79f-4d36-b0ea-849271f457f5; _ga=GA1.1.1616490284.1572865052; _hjIncludedInSample=1; wordpress_logged_in_d1c9e11eb00bdf205a8c6f83abac0894=root%7C1573132470%7CLyuSnZKsfF2LzJB69kjYiE291ykGDAywQGi95juQVzm%7Cecbc51d64e8faa6ec6708991b7956e28df9e7bf553568c8246ddb4f0072ca3d9; portalAlert=true; io=RTKL0-iSHe7X_wrIAAAL; _gid=GA1.1.1638110781.1578300035; wordpress_logged_in_2e0ec32a4bf45e753218dfaa032bb751=root%7C1578482052%7Ctx5Oslx824QE4ifBIAhQIXePgvxBF4vnyiIJynfIwSz%7Cecdeaa34a049a0a3132222500bb0943e2411a19e6a1283b9f84303b46c4cf3a4; wp-settings-1=libraryContent%3Dbrowse%26mfold%3Do; wp-settings-time-1=1578309252; newOrders=true
    [PATH] => /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
    [SERVER_SIGNATURE] => 
Apache/2.4.38 (Debian) Server at localhost Port 8069

    [SERVER_NAME] => localhost
    [SERVER_ADDR] => 172.25.0.3
    [SERVER_PORT] => 8069
    [REMOTE_ADDR] => 172.25.0.1
    [DOCUMENT_ROOT] => /var/www/html
    [REQUEST_SCHEME] => http
    [CONTEXT_PREFIX] => 
    [CONTEXT_DOCUMENT_ROOT] => /var/www/html
    [SERVER_ADMIN] => [email protected]
    [SCRIPT_FILENAME] => /var/www/html/index.php
    [REMOTE_PORT] => 54086
    [GATEWAY_INTERFACE] => CGI/1.1
    [SERVER_PROTOCOL] => HTTP/1.1
    [REQUEST_METHOD] => GET
    [QUERY_STRING] => 
    [SCRIPT_NAME] => /index.php
    [PHP_SELF] => /index.php
    [REQUEST_TIME_FLOAT] => 1578339291.897
    [REQUEST_TIME] => 1578339291
    [argv] => Array
        (
        )

    [argc] => 0
    [WP_SITEURL] => http://localhost:8069
    [WP_HOME] => http://localhost:8070
    [JWT_SECRET_KEY] => jwt_temp_dev_secret

(@autotutorial)

Hace 1 año, 1 mes

¿Por qué debería cuidar CORS?

si su cliente usa wordpress en un directorio pero necesita una vista sin un directorio, ¿cómo puede solucionarlo?
Por favor o moderador eliminar el valor de la cookie 😉 No lo admite $_SERVER['HTTP_ORIGIN']
puede cambiar la función rest_send_cors_headers que mostré, con el valor de $ origin http: // localhost: 8069
Gutenberg usa la relajación de API con WP_HOME, toma una buena taza de café y piensa si Gtenberg es un error, abre una aplicación de extracción en el github de Gutenberg y si es un error de WordPress, escribe en https://core.trac.wordpress.org/

Lanzador de hilos

(@ vavra7)

Hace 1 año, 1 mes

Mi cliente no usa wordpress en un directorio y no quiero verlo en absoluto. Utilizo Gatsby js para generar frontend.

Estoy desarrollando un sitio con interfaz de WordPress sin cabeza y desacoplada. Ambos viven en su propio dominio y la interfaz recupera datos de WordPress a través de la API REST de wp.

¿Entonces todavía no sé por qué debería ocuparme de CORS?

(@autotutorial)

Hace 1 año, 1 mes

característica o errores que puede escribir aquí. Si su solicitud no es aceptada, debe cambiar su codificación. https://github.com/WordPress/gutenberg/issues

(@ joelataylor-1)

hace 1 año

Tengo un problema muy similar. Todas las URL de activos de plugins y plugins mu utilizan el valor WP_SITE cuando deberían usar el mismo valor que los activos de WP Admin: WP_SITEURL.

Súper frustrante.

(@ joelataylor-1)

hace 1 año

En realidad, lo encontré, querrás el WP_CONTENT_URL valor para enrutar correctamente los plugins.

¿Solucionó tu problema??

0 / 0

Deja una respuesta 0

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *