¿Se puede construir en una tarde un tema propio de WordPress, desplegarlo en un hosting compartido, añadir varios idiomas y evitar horas de trabajo repetitivo? En mi caso, sí.
Migré mi portfolio desde la pesada plantilla Porto a un tema propio basado en WordPress Bedrock, monté el entorno local con Docker, usé Polylang para cuatro idiomas, lo desplegué en Hostinger y delegué buena parte del trabajo mecánico a Claude Code.
Por qué elegí Bedrock
Bedrock convierte WordPress en un proyecto más serio: dependencias gestionadas con Composer, configuración por entorno, separación clara entre core y código propio, y un despliegue mucho más predecible.
- Composer controla core, plugins y temas.
- La configuración vive en `.env` y `config/`.
- El código del proyecto está en `web/app/` y el core en `web/wp/`.
- Los secretos quedan fuera del document root.
Entorno local con Docker
En local utilicé Docker con contenedores para PHP/Apache y MySQL. Eso me permitió acercarme mucho al entorno de producción y reducir el riesgo de diferencias entre desarrollo y servidor.
make init
make up
make down
make shell
make wp CMD="plugin list"La ventaja real no es solo la comodidad, sino la reproducibilidad: cualquier desarrollador o agente de IA trabaja sobre el mismo stack.
Un tema propio sin exceso de JavaScript
Porto hacía demasiadas cosas para un sitio de portfolio. Cargaba mucho JavaScript, dependía de jQuery, generaba HTML innecesario y dejaba poco control sobre el rendimiento final.
La nueva versión se diseñó con una idea muy clara: CSS moderno, HTML limpio y el mínimo de dependencias posible.
- `clamp()` para tipografía fluida
- CSS variables para el sistema visual
- Grid y Flexbox para la maquetación
- eliminación de jQuery y de estilos front-end innecesarios
Texto editable con el Customizer
En un sitio multilingüe, dejar textos dispersos dentro de las plantillas es una mala idea. Por eso centralicé todo el contenido textual en un único archivo de configuración para el Customizer.
return [
'shared' => [...],
'en' => [...],
'ru' => [...],
'uk' => [...],
'es' => [...],
];Las funciones helper detectan el idioma actual con Polylang, construyen la clave correcta y leen el valor desde `get_theme_mod()` con fallback seguro.
Polylang y URLs limpias
No solo quería traducciones, también quería URLs limpias: `/ru/`, `/uk/`, `/es/`, con inglés como idioma por defecto sin prefijo. Polylang resuelve gran parte de esto, pero hubo que ajustar el comportamiento de WordPress.
El problema más delicado fue `redirect_canonical`, que a veces intentaba simplificar la URL y eliminaba el prefijo de idioma. Lo corregí con un pequeño mu-plugin que desactiva ese redirect cuando la raíz de idioma es válida.
Qué aportó Claude Code
La arquitectura no la decidió la IA. La dirección técnica, la revisión y las decisiones delicadas siguieron siendo humanas. Pero Claude Code fue muy eficaz en tareas precisas y repetitivas.
- extracción de cientos de strings al config del Customizer
- refactor simultáneo de varias plantillas
- apoyo al depurar Polylang y redirects
- generación de bloques técnicos como JSON-LD
El resultado fue una reducción real del tiempo de entrega. Lo que antes habría ocupado varios días se convirtió en unas pocas horas de trabajo concentrado.
Despliegue en Hostinger con Git
En producción el flujo fue muy directo: acceso por SSH, `git pull`, `composer install –no-dev` y verificación manual. Bedrock encaja muy bien con este tipo de despliegue porque el proyecto ya está estructurado como una aplicación.
Resultados
- menos peso de página
- mejores métricas de Lighthouse
- prácticamente sin JavaScript en el front-end
- cuatro idiomas conectados correctamente con Polylang
- cientos de textos editables desde administración
Guía rápida para empezar
- Instalar Git, Docker y Composer.
- Crear o clonar un proyecto Bedrock.
- Levantar el entorno con `make init`.
- Construir el tema en `web/app/themes/`.
- Configurar Polylang y validar las URLs por idioma.
- Desplegar por SSH y Git en lugar de usar FTP manual.
Conclusión
AI-assisted WordPress development ya es totalmente práctico. Pero la calidad no aparece sola: hace falta una arquitectura clara, criterio técnico y revisión seria.
Si tuviera que repetir este proyecto, volvería a elegir Bedrock, Docker, Polylang y un asistente de IA para la parte repetitiva de la implementación. Esa combinación me dio velocidad sin perder control técnico.
