Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/jpbarbatic/webapp/llms.txt

Use this file to discover all available pages before exploring further.

WebApp Admin Panel requiere Apache como servidor web en producción para que funcionen las URLs limpias, las páginas de error personalizadas y la seguridad básica del directorio. Toda la configuración específica de la aplicación se centraliza en el archivo public/.htaccess, que Apache procesa automáticamente al recibir cada petición, siempre que el módulo mod_rewrite esté activo y la directiva AllowOverride permita la lectura de archivos .htaccess.

Requisitos de Apache

Para que la configuración funcione correctamente necesitas:
  • mod_rewrite habilitado (a2enmod rewrite en Debian/Ubuntu).
  • mod_php o php-fpm para ejecutar los scripts PHP.
  • La directiva AllowOverride All configurada en el bloque <Directory> que corresponde al DocumentRoot de la aplicación. Sin esta directiva, Apache ignorará el archivo .htaccess y las reglas de reescritura no tendrán efecto.

Contenido de .htaccess

El archivo .htaccess se encuentra en public/.htaccess y contiene las siguientes directivas:
Options -Indexes

RewriteEngine On

RewriteRule ^([a-z]+)/([0-9]+)$ $1/editar.php?id=$2 [QSA,L]
RewriteRule ^([a-z]+)/nuevo$ $1/nuevo.php [QSA,L]


ErrorDocument 404 /iaw/repaso/web/public/error.php
ErrorDocument 403 /iaw/repaso/web/public/error.php

Explicación de cada directiva

Options -Indexes

Desactiva el listado automático del contenido de los directorios. Sin esta directiva, si un visitante accede a una URL que corresponde a un directorio sin archivo index.php o index.html, Apache mostraría un listado de todos los archivos presentes, lo que supone un riesgo de seguridad. Con -Indexes, Apache devuelve un error 403 Forbidden en su lugar.

RewriteEngine On

Activa el motor de reescritura de URLs de Apache (mod_rewrite). Es obligatorio que aparezca antes de cualquier directiva RewriteRule. Sin esta línea, todas las reglas siguientes serían ignoradas.

RewriteRule ^([a-z]+)/([0-9]+)$

Implementa las URLs limpias para la edición de registros existentes. Transforma una URL como /productos/42 en la llamada interna productos/editar.php?id=42 sin que el usuario vea la URL real.
  • El primer grupo de captura ([a-z]+) corresponde al nombre del módulo (por ejemplo productos, usuarios).
  • El segundo grupo ([0-9]+) captura el identificador numérico del registro.
  • El flag QSA (Query String Append) preserva los parámetros GET adicionales que pudiera llevar la URL original.
  • El flag L (Last) indica a Apache que deje de evaluar reglas adicionales si esta coincide.

RewriteRule ^([a-z]+)/nuevo$

Implementa las URLs limpias para la creación de nuevos registros. Transforma /productos/nuevo en productos/nuevo.php.
  • El grupo de captura ([a-z]+) identifica el módulo.
  • Los flags QSA y L tienen el mismo comportamiento que en la regla anterior.

ErrorDocument 404 y ErrorDocument 403

Redirigen los errores HTTP 404 (No encontrado) y 403 (Acceso prohibido) a la página de error personalizada de la aplicación error.php. Esto permite mostrar un mensaje de error coherente con el diseño del panel en lugar de la página de error predeterminada de Apache.
Las rutas actualmente codificadas en las directivas ErrorDocument apuntan a /iaw/repaso/web/public/error.php, que corresponde a un entorno de desarrollo concreto. Debes actualizar estas rutas para que coincidan con la ruta real de tu despliegue antes de poner la aplicación en producción. Por ejemplo, si el DocumentRoot es /var/www/webapp/public, la ruta correcta sería:
ErrorDocument 404 /error.php
ErrorDocument 403 /error.php
Si la aplicación está instalada en un subdirectorio, ajusta la ruta en consecuencia, por ejemplo /webapp/public/error.php.

DocumentRoot

Apache debe apuntar al subdirectorio public/ como raíz del servidor web, no a la raíz del proyecto. De este modo, los archivos de configuración (config.php, .env, composer.json, etc.) y las dependencias (vendor/) quedan fuera del alcance directo del servidor HTTP. A continuación se muestra un ejemplo mínimo de VirtualHost para Apache:
<VirtualHost *:80>
    ServerName miapp.local
    DocumentRoot /var/www/webapp/public
    <Directory /var/www/webapp/public>
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>
Después de crear o modificar el archivo de VirtualHost, recarga la configuración de Apache:
sudo a2ensite miapp.local.conf
sudo systemctl reload apache2

Activos estáticos

Los activos estáticos de la aplicación se sirven directamente por Apache sin pasar por PHP. Los archivos de Bootstrap, la hoja de estilos personalizada y el widget meteorológico se encuentran bajo public/assets/; las imágenes de productos y usuarios se almacenan directamente bajo public/imagenes/:
RutaContenido
public/assets/bootstrap/dist/css/Archivos CSS compilados de Bootstrap 5 utilizados en todas las vistas del panel.
public/assets/bootstrap/dist/js/Archivos JS compilados de Bootstrap 5 utilizados en todas las vistas del panel.
public/assets/dashboard.cssHoja de estilos personalizada que complementa Bootstrap con los estilos específicos del panel de administración.
public/assets/weather-widget.jsScript JavaScript del lado del cliente que gestiona el widget meteorológico del panel principal.
public/imagenes/productos/{id}/Fotografías de productos subidas a través del panel. Cada producto tiene su propio subdirectorio identificado por su id.
public/imagenes/usuarios/Fotografías de perfil de los usuarios registrados en el sistema.
Las directivas ErrorDocument del archivo .htaccess no funcionan con el servidor integrado de PHP (php -S). Durante el desarrollo local con npm run serve (que ejecuta php -S 0.0.0.0:9000 -t public), los errores 404 y 403 mostrarán la respuesta predeterminada del servidor integrado en lugar de la página error.php. Este comportamiento es exclusivo del entorno de desarrollo; en producción con Apache las directivas funcionan correctamente.

Build docs developers (and LLMs) love