La integración WordPress y Laravel es la combinación de WordPress como CMS con el framework PHP Laravel para construir aplicaciones más complejas, usando la base de datos de WordPress desde Laravel via Eloquent ORM, API REST, o el framework Acorn. Los tres métodos principales son Corcel, Acorn y la REST API, cada uno con casos de uso distintos según la arquitectura del proyecto.
En 30 segundos
- Corcel es un paquete Composer que expone los modelos de WordPress (posts, taxonomías, meta fields) como modelos Eloquent, sin tocar WordPress directamente.
- Acorn, de Roots, trae el service container de Laravel adentro de WordPress, con Blade templating y migraciones.
- La REST API de WordPress es el método desacoplado: Laravel consulta vía HTTP, sin compartir base de datos.
- Para proyectos donde WordPress maneja el contenido y Laravel la lógica de negocio, Corcel es la solución más directa.
- La seguridad de la base de datos compartida es el punto débil más frecuente: credenciales en texto plano en `.env` o permisos de usuario de MySQL mal configurados.
¿Por qué integrar WordPress con Laravel?
Ponele que tenés una SaaS con un dashboard complejo, lógica de suscripciones, roles de usuario y una API propia. WordPress no te alcanza para eso. Pero sí tenés un blog con 200 posts rankeados en Google, un equipo de marketing que sabe usar el editor Gutenberg, y no querés migrar nada. ¿Qué hacés?
Ahí aparece la integración WordPress y Laravel como solución real. WordPress hace lo que hace bien: CMS, SEO via RankMath, gestión de contenido. Laravel hace lo que WordPress no puede: lógica de negocio compleja, arquitectura MVC limpia, testing, colas, eventos. Cada plataforma en su cancha.
Los casos más comunes que aparecen en producción son: portales empresariales con blog público en WordPress y extranet en Laravel, eCommerce con WooCommerce para el catálogo y Laravel para la lógica de pedidos personalizada, y sitios de membresías donde WordPress maneja el contenido pero Laravel controla el acceso. No es un setup raro; según WP Engine, esta arquitectura híbrida es cada vez más frecuente en agencias de desarrollo regional.
Tres métodos de integración: Corcel, Acorn y API REST
Antes de entrar a fondo en cada uno, la tabla comparativa que te ahorra la lectura completa si ya sabés qué necesitás:
| Método | Comparte DB | Requiere WordPress activo | Curva de aprendizaje | Mejor para |
|---|---|---|---|---|
| Corcel | Sí | No necesariamente | Baja (Eloquent estándar) | Leer/escribir posts y meta desde Laravel |
| Acorn (Roots) | Sí | Sí (corre adentro) | Media | Temas custom con toda la potencia de Laravel |
| REST API | No | Sí (expone endpoints) | Baja | Arquitecturas desacopladas, microservicios |
La elección depende de si querés que Laravel y WordPress compartan la base de datos o que se hablen por HTTP. Eso no es un detalle menor.
Corcel: acceder a la base de datos de WordPress con Eloquent ORM
Corcel es un paquete open source disponible en GitHub que expone las tablas de WordPress (`wp_posts`, `wp_postmeta`, `wp_terms`, etc.) como modelos Eloquent. Lo instalás con Composer y listo: podés hacer queries a WordPress como si fueran modelos propios de Laravel.
La instalación es:
composer require jgrossi/corcel- Configurar la conexión en `config/database.php` apuntando a la base de datos de WordPress
- Publicar el config de Corcel:
php artisan vendor:publish --provider="Corcel\Laravel\CorcelServiceProvider"
Lo que podés hacer después es bastante directo. Algunos ejemplos de uso real:
Post::published()->get()— todos los posts publicadosPost::type('producto')->get()— custom post types$post->meta->color— acceso a meta fields individualesPost::hasMeta('_featured')->get()— filtrar por meta
El soporte para Advanced Custom Fields (ACF) existe, aunque con limitaciones en campos complejos como Repeater o Flexible Content. Para meta fields simples y relaciones básicas, Corcel funciona muy bien. Para CPTs con estructuras muy complejas, vas a necesitar queries SQL directas o ajustes. Ya lo cubrimos antes en formularios seguros con WPForms.
¿Y qué pasa si necesitás crear posts desde Laravel? También podés, aunque el comportamiento difiere un poco del que haría WordPress nativo (no dispara hooks de WordPress, por ejemplo). Si eso importa, mejor usar la REST API para escrituras.
Acorn: el framework Laravel adentro de WordPress
Acorn, desarrollado por Roots, es una propuesta diferente. No es solo un ORM: es una implementación completa del service container de Laravel que corre dentro del contexto de WordPress. Blade templating, service providers, migraciones, façades, todo disponible desde un tema o plugin de WordPress.
La diferencia clave con Corcel: Acorn trae Laravel adentro de WordPress. Corcel lleva WordPress adentro de Laravel. Son arquitecturas inversas.
Acorn encaja cuando:
- Estás construyendo un tema custom con Sage (el tema de Roots basado en Blade)
- Necesitás service providers propios para inyección de dependencias dentro de WordPress
- Querés Blade en lugar de PHP puro en las plantillas
- El proyecto es principalmente WordPress pero necesita capacidades de Laravel para ciertas funcionalidades
Lo que Acorn no resuelve tan bien es la separación clara de responsabilidades. Si tu aplicación tiene lógica de negocio que va más allá del contenido, termina mezclando WordPress hooks con clases de Laravel de formas que pueden ser difíciles de testear.
Integración vía API REST de WordPress
El método más desacoplado. Laravel consulta a WordPress via HTTP, sin compartir base de datos ni código. WordPress expone sus endpoints en `/wp-json/wp/v2/posts`, Laravel los consume con Guzzle o el HTTP Client nativo.
La ventaja principal es la independencia total: podés escalar cada sistema por separado, actualizar WordPress sin romper Laravel, o reemplazar WordPress por otro CMS sin tocar el código de Laravel. Para alojamiento, si tenés ambos sistemas en servidores distintos (por ejemplo WordPress en un hosting administrado y Laravel en un VPS propio como los de donweb.com), esta arquitectura es la más limpia.
El punto débil, claro, es la latencia. Cada consulta es un HTTP request. Si tu página de Laravel necesita datos de 15 posts de WordPress para renderizarse, son 15 requests o una query con paginación. Implementar caché en este nivel es obligatorio.
Para autenticación, WordPress REST API acepta Application Passwords desde WordPress 5.6. No hace falta plugin adicional para autenticar requests de Laravel. Esto se conecta con lo que analizamos en automatizar procesos con Claude.
Consideraciones de performance y seguridad
Acá es donde más gente la pifía. Y no por desconocimiento técnico, sino por descuido en la implementación.
Caché con Corcel. Corcel no tiene caché propio; cada llamada es una query a MySQL. En producción, con tráfico real, eso duele. Implementá caché en Laravel (Redis o Memcached) para queries frecuentes. Un `Cache::remember(‘posts_home’, 300, fn() => Post::published()->take(10)->get())` puede reducir el load de base de datos un 80% en páginas de alta concurrencia.
Usuario de base de datos con permisos mínimos. Si Laravel accede a la base de datos de WordPress, no uses el usuario de WordPress con todos los permisos. Creá un usuario MySQL de solo lectura si Laravel solo necesita consultar. Si necesita escribir, limitá los permisos por tabla. El `.env` de Laravel con las credenciales debe estar fuera del webroot y nunca en el repositorio.
Permisos de carpetas. `storage/` y `bootstrap/cache/` de Laravel deben ser escribibles por el servidor web pero no accesibles públicamente. Esto no es opcional.
¿Qué pasa si alguien explota una vulnerabilidad en WordPress y tiene acceso a la base de datos? Si Laravel usa el mismo servidor MySQL con el mismo usuario, la exposición es total. Separar credenciales y usar usuarios distintos por aplicación es una medida básica que muchos equipos omiten.
Casos de uso prácticos en Argentina
La arquitectura más común que se ve en proyectos argentinos de mediano tamaño es esta: WordPress en un subdirectorio o subdominio maneja el blog y el marketing. Laravel maneja el dashboard de usuario, la API, y la lógica del producto. Para más detalles técnicos, mirá crear features personalizadas.
Un portal de propiedades, por ejemplo: el blog con consejos de alquiler e inversión en WordPress (SEO incluido), el buscador de propiedades y el sistema de contacto en Laravel. Corcel le permite a Laravel mostrar los últimos posts del blog en el dashboard sin una segunda petición HTTP.
Una agencia digital con clientes en varios rubros tiene otro patrón típico: usa WordPress como constructor de sitios para sus clientes, pero construyó su propio CRM en Laravel. Con Corcel, el CRM puede leer métricas de contenido directamente desde la base de datos de cada WordPress sin APIs intermedias.
El flujo de datos suele ser unidireccional: WordPress escribe contenido, Laravel lo lee. Cuando necesitás escritura bidireccional (Laravel actualiza datos que WordPress muestra), la complejidad sube bastante y generalmente es mejor usar la REST API para eso.
Qué está confirmado / Qué no
| Aspecto | Estado |
|---|---|
| Corcel soporta WordPress 6.x con PHP 8.2 | Confirmado (mantenimiento activo en GitHub) |
| Acorn 4.x compatible con Laravel 11 | Confirmado según Roots |
| REST API de WordPress admite Application Passwords sin plugins | Confirmado desde WP 5.6 (2020) |
| Soporte de Corcel para ACF Repeater Fields | Parcial — requiere trabajo manual |
| Roadmap oficial de Acorn para WordPress 7 | Sin confirmación pública al 17/04/2026 |
Errores comunes al integrar WordPress con Laravel
Error 1: Usar el usuario de WordPress para las queries de Laravel. El usuario que WordPress usa para su base de datos tiene permisos de lectura y escritura sobre todas sus tablas. Si ese mismo usuario lo usás desde Laravel y hay una inyección SQL en tu app Laravel, la exposición incluye toda la data de WordPress. Creá un usuario separado.
Error 2: Ignorar los hooks de WordPress al escribir desde Laravel. Cuando Corcel crea o actualiza un post, no ejecuta los hooks de WordPress (`save_post`, `publish_post`, etc.). Si tenés plugins que dependen de esos hooks (caché, indexación, notificaciones), van a quedar sin ejecutarse. Para escrituras que necesiten disparar hooks, usá la REST API o wp-cli.
Error 3: No implementar caché con Corcel en producción. En desarrollo todo funciona fluido. En producción con 500 usuarios simultáneos y Corcel haciendo queries sin caché, el servidor de base de datos se satura. No es opcional. Relacionado: proteger tu sitio con WAF.
Error 4: Exponer la API REST de WordPress sin autenticación. Por defecto, endpoints como `/wp-json/wp/v2/users` devuelven información de usuarios. Si la integración vía REST API está configurada, revisá qué endpoints son públicos y cuáles requieren autenticación.
En nuestro post sobre WordPress with Laravel db encontrás más información al respecto.
Preguntas Frecuentes
¿Qué es Corcel y para qué sirve en Laravel?
Corcel es un paquete PHP que permite acceder a la base de datos de WordPress usando Eloquent ORM de Laravel. Con Corcel podés hacer queries a posts, taxonomías y meta fields de WordPress con la misma sintaxis que usarías para modelos propios de Laravel. Está disponible en GitHub bajo el paquete `jgrossi/corcel` y tiene soporte activo para WordPress 6.x y PHP 8.2.
¿Cuál es la diferencia entre Corcel y Acorn?
Corcel es un ORM: trae las tablas de WordPress a Laravel para consultarlas con Eloquent. Acorn, de Roots, es una implementación del service container de Laravel que corre dentro de WordPress, habilitando Blade templating y service providers desde el contexto de WordPress. Corcel va de WordPress hacia Laravel; Acorn lleva Laravel adentro de WordPress.
¿Cómo integro WordPress con Laravel sin compartir base de datos?
Usás la REST API de WordPress. Laravel consume los endpoints de WordPress via HTTP usando Guzzle o el HTTP Client nativo de Laravel. WordPress expone sus datos en `/wp-json/wp/v2/` y Laravel los lee sin conexión directa a MySQL. Este método es más lento (requiere caché) pero arquitectónicamente más limpio y más fácil de escalar de forma independiente.
¿Puedo escribir posts en WordPress desde Laravel con Corcel?
Podés, pero con limitaciones importantes. Corcel puede crear y actualizar registros en las tablas de WordPress, pero no ejecuta los hooks de WordPress. Plugins que dependan de `save_post` u otros hooks no van a enterarse de los cambios. Para escrituras donde los hooks importan (caché, indexación, notificaciones de plugins), la REST API autenticada es la opción correcta.
¿Es seguro compartir la base de datos entre WordPress y Laravel?
Es seguro si la configuración es correcta: usuario MySQL con permisos mínimos (idealmente solo lectura si Laravel no necesita escribir), credenciales en `.env` fuera del webroot, y never en el repositorio. El riesgo principal es una vulnerabilidad en uno de los dos sistemas que exponga la base de datos del otro. Separar usuarios de base de datos por aplicación es la medida más importante.
Conclusión
No hay un método universal para la integración WordPress y Laravel. Corcel es la opción más directa si Laravel necesita leer datos de WordPress sin montar una API. Acorn encaja cuando el proyecto vive principalmente en WordPress pero necesita la infraestructura de Laravel. La REST API es la elección para arquitecturas desacopladas o cuando los sistemas corren en servidores distintos.
Lo que sí es claro: la integración existe, está madura, y tiene casos de uso reales en producción. Antes de decidir cuál método usar, la pregunta que hay que responder es una sola: ¿los sistemas van a compartir base de datos o comunicarse por HTTP? De esa respuesta depende todo lo demás.
El setup de seguridad (usuarios de base de datos separados, caché en producción, hooks de WordPress monitoreados) no es opcional si querés que esto funcione más de dos semanas sin problemas.