En septiembre de 2026 separé la portada de criver.site de WordPress. No abandoné WordPress: sigue siendo mi CMS para artículos. La portada, en cambio, pasó a HTML/CSS/JavaScript estático y ahora se despliega automáticamente desde GitHub a Xserver.
La razón fue práctica. A medida que creaba juegos y pequeñas aplicaciones web, dejó de tener sentido que la entrada del sitio, el blog y los propios productos dependieran de la misma capa de WordPress.
Qué me estaba causando problemas
Cuando todo vivía en WordPress, un cambio de tema o plugin podía afectar la portada. Además, subir código a GitHub no significaba que producción ya estuviera actualizada. Durante la etapa de subidas manuales con FileZilla, GitHub podía tener la versión nueva mientras el servidor seguía usando archivos antiguos.
La estructura actual
- Portada: HTML/CSS/JavaScript estático
- Código fuente: GitHub
- Despliegue: GitHub Actions → Xserver
- Artículos: WordPress
- Juegos y apps: independientes de WordPress
La lección principal: push no es deploy
Al empezar con Git, casi trataba “push a GitHub” como “web actualizada”. Durante el desarrollo de ORA Quest comprobé que el JavaScript podía estar corregido en local y en GitHub mientras producción seguía sirviendo una versión antigua.
Desde entonces, comprobar la URL real forma parte del despliegue.
La automatización también falla
He configurado mal un host FTPS y provocado un error SSL. También he visto cachés mantener JavaScript antiguo. La automatización no elimina los fallos, pero permite localizar mejor si el problema está en la conexión, la transferencia, la caché o la verificación final.
Separar responsabilidades ayudó mucho
Ahora la portada se centra en ser una entrada a mis proyectos, como ORA Quest y el juego de memoria de un minuto Oboete Iruka?. WordPress se centra en publicar y ordenar artículos.
En mi caso, la mejor solución no fue elegir entre “todo WordPress” o “nada WordPress”, sino combinar ambos enfoques.
コメント