Koas.dev

Una nota rápida para no tirarme media hora en el futuro sufriendo por esto…

Firefox tiene un bug muy curioso: si intentamos posicionar elementos de forma absoluta dentro de una celda (ya sea una celda de tabla normal o un div con estilo display:table-cell) él amablemente nos enseña el dedo más largo de su peluda patita y los coloca con respecto al primer elemento de fuera de la tabla.

Para evitarlo hay que crear como primer hijo de la celda un div con posición relativa que ocupe todo el ancho y alto de la celda, y meter dentro de él los elementos que queramos posicionar de forma absoluta. Entonces sí funciona.

Hay veces en las que debemos realizar alguna tarea con PHP que lleva demasiado tiempo (convertir imágenes, videos, etc…). En estos casos no es elegante dejar esperando al usuario, es preferible redirigirle a una página donde se le informe de que se está llevando a cabo la tarea.

Una solución podría ser implementar un sistema de workers que realicen el trabajo; así nuestro script de PHP simplemente tendría que lanzar el trabajo y terminaría inmediatamente. Esta es la mejor solución porque los sistemas de workers permiten un escalado horizontal.

Pero hay ocasiones en las que por las características de nuestro proyecto no se pueden o no se quieren implementar estos workers. En estos casos nos bastará con redirigir al usuario a una página informativa y realizar el trabajo desde nuestro script de PHP.

Esta técnica la encontré, y está perfectamente documentada, en esta página, que podéis consultar para una explicación detallada. Aquí me limito a copiar el código:

    //Redirect to messageToUser.php
    header("Location: messageToUser.php");
    //Erase the output buffer
    ob_end_clean();
    //Tell the browser that the connection's closed
    header("Connection: close");

    //Ignore the user's abort (which we caused with the redirect).
    ignore_user_abort(true);

    //Extend time limit to 30 minutes
    set_time_limit(1800);
    //Extend memory limit to 10MB
    ini_set("memory_limit","10M");
    //Start output buffering again
    ob_start();

    //Tell the browser we're serious... there's really
    //nothing else to receive from this page.
    header("Content-Length: 0");

    //Send the output buffer and turn output buffering off.
    ob_end_flush();
    //Yes... flush again.
    flush();

    //Close the session.
    session_write_close();

    //Do some work

    //Then notify the user that it's finished

Actualización 14/09/2021: si usamos PHP-FPM hay una función que nos permite cerrar la conexión con el navegador y seguir haciendo lo que queramos en nuestro código, fastcgi_finish_request.

Últimamente he estado viendo en bastantes sitios que los enlaces a documentos externos se escriben sin especificar el protocolo. Es decir, en lugar de escribir

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.11.0/jquery.min.js"></script>

escribiríamos esto

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.11.0/jquery.min.js"></script>

Así a bote pronto me ha chocado un poco, porque de toda la vida yo pensaba que era el http:// lo que distinguía a un enlace externo de uno que hacía referencia a un documento dentro del árbol de ficheros de nuestra página.

Pero por lo visto resulta que es el // lo que hace que el navegador interprete el enlace como externo, por lo que nos podemos ahorrar el http o https en la URL siempre que queramos que el enlace use el protocolo http y no otros como ftp, mailto, o tel.

Además tenemos una ventaja añadida si quitamos el protocolo: el navegador usará el protocolo que esté usando la página en la que está el enlace. Si hemos accedido a ella mediante http usará http, y si hemos accedido mediante https usará https. Esto significa que si estamos cargando un fichero con http (contenido no seguro) en una página cargada con https (contenido seguro) el navegador no protestará (que yo recuerde esto solamente lo hace Internet Explorer).

Actualización del 17/11/2015: no es solo Internet Explorer, otros navegadores también bloquean por ejemplo ficheros de JS cargados desde una URL no segura si se ha accedido a la página a través de una URL segura. Un motivo más para usar esta forma de escribir las URL.

En las páginas que están en producción es conveniente minimizar el código JavaScript y el CSS para que pesen menos y ayuden a que la velocidad de carga de la página sea rápida. Si bien los navegadores cachean estos ficheros y esto solamente se aplica a la primera carga siempre conviene que sea lo más rápida posible (además de reducir el ancho de banda que consumimos en nuestro servidor).

Hay muchos minimizadores de código JavaScript y de CSS, yo uso JavaScript Minifier simplemente porque tiene un enlace en la misma página a su minimizador de CSS, y hace todo el proceso más rápido.