Cuando el ecosistema lanza plugins para desactivar el acceso público a PHP, está admitiendo algo: que ejecutar PHP en cada visita es el problema, no la solución. La cura se llama estático.
Caché de páginas, caché de objetos, exportadores a estático, y ahora plugins cuyo único trabajo es que WordPress no se ejecute cuando entra un visitante. La industria que vive de WordPress dedica cada vez más esfuerzo a evitar que WordPress corra.
Es un dato del mercado: la arquitectura dinámica por defecto se ha convertido en el problema a resolver, incluso dentro del propio ecosistema.
La idea es razonable: servir HTML pregenerado al visitante y dejar el PHP solo para el panel de administración. Funciona, con coste: otra capa que configurar, otro modo de fallo, y el panel sigue siendo el mismo PHP de siempre con su misma superficie de ataque.
Lo revelador no es la técnica, es la dirección: todos los caminos convergen en generar antes y servir estático. Que es exactamente lo que un generador de sitios estáticos hace por diseño, sin capas añadidas sobre un CMS que no fue pensado así.
No necesitas parchear un CMS dinámico para conseguir lo que la plataforma adecuada te da de serie: edición cómoda en un panel, compilación del sitio completo y HTML estático servido al visitante. Sin PHP expuesto, sin caché que configurar, sin capas.
Cuando el parche y la cura hacen lo mismo, la pregunta es por qué seguir pagando el parche. La cura, explicada punto por punto y con el método de migración, es la alternativa a WordPress para pymes.
Si ya has instalado (o estás pensando instalar) un plugin para servir tu WordPress como estático, hablemos: hay un camino más corto al mismo destino.
