Centralizar el acceso a tu aplicación PHP mediante un front controller transforma un proyecto desordenado en una arquitectura mantenible, segura y escalable. Aprenderás a unificar el punto de entrada en index.php, definir rutas en un archivo dedicado y proteger tu código moviendo lo público a una carpeta aparte. Ideal para quien construye su primer blog o sistema en PHP sin frameworks.

¿Qué es un front controller y por qué centralizar el acceso?

Un front controller es un patrón donde todas las peticiones del navegador pasan por un único archivo, normalmente index.php. En lugar de que cada clic abra un archivo distinto, tu sistema procesa todo desde el mismo punto de entrada [01:05].

Esto cambia la forma en que navegas. Antes visitabas archivos sueltos como post.php o about.php. Ahora visitas rutas que el sistema interpreta y resuelve internamente.

¿Qué hace exactamente un front controller? Recibe todas las peticiones HTTP, identifica qué ruta se solicitó y delega la respuesta al controlador correspondiente. Es el portero único de tu aplicación.

La ganancia es directa: dejas de duplicar lógica en cada archivo y empiezas a pensar en rutas, no en rutas de archivo.

¿Cómo organizar la carpeta app y los controladores?

La estructura empieza con una carpeta app que aloja la lógica del proyecto, y dentro de ella una subcarpeta controllers [01:48]. Aquí es donde por semántica renombras tu antiguo index.php a home.php, porque ese archivo ya no es un punto de entrada sino un controlador.

La lógica queda así:

• El controlador home.php se encarga de la página principal.
• Cada controlador tiene su vista correspondiente, también llamada home.
• El único punto de entrada del sistema sigue siendo index.php.

Este cambio te obliga a ajustar las rutas relativas dentro de los controladores. Si antes hacías un require desde la raíz, ahora debes salir dos niveles con ../../ para llegar a la carpeta recursos [05:55]. Es navegación de línea de comandos aplicada al código.

¿Cómo definir un sistema de rutas en PHP con un array?

La idea es desarrollar con intención: antes de escribir código, piensa qué quieres lograr. Crea una carpeta rutas y dentro un archivo web.php que retorna un array asociativo donde la clave es la URI y el valor es el controlador [02:30].

Un ejemplo de cómo se ve esa estructura:

php

<?php return [ '/' => 'home.php', '/post' => 'post.php', '/about' => 'about.php', '/enlaces' => 'enlaces.php', ]; Fíjate en un detalle clave: las rutas **no llevan `.php`** porque ya no son archivos, son rutas lógicas. El `.php` solo aparece en el nombre del controlador al que apuntan. ### ¿Cómo procesa index.php las rutas? Dentro de `index.php` el flujo es sencillo. Recuperas el array de rutas con un `require`, capturas la `URI` que se está visitando y verificas si esa URI existe como clave en el array [03:30]. El chequeo se hace con un `if`: - Si la ruta existe, haces `require` del controlador correspondiente. - Si no existe, respondes con un `exit('404')` simple para indicar que no se encontró. > **¿Por qué usar un array para las rutas?** Porque centraliza la configuración. Cuando necesites una nueva página, solo añades una entrada al array sin tocar el front controller. ## ¿Cómo proteger el proyecto con una carpeta public? Aquí aparece un problema sensible. Si alguien escribe manualmente en el navegador algo como `/rutas/web.php`, el servidor sirve ese archivo directamente sin pasar por el front controller [08:20]. Eso rompe la centralización y expone tu código. La solución es crear una carpeta `public` y mover `index.php` dentro de ella. **Desde el navegador no puedes acceder a archivos que estén fuera de `public`**, así que todo lo demás queda protegido [08:50]. Dentro de `public` solo deben vivir: - El archivo `index.php` como front controller. - Archivos CSS. - Imágenes y otros recursos estáticos. Después de mover el archivo, ajusta las rutas de `require` para salir un nivel más y llegar a la carpeta de rutas y a los controladores. Cuando intentas visitar manualmente `/rutas/web.php`, el sistema responde con tu 404 personalizado porque la condición del `if` se activa correctamente. ### ¿Por qué frameworks como Laravel y Symfony usan public? No es casualidad. Tanto **Laravel** como **Symfony** estructuran sus proyectos con una carpeta `public` por la misma razón: separar lo accesible desde el navegador de la lógica interna [09:30]. Herramientas como **Laravel Herd** funcionan sin configuración adicional precisamente porque respetan este patrón. Adoptar esta convención desde un proyecto propio te prepara para trabajar con frameworks reales sin fricción. ## ¿Qué ganas con esta arquitectura? Tu proyecto pasa de ser un conjunto de archivos sueltos a una aplicación con tres mejoras concretas: - **Front controller**: un único punto de acceso que procesa toda petición. - **Rutas centralizadas**: agregas o modificas páginas tocando solo `web.php`. - **Seguridad por estructura**: lo público está en `public`, lo demás queda fuera del alcance del navegador. Un sistema mantenible es uno que entiendes. Y solo entiendes lo que está bien organizado. El reto ahora es tuyo: adapta el blog que estás construyendo a esta arquitectura y cuéntanos en los comentarios qué parte te costó más resolver.