Operar el front end en Cloudflare

PLUS Un front end que lee la interfaz headless puede ejecutarse como Cloudflare Worker: Cloudflare construye el sitio web con cada cambio en el repositorio Git y lo sirve en todo el mundo. WP-ImmoMakler sigue siendo la fuente de datos y avisa tras cada importación de que hay que reconstruir el sitio web. Esta página describe qué configurar para ello en WordPress y en Cloudflare. Los ejemplos se refieren a un front end de Astro con páginas generadas de antemano y rutas del lado del servidor para la búsqueda y los formularios, tal como lo implementa el starter de Astro de 49heroes.

Cuánto cuesta Cloudflare

El plan gratuito de Workers tiene estos límites:

Plan gratuito	Límite
Solicitudes generadas en el servidor (búsqueda, formularios, lista de favoritos, página de alertas de búsqueda, webhook)	100.000 al día
Tiempo de cálculo por solicitud	10 ms
Páginas, imágenes y scripts generados de antemano	gratis e ilimitados
Builds desde Git	3.000 minutos al mes, uno a la vez

Las páginas de detalle, de categoría y de contenido se generan durante el build y no cuentan como solicitudes. El tiempo de espera de WordPress no cuenta como tiempo de cálculo, solo la generación de la página. Los tiempos de cálculo los verá en Cloudflare, en Observability del Worker. El plan de pago empieza en 5 dólares estadounidenses al mes; las condiciones actuales figuran en la lista de precios de Cloudflare.

Requisitos

• WP-ImmoMakler a partir de la versión 5.71.0 en una edición PLUS
• Su sitio web de WordPress es accesible desde internet y tiene un certificado válido. Un Worker no consulta direcciones privadas ni páginas con certificado autofirmado.
• Una cuenta de Cloudflare y el repositorio Git de su front end en GitHub o GitLab

Configurar en WordPress

En el back end de su sitio web (wp-admin), en WP-ImmoMakler → Integraciones → Headless:

1. Activar la interfaz

   Active Activar la interfaz headless y guarde. Compruebe que la interfaz responde:

   curl -s https://www.su-dominio.es/wp-json/immomakler-headless/v1/site

   La respuesta empieza por {"api_version":. Si WordPress responde con rest_no_route, la interfaz aún está desactivada o una caché de objetos conserva los ajustes antiguos; en ese caso, vacíe la caché.

2. Anotar las credenciales

   En Credenciales de acceso, anote la clave de API y, en Secreto del webhook y estado, el secreto del webhook. Más adelante guardará ambos en Cloudflare.

3. Introducir la dirección de su front end

   En Dirección de su frontend, introduzca la dirección del Worker, por ejemplo https://su-proyecto.su-cuenta.workers.dev, más adelante su propio dominio. Los enlaces de la interfaz, de los correos de las solicitudes y de las alertas de búsqueda apuntarán entonces al front end. La dirección la conocerá tras el primer build en Cloudflare; hasta entonces puede dejar el campo vacío.

4. Introducir las direcciones de proxy de confianza

   Un Worker envía los formularios en nombre de los visitantes y no tiene una dirección fija. En Direcciones de proxy de confianza, introduzca los rangos de direcciones que Cloudflare publica en cloudflare.com/ips, uno por línea en notación CIDR, por ejemplo 173.245.48.0/20 o 2400:cb00::/32. Sin estos rangos, el límite de solicitudes por hora cuenta a todos los visitantes de su front end juntos. Encontrará más información en Formularios a través de la interfaz headless.

Configurar en Cloudflare

1. Conectar el repositorio

   En el panel de Cloudflare, abra Workers & Pages → Create → Import a repository y elija el repositorio de su front end. En un repositorio privado de una organización, la aplicación de GitHub de Cloudflare debe tener acceso a él; los propietarios de la organización lo autorizan en GitHub, en Settings → GitHub Apps.

2. Configurar el build

   Asigne un nombre de proyecto formado por minúsculas, cifras y guiones; pasa a formar parte de la dirección. Para el starter de Astro, el comando de build es npm run build y el comando de despliegue es npx wrangler deploy. Puede dejar desactivados los Preview builds mientras trabaje solo en la rama principal; cada vista previa necesita sus propias variables y secretos.

3. Introducir las variables de build

   Las variables de Advanced settings → Variables solo se aplican al build. Aquí van los valores que se escriben en el sitio web durante el build; si cambia alguno, hace falta un nuevo build. Para el starter de Astro:

   Nombre	Valor
   DEPLOY_TARGET	cloudflare
   IMMOMAKLER_API_URL	https://www.su-dominio.es/wp-json/immomakler-headless/v1
   PUBLIC_SITE_URL	la dirección del Worker, tras el primer build

   No deje ninguna fila con el valor vacío; de lo contrario, el botón Deploy no responde. El build solo necesita la clave de API si Exigir la clave de API también para las solicitudes de lectura está activado.

4. Iniciar el primer build y adoptar la dirección

   Haga clic en Deploy. Tras el build, la vista general del Worker muestra su dirección, https://<nombre del proyecto>.<cuenta>.workers.dev; el subdominio de su cuenta también figura en la vista general de Workers & Pages. Introduzca la dirección como PUBLIC_SITE_URL en Settings → Build → Variables and secrets y en WordPress como Dirección de su frontend, y reinicie el build (Retry build).

5. Guardar los secretos

   En Settings → Runtime variables and secrets, cree en la sección Production los valores que el Worker lee en cada solicitud. Haga clic cada vez en Add variable y elija la entrada Secret como Type:

   Nombre	Valor
   IMMOMAKLER_API_KEY	la clave de API de la pestaña Headless
   IMMOMAKLER_WEBHOOK_SECRET	el secreto del webhook de la misma pestaña
   BUILD_HOOK_URL	la dirección del deploy hook de la sección siguiente

   Los secretos surten efecto sin un nuevo build. Una variable de build no está disponible en tiempo de ejecución: una clave de API que solo figure allí no llega a los formularios.

   Precaución

   Cree también BUILD_HOOK_URL como Secret, no como Variable. Cloudflare sustituye las variables simples en cada despliegue por las de la configuración de Wrangler del repositorio, de modo que la dirección falta tras el siguiente push. No siga la sugerencia de pasar la variable a la configuración de Wrangler: la dirección quedaría entonces en el repositorio y cualquiera con acceso de lectura podría iniciar builds.

Reconstruir tras cada importación

WP-ImmoMakler notifica los cambios al front end, y el front end inicia un build en Cloudflare:

1. Crear un deploy hook

   En Cloudflare, en Settings → Builds → Deploy Hooks, cree un hook para la rama principal y copie su dirección. Quien conozca esta dirección puede iniciar builds; trátela como una contraseña. Guárdela como secreto BUILD_HOOK_URL. Si la dirección ha caído en manos ajenas, elimine el hook, cree uno nuevo y sustituya el secreto.

2. Activar el webhook en WordPress

   En Enviar webhook, active el envío e introduzca en Dirección del webhook la dirección que su front end ofrece para las notificaciones, en el starter de Astro https://<dirección del Worker>/api/revalidate/, con la barra final. El Tiempo de espera (segundos) agrupa los cambios de una importación en un único build.

3. Comprobar la conexión

   Haga clic en Enviar mensaje de prueba. Los ajustes indican si el mensaje se entregó; un mensaje de prueba no desencadena ningún build. Para comprobar toda la cadena, modifique y guarde un inmueble: transcurrido el tiempo de espera, aparece un nuevo build en Cloudflare, en Deployments.

Cómo está estructurado el mensaje y cómo verifica su front end la firma se describe en Webhook, enlaces y redirección.

Consejo

En un Worker, el módulo de Node node:crypto solo está disponible con la bandera de compatibilidad nodejs_compat. Con Web Crypto verifica la firma sin esa bandera, tanto en Node como en Workers:

const encoder = new TextEncoder();
const key = await crypto.subtle.importKey('raw', encoder.encode(secret), { name: 'HMAC', hash: 'SHA-256' }, false, ['sign']);
const digest = new Uint8Array(await crypto.subtle.sign('HMAC', key, encoder.encode(`${timestamp}.${rawBody}`)));
const expected = 'sha256=' + Array.from(digest, (byte) => byte.toString(16).padStart(2, '0')).join('');

let difference = expected.length ^ signatureHeader.length;
for (let i = 0; i < Math.min(expected.length, signatureHeader.length); i++) {
  difference |= expected.charCodeAt(i) ^ signatureHeader.charCodeAt(i);
}
const valid = difference === 0;

Dominio propio

Registre su dominio en Cloudflare, en Settings → Domains & Routes. Después cambie la dirección en todos los sitios: PUBLIC_SITE_URL en Cloudflare (con un nuevo build), Dirección de su frontend y Dirección del webhook en WordPress. Introduzca además el dominio como dominio permitido en su proveedor de captcha y, en Orígenes permitidos (Origins), si los navegadores de los visitantes acceden directamente a WordPress, por ejemplo para las sugerencias de dirección de la búsqueda por radio.

Preguntas frecuentes

¿Es gratuito el funcionamiento?

En el plan gratuito no paga nada mientras el sitio web se mantenga dentro de los límites de Cuánto cuesta Cloudflare. Las páginas generadas de antemano no cuentan.

¿Puedo construir el sitio web en local y subirlo por SFTP?

Solo en parte. Las páginas generadas de antemano son archivos sencillos que sirve cualquier alojamiento web. Pero la búsqueda con filtros, los formularios, la lista de favoritos, la página de alertas de búsqueda y la notificación tras las importaciones necesitan un servidor que responda a las solicitudes. Hay dos opciones: un plan de alojamiento que ejecute aplicaciones Node.js, o un front end que envíe la búsqueda y los formularios directamente desde el navegador a la interfaz; las rutas de formulario aceptan esas solicitudes de los orígenes permitidos. Con un build subido manualmente, los inmuebles nuevos solo aparecen tras el siguiente build y la siguiente subida.

¿Necesito builds de vista previa?

No. Los builds de vista previa generan una vista previa propia para cada rama salvo la principal. Cada vista previa necesita sus propias variables y secretos y tiene su propia dirección, que no figura en WordPress como origen permitido.

¿Dónde introduzco cada variable?

Los valores que se escriben en el sitio web durante el build (DEPLOY_TARGET, IMMOMAKLER_API_URL, PUBLIC_SITE_URL) son variables de build: al crear el proyecto, en Advanced settings → Variables, y después en Settings → Build → Variables and secrets. Los valores que el Worker lee en cada solicitud (IMMOMAKLER_API_KEY, IMMOMAKLER_WEBHOOK_SECRET, BUILD_HOOK_URL) se crean, una vez creado el proyecto, como secretos en Settings → Runtime variables and secrets.

¿Cómo averiguo la dirección del Worker?

Se compone del nombre del proyecto y del subdominio workers.dev de su cuenta. El subdominio aparece en la vista general de Workers & Pages; la dirección completa, en la vista general del Worker tras el primer build.

Solución de problemas

Lo que ve	Causa	Solución
El botón Deploy no responde	una variable con valor vacío o un campo no válido	eliminar las filas vacías, buscar campos marcados en rojo
El build se interrumpe con GET /site failed with 404 Es wurde keine Route gefunden	la interfaz está desactivada en WordPress	Activar la interfaz
El build se interrumpe con un error de certificado o de conexión	WordPress no es accesible públicamente	usar un sitio web de WordPress accesible públicamente y con certificado válido
Los formularios fallan, el token antispam responde con 502, WordPress indica 403	falta IMMOMAKLER_API_KEY en tiempo de ejecución, solo figura en las variables de build o difiere de la clave de API de WordPress	guardarlo como secreto en Runtime variables and secrets, copiar la clave de API actual
Log: “Headless webhook address redirects; followed it once”	a la Dirección del webhook le falta la barra final y el front end redirige; WP-ImmoMakler sigue la redirección dentro del mismo dominio	introducir la dirección indicada en el log bajo to, por ejemplo …/api/revalidate/
Log: “Headless webhook refused by the front end” con estado 301, 302, 307 o 308	la dirección del webhook redirige a otro dominio o con un tipo de redirección que WP-ImmoMakler no sigue	introducir la dirección final
Mensaje de prueba o log: estado 503	falta IMMOMAKLER_WEBHOOK_SECRET	guardarlo como secreto
Mensaje de prueba: estado 401	el secreto difiere del de WordPress	copiar de nuevo el secreto
Las importaciones no reconstruyen el sitio web	falta BUILD_HOOK_URL o Enviar webhook está desactivado	configurar el deploy hook y el webhook
Las importaciones solo reconstruyen el sitio web hasta el siguiente push	BUILD_HOOK_URL se creó como Variable en lugar de como Secret, y el siguiente despliegue la eliminó	volver a crearla como secreto
El selector de idioma o los correos llevan a WordPress	Dirección de su frontend está vacía	introducir la dirección y reconstruir
Los enlaces canónicos apuntan a localhost	falta PUBLIC_SITE_URL	introducir la variable de build y reconstruir

También puede interesarle

• Modo headless con front end propio
• Webhook, enlaces y redirección
• Formularios a través de la interfaz headless
• Referencia de la API de la interfaz headless