Category: Programación

Para definir cómo queremos que una página web se comparta en las redes sociales se utilizan las etiquetas META de Open Graph. Así podemos definir la miniatura que queremos que aparezca cuando alguien comparta nuestra página en alguna red social.

Tanto Facebook como LinkedIn guardan en caché una copia de esta miniatura, y hacen muy bien: si una página es muy compartida no tiene sentido que cada vez que alguien la comparta descarguen la miniatura del servidor, usando un caché se ahorran (y nos ahorran) tráfico.

Ahora bien, ¿qué pasa si estamos aún en desarrollo y queremos cambiar esa miniatura? Pues que aunque cambiemos el contenido de la etiqueta META correspondiente tanto Facebook como LinkedIn siguen mostrando al compartir la página la miniatura que tenían en su caché. Y esto es algo que queda fuera de nuestro control. ¿Cómo resolverlo?

Facebook nos ofrece un modo: a través de su depurador de objetos Open Graph. Esta herramienta es una gozada. Primero porque tiene un botón para que Facebook descargue en el momento la información Open Graph de nuestra página (refrescando así su caché de nuestra miniatura). Y segundo porque nos dice un montón de cosas interesantes sobre nuestras etiquetas Open Graph, si las estamos usando correctamente, etc…

Siento si el título del artículo te ha hecho pensar que esto mismo o algo parecido se puede hacer en LinkedIn, porque no se puede. LinkedIn no ofrece ninguna forma de limpiar el caché de la miniatura de nuestra página web.

<ironía>Muy bien, LinkedIn, muchas gracias. Entiendo que es algo dificilísimo de hacer y que desde que la gente empezó a pedirlo en 2011 no habéis tenido tiempo para implementarlo. No os preocupéis, os seguiré incluyendo en mis páginas como red social aunque no me obliguen a ello mis clientes.</ironía>

Ya hablé la última vez sobre Amazon S3 y sobre lo útil que es para descargar tráfico de un servidor. Además de imágenes y vídeos también podemos subir a S3 ficheros de fuentes si nuestra página los utiliza.

Sin embargo Firefox no permite cargar fuentes de un dominio que no sea el de la página, así que nos devolverá un error en la consola como este:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at ******. This can be fixed by moving the resource to the same domain or enabling CORS

Para solucionar esto debemos entrar en S3, seleccionar nuestro bucket y pulsar en Permissions – Edit CORS configuration. Allí podremos editar la configuración en XML; yo lo tengo así:

<CORSConfiguration>
    <CORSRule>
        <AllowedOrigin>*</AllowedOrigin>
        <AllowedMethod>GET</AllowedMethod>
    </CORSRule>
</CORSConfiguration>

En el campo AllowedOrigin tengo un asterisco porque quiero que se puedan leer desde varios dominios distintos, pero si se quisiera restringir solamente a un dominio en lugar del asterisco pondríamos el dominio. Podemos tener tantos nodos CORSRule como necesitemos.

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.