ENTORNO APACHE + PHP Y PRIMER SCRIPT¶

Estos apuntes son material de consulta para el Lab 01 y los siguientes. Asumen que ya conoces Apache y sabes configurar VirtualHost de trabajos anteriores; aquí nos centramos en los conceptos específicos de PHP como lenguaje de servidor.

PHP como lenguaje de servidor¶

Los lenguajes de servidor se ejecutan en la máquina servidor para generar contenido dinámico antes de enviarlo al navegador. PHP es el más extendido en hosting tradicional tipo LAMP.

Lenguaje	Entorno habitual
PHP	Apache/Nginx + `mod_php` o PHP-FPM
Python	Flask, Django, FastAPI
JavaScript	Node.js

Cliente vs servidor

HTML, CSS y JavaScript se ejecutan en el navegador del usuario. PHP se ejecuta en el servidor: el usuario nunca ve el código PHP, solo el HTML que el servidor le devuelve.

Ciclo de una petición PHP¶

Cuando el navegador solicita un fichero .php, el proceso es:

El navegador envía GET /listado.php HTTP/1.1 al servidor.
Apache detecta la extensión .php y pasa el fichero al intérprete PHP a través del módulo libapache2-mod-php.
PHP ejecuta el script de arriba a abajo y construye la respuesta HTML.
Apache devuelve el HTML al navegador.

PHP ejecuta el script completo de nuevo en cada petición. No hay estado entre peticiones (HTTP es stateless) salvo lo que se guarde explícitamente en sesión, cookie o fichero.

Apache + módulo PHP¶

En el stack LAMP, PHP no es un servicio independiente: vive dentro de Apache a través del módulo libapache2-mod-php. Una vez instalado el módulo, Apache envía automáticamente cualquier fichero con extensión .php al intérprete PHP. No hay que configurar nada adicional.

Herramientas rápidas para comprobar el entorno:

Comando	Para qué sirve
`apache2 -v`	Versión de Apache instalada
`php -v`	Versión de PHP instalada en CLI
`php -l fichero.php`	Valida la sintaxis del fichero sin ejecutarlo (lint)

`phpinfo()` — radiografía de PHP¶

La función phpinfo() imprime una página HTML con toda la configuración de PHP activa: versión, extensiones cargadas, directivas de php.ini, rutas internas, variables de entorno. Es la forma estándar de comprobar que Apache está ejecutando PHP correctamente y de consultar el valor por defecto de una directiva.

<?php phpinfo();

Mala práctica: dejar phpinfo() accesible en producción

phpinfo() expone información sensible — rutas absolutas del servidor, versiones exactas de módulos, extensiones, variables de entorno. Un atacante que vea esa página sabe exactamente qué vulnerabilidades conocidas probar.

## Incorrecto: dejar info.php en el DocumentRoot tras verificar
<?php phpinfo();   // fichero olvidado en /var/www/html/info.php

## Correcto: úsalo como herramienta de diagnóstico temporal
sudo rm -f /var/www/html/info.php

Estructura de proyecto con `public/`¶

Un error frecuente es colocar toda la aplicación directamente en el DocumentRoot de Apache. Cualquier fichero allí es accesible por URL, incluidos los datos y la lógica interna. La solución estándar es el patrón de document root pequeño:

gestor/
├── public/        ← único directorio accesible por URL (DocumentRoot)
├── src/           ← lógica PHP reutilizable (funciones, helpers)
├── templates/     ← cabeceras y pies HTML comunes
└── data/          ← datos persistentes (JSON, etc.)

Carpeta	Contiene	Accesible por navegador
`public/`	`index.php`, `listado.php`, hojas CSS, imágenes	Sí
`src/`	Funciones y clases PHP que se incluyen desde `public/`	No
`templates/`	Fragmentos HTML/PHP reutilizables (`_header.php`, `_footer.php`)	No
`data/`	Ficheros de datos leídos y escritos por la aplicación	No

Apache se configura con un VirtualHost cuyo DocumentRoot apunta directamente a public/. El resto de carpetas quedan por encima del DocumentRoot y por tanto no son accesibles por URL, aunque PHP sí puede leerlas y escribirlas desde dentro del servidor.

Permisos de escritura en data/

Los ficheros PHP se ejecutan bajo el usuario del proceso Apache (habitualmente www-data). Para que un script pueda escribir en data/, ese usuario debe tener permiso de escritura sobre el directorio. En desarrollo basta con dejar data/ escribible por www-data; el resto del proyecto puede mantenerse con tu usuario para editar cómodamente.

Mala práctica: mezclar datos y código publicado

## Incorrecto: incidencias.json accesible vía URL
public/
├── listado.php
└── incidencias.json   ← cualquiera puede abrir http://.../incidencias.json

## Correcto: datos fuera del DocumentRoot
public/listado.php
data/incidencias.json   ← solo PHP puede leerlo, no el navegador

Bloques PHP dentro de HTML¶

Un fichero .php puede mezclar PHP y HTML libremente. Todo lo que va entre <?php y ?> lo ejecuta el intérprete de PHP; lo que queda fuera pasa tal cual al navegador.

Sintaxis básica¶

<?php
$titulo = 'Gestor de incidencias';
$ahora  = date('d/m/Y H:i');
?>
<!doctype html>
<html lang="es">
<body>
  <h1><?= htmlspecialchars($titulo, ENT_QUOTES, 'UTF-8') ?></h1>
  <p>Fecha del servidor: <?= htmlspecialchars($ahora, ENT_QUOTES, 'UTF-8') ?></p>
</body>
</html>

Observa la estructura: el bloque PHP al inicio calcula los datos, y el HTML de abajo los muestra. Esta separación entre lógica y presentación es el patrón que seguirás en todos los labs de la unidad.

`echo` y la forma corta `<?= ?>`¶

Las dos formas siguientes son equivalentes:

<?php echo htmlspecialchars($titulo); ?>
<?= htmlspecialchars($titulo) ?>

La forma corta <?= ... ?> se usa dentro del HTML porque es más legible. Internamente aplica echo al resultado de la expresión.

Variables y paralelismo con bash¶

Las variables en PHP empiezan por $ y las instrucciones acaban en ;.

Bash	PHP
`titulo="Impresora"`	`$titulo = 'Impresora';`
`echo "$titulo"`	`echo $titulo;`

Diferencias: PHP sí distingue mayúsculas ($var ≠ $Var), el ; es obligatorio, las operaciones aritméticas se escriben directamente ($a + $b, no $((a+b))).

Funciones de introspección del servidor¶

PHP ofrece funciones y constantes para consultar información sobre el servidor y el entorno de ejecución. Son útiles para scripts de diagnóstico y para depurar.

Función / constante	Devuelve
`date('d/m/Y H:i')`	Fecha y hora actuales con el formato indicado
`phpversion()`	Versión exacta de PHP (p. ej. `"8.3.6"`)
`gethostname()`	Nombre del host del servidor
`PHP_OS`	Sistema operativo donde corre PHP (p. ej. `"Linux"`)
`__DIR__`	Directorio absoluto del fichero actual
`get_current_user()`	Usuario propietario del fichero PHP que se ejecuta
`php_sapi_name()`	Interfaz que invoca a PHP (`"apache2handler"`, `"cli"`, etc.)

get_current_user() no devuelve www-data

Aunque Apache ejecuta el script bajo el usuario www-data, get_current_user() devuelve el usuario propietario del fichero PHP, no el usuario del proceso. Si tu fichero index.php lo creaste tú, verás tu nombre de usuario.

Para saber bajo qué usuario se está ejecutando el proceso en realidad, mira phpinfo() (sección "Environment", variable USER) o usa extensiones como posix.

Escape de salida: protegerse de XSS¶

Siempre que una variable se imprime dentro de HTML, hay que escaparla primero. Si no, un valor malicioso puede romper el HTML o inyectar código JavaScript en la página.

Qué es XSS¶

Cross-Site Scripting (XSS) es una vulnerabilidad en la que un atacante consigue que el navegador de la víctima ejecute JavaScript arbitrario. El vector más común es imprimir datos del usuario sin escapar:

// Suponiendo que $titulo llega del usuario:
$titulo = '<script>alert("hackeado")</script>';
echo "<h1>$titulo</h1>";   // el navegador ejecuta el <script>

`htmlspecialchars()`¶

Convierte los caracteres que tienen significado especial en HTML a sus entidades seguras:

Carácter	Se convierte en
`<`	`<`
`>`	`>`
`"`	`"`
`'`	`'`
`&`	`&`

Firma completa recomendada: htmlspecialchars($valor, ENT_QUOTES, 'UTF-8'). El segundo argumento escapa también las comillas simples (útil dentro de atributos) y el tercero fija la codificación.

Mala práctica: imprimir variables sin escapar

## Incorrecto: cualquier < o > del usuario se interpreta como HTML
echo "<h1>$titulo</h1>";

## Correcto: escapar siempre al imprimir
echo "<h1>" . htmlspecialchars($titulo, ENT_QUOTES, 'UTF-8') . "</h1>";

Qué escapar y qué no

Sí escapa: cualquier cadena que vayas a imprimir dentro de HTML (valores de formularios, campos de una ficha, URLs de usuario…).
No hace falta escapar: números enteros y decimales que controles tú mismo, pues no pueden contener caracteres HTML peligrosos.

En el Lab 07 crearás un helper e() que encapsula la llamada para no repetirla en cada plantilla.

Depuración y logs¶

Errores de PHP durante el desarrollo¶

Por defecto, PHP no muestra errores en el navegador (configuración pensada para producción): los escribe silenciosamente en el log y al usuario le devuelve una página genérica o en blanco. Durante el desarrollo necesitas verlos para poder corregirlos.

Activa los errores al inicio del script:

<?php
error_reporting(E_ALL);
ini_set('display_errors', '1');

// ... tu código ...

error_reporting(E_ALL) activa todos los niveles de aviso (avisos, advertencias, errores).
ini_set('display_errors', '1') los muestra en la respuesta HTML.

Mala práctica: display_errors en producción

## Incorrecto: cualquier error expone rutas internas, nombres de variables, SQL...
ini_set('display_errors', '1');   // en un servidor público

## Correcto: en producción, solo logs
ini_set('display_errors', '0');
ini_set('log_errors', '1');
// los errores quedan en /var/log/apache2/error.log

Leer un error de PHP¶

Un mensaje típico tiene la forma:

Parse error: syntax error, unexpected token "$alumno", expecting "," or ";"
in /home/tuusuario/gestor/public/index.php on line 6

Te indica qué falla (token inesperado), dónde (ruta completa del fichero) y en qué línea. Leer el mensaje entero resuelve el 80 % de los errores antes de tener que buscar en Google.

Log de Apache¶

Los errores de PHP y los errores del propio Apache se escriben en:

/var/log/apache2/error.log

Durante el desarrollo es útil seguir el log en tiempo real mientras trabajas en otra terminal:

sudo tail -f /var/log/apache2/error.log

Cada recarga de una página con error añade una línea nueva al final del fichero.

Validación sintáctica con `php -l`¶

Antes de probar un fichero en el navegador puedes comprobar que al menos no tiene errores de sintaxis:

php -l public/index.php

Si la sintaxis es correcta: No syntax errors detected in public/index.php.
Si hay un error: devuelve el mismo formato que verías en el navegador, con fichero y línea.

Es un chequeo rápido que puedes automatizar en el flujo de trabajo antes de entregar el lab o publicar un cambio.