Error de cors de WordPress
Contents
Esto se debe probablemente a que he instalado WordPress en un subdirectorio, pero luego lo he «movido» a la raíz copiando el index.php a la raíz (quiero que el nuevo sitio web se muestre al solicitar la URL de inicio).
El problema aquí parece ser que antes tenías las fuentes en el mismo dominio que la instalación de WordPress. Ahora que las fuentes viven en un dominio diferente (y posiblemente en un servidor diferente), necesitas establecer la cabecera Access-Control-Allow-Origin en el servidor que está manejando las fuentes, no en el que sirve a WordPress.
Desactivar cors wordpress
Tengo este sitio de wordpress con un plugin llamado JSON API. Este plugin proporciona un formato JSON para el contenido que está en el wordpress. Pude habilitar CORS en el wordpress añadiendo header(«Access-Control-Allow-Origin: *»); en el header de php. Pero cuando probé la url que el plugin JSON API proporciona el CORS ya no funciona.
He utilizado diferentes APIs de WordPress – pero para aquellos que utilizan el WP-API ‘oficial’, tuve muchos problemas con este CORS — y lo que encontré fue que entre el enfoque .htaccess y algunos otros que me encontré… añadiendo esto a su tema functions.php funcionó mejor.
Usando WordPress 5.2.3 – mientras se usa GET y POST externamente, lo siguiente finalmente abrió sesame para mí. Probé todas las respuestas anteriores (sin éxito) antes de encontrar esta solución que funcionó para mi caso.
Tenga en cuenta que esto permitirá el acceso desde CUALQUIER fuente. Por seguridad debería intentar hacer algo como establecer una lista de dominios permitidos que puedan hacer la petición a su sitio de WordPress y cortocircuitar el CORS permitido si el dominio que hace la petición no está en la lista permitida:
Access-control-allow-origin
Acabo de migrar un sitio web de WordPress de HTTP a HTTPS y algunas páginas no se migran correctamente porque el contenido está bloqueado debido a la política CORS. el problema es que dos fuentes para calificar el error de la política CORS son del mismo dominio, pero sólo su diferente en el nivel de seguridad uno es HTTPS y otro es HTTP.
El acceso a la Fuente en ‘https://kitabee.in/wp-content/themes/academia/dist/fonts/montserrat/montserrat-regular-webfont.woff2’ desde el origen ‘http://kitabee.in’ ha sido bloqueado por la política CORS: No hay cabecera ‘Access-Control-Allow-Origin’ en el recurso solicitado. Por lo tanto, no se permite el acceso al origen ‘http://kitabee.in’.
No tenga enlaces absolutos a los recursos (es decir, los que tienen el dominio en ellos también), utilice unos como ‘/wp-content/themes/academia/dist/fonts/montserrat/montserrat-regular-webfont.woff2’ en su lugar. De este modo, utilizará el mismo dominio y protocolo que la página que lo solicita.
La política de WordPress cors no ‘access-control-allow-origin’
El acceso a XMLHttpRequest en ‘https://wordpress.dev/wp-json/wp/v2/posts’ desde el origen ‘http://localapp.test’ ha sido bloqueado por la política CORS: El campo de cabecera de la solicitud x-requested-with no está permitido por Access-Control-Allow-Headers en la respuesta de preflight.
¿Pero por qué? La regla .htaccess que añadimos arriba sólo tiene un valor. La razón de esto es que la API REST de WordPress ya está estableciendo las cabeceras CORS usando la función rest_send_cors_headers(). Puede anular esto eliminando las cabeceras CORS existentes proporcionadas por WordPress y definiendo las suyas propias.
Hay muchas razones por las que no deberías configurar las cabeceras de la manera mostrada arriba, pero esta es una gran base para conseguir que la API REST esté configurada para jugar bien con Axios, jQuery.ajax() o la API Fetch.
