- ¿Por qué no entra por el if?
Este es típico: un if que controla una sóla condición. Ejemplo en PHP, pero aplicable a cualquier lenguaje -excepto Python :-)loQueSea();
if ($varControl)
hazAlgo();
otraCosa();
Al cabo de un rato piensas que si entra por el if, además debes cambiar otra variable y escribes:loQueSea();
if ($varControl)
hazAlgo();
$otraVarControl = true;
otraCosa();
Y nunca consigues que otraVarControl se quede a true. ¿Qué pasa aquí? Fácil: no hemos puesto llaves al if.
Conclusión: aunque el if sólo controle una sentencia, mejor con llaves siempre. Al final siempre va a haber más de una sentencia bajo ese if:loQueSea();
if ($varControl) {
hazAlgo();
$otraVarControl = true;
}
otraCosa(); - ¡No pilla los cambios!
Es la típica llamada de un cliente (o un jefe): ¡me has dicho que cambiaste el XXX y no lo veo, sigue como antes!
Nuestro XXX puede ser un fichero .js, un .css, una imagen o cualquier otro tipo de recurso que estamos seguros que hemos actualizado y que aún así, nos dicen que no lo ven.
A los desarrolladores web no nos gustan mucho las cachés, ni proxies, etc, y además nos conocemos todos los típicos trucos para hacer un refresco completo de la página, pero nuestros jefes, clientes y usuarios sí que utilizan cachés (en el navegador, en su proxy). Además no se saben esos "mágicos" atajos de teclado que utilizamos sistemáticamente (Ctrl-Shift-R, Ctrl-F5 en IE) para ver cómo va nuestro trabajo en el navegador.
Solución: forzar el refresco. Supongamos el siguiente HTML que incluye un .js sobre el cual hemos hecho cambios importantes:
...
Subimos el fichero actualizado al hosting o servidor de producción, hacemos la llamada o enviamos el correo de rigor ("oye, ya está hecho") y al rato tenemos el típico "yo lo veo como antes".
Nuestro fallo: presuponer que el entorno del usuario es el mismo que el nuestro. Puede que esté navegando a través de un proxy (suelen guardar en caché los elementos que le solicitan), su navegador puede estar configurado para que también "cacheé" algunos recursos, etc.
La solución más fácil es añadir un "query string" a la llamada al recurso. Esto nos garantiza que será tratado como un fichero diferente y cargado de nuevo:
...
Nos da igual cuál es esta "query string", simplemente lo que queremos es que todos los proxies, navegadores y demás clientes entiendan que es un recurso diferente. Este truco es válido para CSS, imágenes, swf. Por ejemplo, en la regla CSS:
div.cabecera {background-image: http://mi.servidor.com/img/fondo.png?r=1}
Si se tiene todo el trabajo integrado en un sistema de control de versiones, es muy útil configurar nuestro "deploy" para que este "parámetro" tome siempre el número de versión. Si estamos desarrollando la aplicación todavía, el truco infalible para que el navegador siempre lea los recursos como "nuevos" es hacer las llamadas así en nuestro fichero .php:
<script src="fichero.js?version=" type="text/javascript">
<link href="fichero.css?version=" rel="stylesheet" type="text/css" /> - Página en blanco, no se ve nada. ¿Qué falla?
Este típico error suele pasar cuando PHP está configurado para no mostrar ningún error (lo más recomendable en producción). Las soluciones son dos:- Editar el php.ini y cambiar el ajuste "display_errors" (nada recomendable).
- Escribir la siguiente instrucción para saltarnos este ajuste para un "script" en concreto:
<?php
ini_set('display_errors', 1);
// Sigue nuestro script
La función ini_set() permite ajustar parámetros de configuración para un script determinado. Es muy útil cuando algo falla y no vemos dónde.
- Los usuarios de mi aplicación no pueden hacer "login", o unos acceden al perfil del otro.
Este es un error bastante insidioso y puede tener diferentes orígenes. Hay que conocer cómo maneja PHP las sesiones: PHP asigna al usuario una 'cookie' única con el identificador de sesión. En el servidor se guardan ficheros de sesiones en un directorio, un fichero para cada sesión 'asignada' a un usuario. Problemas potenciales:- El usuario no está aceptando cookies: en este caso es imposible que PHP asocie una sesión y sus datos con un usuario. Se puede configurar para que PHP mande el identificador de sesión en la URL, pero no es nada recomendable. Se puede comprobar si el usuario acepta cookies intentando enviarle una y leyéndola a continuación. Si no la tenemos, sacamos una advertencia al usuario.
- El directorio del servidor donde se guardan las cookies no está accesible (problemas de permisos, falta de espacio, etc).
- Si tenemos una configuración con balanceo de carga (varios servidores atendiendo a la misma URL) tenemos que asegurarnos que una vez que un usuario 'entra' por un servidor, sigue siempre en el mismo servidor. Otra solución es guardar las sesiones en una base de datos en vez de almacenarlas como ficheros.
Hay muchísimos más fallos tontos que nos podemos encontrar, pero éstas son algunas de las que más tiempo me han hecho perder ;-)