Un alojamiento compartido

Un sitio hecho con Ehundu es HTML, CSS e imágenes: el servidor no ejecuta nada. Por eso funciona en cualquier alojamiento compartido, hasta en el más básico, aunque solo ofrezca FTP y no tenga PHP 8.4. Lo único que necesita PHP 8.4 es compilar, y eso lo haces donde quieras.

Dónde compilar¶

Lo normal es en tu ordenador. Compilas, despliegas por FTP o SFTP (la guía Desplegar el sitio lo cuenta) y el servidor solo recibe el resultado. Necesitas PHP 8.4 con mbstring y, para desplegar por FTP, las extensiones ftp y openssl. Lo compruebas así:

php -v
php -m

Si tienes SSH, también puedes compilar en el propio servidor: subes ehundu.phar y lo ejecutas allí con el destino carpeta, que copia el sitio a la raíz web. Ojo, que la versión de PHP de la línea de órdenes no tiene por qué ser la de la web: muchos alojamientos tienen varias y la de la consola es la antigua. Mira php -v antes de nada.

Y hay una tercera, para quien monta un panel: compilar desde un proceso web, al pulsar un botón. Ahí el límite de tiempo es real, y la biblioteca reparte el trabajo en varias llamadas. Está en la biblioteca y en la compilación.

Cuánta memoria¶

Un alojamiento compartido suele limitar la memoria de PHP (memory_limit). En el sitio más grande que hemos probado, de 1.204 páginas, el pico es de 170 MB en la primera compilación; uno de unos cientos de páginas necesita bastante menos. Son medidas de una sola máquina, no una promesa. Si PHP se queda sin memoria, sube el límite solo para esa orden:

php -d memory_limit=512M ehundu.phar compilar

El .htaccess¶

Con Apache, un fichero .htaccess en la carpeta del sitio configura el servidor sin tocar nada más. Pones el tuyo en publico/ y Ehundu lo copia tal cual a la raíz, como el resto de lo que hay ahí. Tres cosas que casi siempre querrás.

La página de error. Escribe la página con url: /404.html en su front matter y dile a Apache que la use:

ErrorDocument 404 /404.html

Las direcciones que cambian. Si una página se mueve, la antigua redirige a la nueva con un 301, y ni los buscadores ni quien la tenga en favoritos se pierden:

Redirect 301 /servicios-antiguos/ /servicios/

Y la caché. Si usas css_fichero() o js_fichero(), el nombre del fichero es la huella de su contenido y cambia cuando él cambia, así que el navegador puede guardarlo un año:

<FilesMatch "^[0-9a-f]{10}\.(css|js)$">
  Header set Cache-Control "public, max-age=31536000, immutable"
</FilesMatch>

Algunos alojamientos ponen un proxy delante de Apache, y entonces %{HTTPS} no llega nunca como on: una regla del tipo «si no es HTTPS, redirige» entra en bucle. La redirección de http a https es mejor hacerla en el panel del alojamiento. Y si tu servidor no es Apache, el .htaccess no le dice nada: la configuración equivalente va donde te diga su documentación.

Lo que un sitio estático no tiene¶

No tiene PHP en el servidor, así que un formulario no se procesa ahí. Necesitas un servicio que reciba el envío y te lo mande por correo; Ehundu no incluye ninguno. Lo mismo vale para un buscador o cualquier cosa que tenga que ejecutarse al visitar la página: se resuelve con un servicio externo, no con el sitio.

La primera vez que despliegas sobre un alojamiento que ya tenía una web, los ficheros de la anterior se quedan donde estaban hasta que los quites a mano. Ehundu solo borra lo que subió él.