A vueltas con los gif.

@Ashdown Te van a decir lo de siempre, que vayas aquí:

ucp.php?i=prefs&mode=view

y los desactives. Lo malo es que te los desactiva del ordenador también. Yo este verano que he estado con el móvil el 90% del tiempo en EOL lo he agradecido, pero lo he quitado ya porque en PC me parece molesto

Ya, però eso es machetazo a todas las imágenes. Yo lo que quería decir es pasarle la afeitadora solo a los gif, que son los que se pueden salir de madre con el tamaño.

Además de lo que ha dicho Senegio, yo creo que no es posible cargar las imágenes selectivamente: hay que descargarla primero para saber qué es, y entonces ya no sirve de mucho

No digo que lo implementes, que generaría tráfico, ni sé si se puede, pero hacer un HEAD en PHP a la url externa enmarcada entre 2 [img][/img] dará un content-type y content-length para discernir el tipo de imagen y el tamaño, respectivamente, podría ser una posibilidad.

Hay mucho servidor raro por ahí fuera que se pasan el mime-type por..., pero respecto a tamaño, no sería mala idea. Filtrar en base a un tamaño. Incluso daría igual el tipo, porque se cuelgan algunas imágenes JPG, que ojito también.

Por ejemplo, para mí, con 3-4MB de GIF, ya es demasiado. El que quiera más, que ponga un enlace.

(Veo que sí se puede hacer) Se podría hacer antes de enviar un mensaje, para advertir y evitar, o cada vez que cargue la página para no cargar y poner sólo el enlace con la razón de por qué no se carga la imagen.

EDIT: se me olvidaba el enlace:
http://pear.php.net/manual/en/package.h ... 2.head.php


Voy a tener que empezar a cobraros por daros ideas...

@melado ¿Y no podrías hacer una función que, con la pestaña activada, convierta el texto ".gif" en ". gif" (es decir, con un espacio) para que no cargue la etiqueta [img]?

No sé, se me ocurre eso xD

O que sólo te oculte los [img] que contengan ".gif" en su enlace

La extensión no es algo definitivo.

Sin ir más lejos, los avatares en esta web no tienen extensión

A la hora de la verdad lo que importa es el mime type, si se respeta...

Sin irnos otra vez, mucho más lejos, esta web los envía en binario.

En último término, la interpretación del navegador al leer las cabeceras es lo que determina su representación.


Además, ¿qué sentido tiene bloquear absolutamente todos los GIFs? El problema son los mega archivos que algunos ponen.

JohnH escribió:No digo que lo implementes, que generaría tráfico, ni sé si se puede, pero hacer un HEAD en PHP a la url externa enmarcada entre 2 [img][/img] dará un content-type y content-length para discernir el tipo de imagen y el tamaño, respectivamente, podría ser una posibilidad

Precargar desde el servidor todas las imágenes que se ponen en el foro es una locura, lo siento xD

Hay mucho servidor raro por ahí fuera que se pasan el mime-type por..., pero respecto a tamaño, no sería mala idea. Filtrar en base a un tamaño. Incluso daría igual el tipo, porque se cuelgan algunas imágenes JPG, que ojito también.

Esa es otra, muchos servidores mienten, así que además de ser una locura sería poco útil un porcentaje importante de las veces.

Senegio escribió:@melado ¿Y no podrías hacer una función que, con la pestaña activada, convierta el texto ".gif" en ". gif" (es decir, con un espacio) para que no cargue la etiqueta [img]? O que sólo te oculte los [img] que contengan ".gif" en su enlace

Las extensiones no determinan el tipo del archivo. Mira, un GIF que termina en JPG xD


El problema al final es que todo esto que sugerís está fuera del alcance de lo que debería hacer un foro. Es una función que debería implementarse en los navegadores, sea con algo tan básico como desactivar las imágenes o mediante una extensión que haga alguna de las cosas que proponéis.

@melado Primera noticia xD, siempre linkeo gifs que tienen extensión .gif jaja.

Pues no sé entonces. Es que es un problema en versión móvil tragarte algunas imágenes o gif por sorpresa que acaban con tus MB. Sobretodo en el subforo de PC, que estás leyendo un hilo y... ¡zas! te comes unas cuantas imágenes a 4K y de tropecientos MB cada una, por mucho que estén ocultas en una etiqueta spoiler xD.

Senegio escribió:@melado Primera noticia xD, siempre linkeo gifs que tienen extensión .gif jaja.

Es que la inmensísima mayoría de los gifs que se puedan postear aquí, van a tener extensión gif.
Ya propuse un par de alternativas, pero no hilo_imagenes-y-version-movil_2091011

@Gaiden Lo sé, te leí en su momento, y otros muchos más hilos que hemos/han abierto con cosas del estilo.

Aunque sea poco prioritario pienso que es una cosa que se debería tener en cuenta y añadirlo a la lista de futuribles (como la opción de mensajes más valorados en un hilo hilo_sugerencia-boton-de-mensajes-mas-valorados_2172422, que @melado me ignoró ).

Seguro que, pese a que la web tenga ahora un diseño responsive, hay alguna forma de distinguir versión móvil de la que no es, aunque sea con una chapucilla de a menos de X resolución se considera versión móvil.

Y desde esa chapucilla o algo más profesional, habilitar las opciones que hay ahora de no cargar las etiquetas [img] pero que sólo se activen con resoluciones de móvil.

No sé cómo lo tendrán hecho otros foros similares a éste porque no los visito, pero siempre podemos cotillearles

melado escribió:

JohnH escribió:No digo que lo implementes, que generaría tráfico, ni sé si se puede, pero hacer un HEAD en PHP a la url externa enmarcada entre 2 [img][/img] dará un content-type y content-length para discernir el tipo de imagen y el tamaño, respectivamente, podría ser una posibilidad

Precargar desde el servidor todas las imágenes que se ponen en el foro es una locura, lo siento xD

El comando HEAD no precarga, sólo descarga cabeceras HTTP.

A lo mucho, dependiendo del servidor, serían unos 512 bytes, y tirando muy por lo alto. Lo normal viene a ser no más de 150 bytes. (IMGUR, que se usa mucho por aquí son ±580 bytes)

Y tampoco te digo que sea comprobar cada imagen. Te he propuesto, alternativamente, al igual que se hacen otras comprobaciones al darle al "botón" enviar (o vista previa), comprobar que las urls incluidas en el tag IMG no llevan a archivos enormes. Es mucho menos común que no se envíe la cabecera Content-Length.

Es decir, no sería hacer una comprobación por cada imagen, sino cuando se pretende enviar una mega imagen (que daría igual el tipo (GIF, JPG, PNG, BMP (que también los hay...))).


Ahora, también entiendo que se envían una cantidad enorme de mensajes al foro, así que por eso te dije al principio que generaría tráfico.

It's up to you.

No, hacer eso del lado del servidor es super frágil y requeriría un esfuerzo importante para un resultado mediocre.

Lo que me pregunto es si se podría hacer con un Service Worker en el lado del cliente...

melado escribió:No, hacer eso del lado del servidor es super frágil y requeriría un esfuerzo importante para un resultado mediocre.

Lo que me pregunto es si se podría hacer con un Service Worker en el lado del cliente...

Por todo lo contrarío te lo proponía yo.

Es más fácil deshabilitar Javascript (y almacenamiento local) en el cliente (yo no soy una muestra útil, pero mayormente navego, aquí o en otras webs, con este desactivado; paradojicamente lo suelo habilitar para el editor). Por eso es más factible hacerlo del lado del servidor. El entorno del cliente es mucho más aleatorio.

Además, no lo he dicho antes, porque vosotros tendréis los datos y sabréis mejor, pero se sobreentiende que no todos los mensajes que se envían contienen imágenes (exceptuando emoticonos, fáciles de filtrar en un chequeo).

Con números, seguro que demasiado bajos, no creo que el servidor llegase tampoco 10MB diarios de consumo en cabeceras de petición y respuesta. No sé, no tengo datos.

Hagáis o no hagáis nada, de momento me conformo con victorias como la de hace unos meses con un usuario que enviaba mensaje sí, y mensaje también, con GIFs enormes, para que dejen de hacerlo.

Lo dejo aquí.

Yo sin saber nada del tema de desarrollo web poco puedo aportar al tema técnico, pero que parece que sí que hay deseo de capar los archivos enormes por parte de vuestros usuarios es innegable. Anda y échale un ojo a lo que dice @JohnH, va, que parece que tiene algún tipo de experiencia con cosas del tema que nos ocupa.

Te va a parecer que te hago el feo, y en realidad me lo hago a mí, aunque es mejor dejarlo claro, pero créeme que yo no tengo más nivel y/o experiencia que melado.

Lo tengo, no sé cómo no se nos había ocurrido antes. El tamaño de los [ img] se guarda en momento de posteo como un campo más de la bdd. Ya sé que la imagen se podría modificar a posteriori pero serían casos aislados. El potencial es enorme: definir a partir de qué tamaño no cargar, mostrar el tamaño en el link a la imagen, avisar de fail al postear... Y la carga de tráfico para el server sería baja.

1. En este momento no guardamos en ninguna parte información alguna sobre ninguna imagen insertada en EOL.
2. Aunque lo hiciésemos, no todos los servidores dan esa información sin descargarse la imagen por completo.
3. Aunque nos diesen siempre esa información, muchos servidores nos bloquean (es un problema habitual para por ejemplo las firmas, donde sí se comprueba ese tamaño, y muchas veces la gente no puede insertar una firma porque a alguien se le ha ocurrido la idea de bloquear nuestra IP).
4. Aunque no nos bloqueasen, los servidores a veces están caídos, van lentos, o no funcionan desde distintas partes de internet. Puede que tú veas la imagen pero nosotros no seamos capaces por un cambio reciente de DNS, por ejemplo.
5. Aunque los servidores funcionen todos perfectamente el 100% de las veces, nada impide alojar tu propia imagen y mentir sobre el tamaño, o directamente insertar una imagen de 2 KB y una vez verificada reemplazarla por una de 2 GB (esto también ha sido un problema con las firmas).

Como he dicho, sería un sistema que fallaría muy a menudo, el resultado sería bastante pobre, y requeriría un trabajo bastante importante de programación y adaptación del foro. Por todo ello, creo que no vale la pena.

Dicho esto, tengo apuntado investigar lo de los Service Workers porque eso sí parece una solución que, si funciona, evitaría todos los problemas que menciono, al ejecutarse en el lado del cliente.

Sólo espero que no obligues a tener JavaScript habilitado en el editor sí o sí, si no, te voy a echar un mal de ojo

Hagas lo que hagas ya, me da igual. No soy de reportar, pero he sacado la escopeta. Paso ya de encontrarme, como el otro día, una respuesta (si se le podía llamar así), a otro usuario, con un p... GIF de 8.5MB, cuando bien podía haber puesto el siguiente emoticono para decir lo mismo:

No violan las normas, pero GIF enorme y sin sentido que vea, mensaje que voy a reportar. Que se pongan en los hilos en los que se comparten imágenes y tal, bien, pero el resto, tolerancia cero. Y ni siquiera los hilos de fotografía se libran, que el que reporté hace unos meses, tela. Empatía por el resto de conexiones de España, cero, tanto por dimensiones de la imagen, como por tamaño. Y mira que se llenan las noticias sobre banda ancha con gente diciendo que aún están a 1MB.

JohnH escribió:Sólo espero que no obligues a tener JavaScript habilitado en el editor sí o sí, si no, te voy a echar un mal de ojo

A pesar de lo que pueda parecer, soy un firme creyente del "progressive enhancement", y que la web funcione sin JavaScript. Mientras esté yo por aquí y no me obliguen a lo contrario, así seguirá siendo. JS es necesario para funciones adicionales, no vitales, que se "esparcen" por encima de la funcionalidad base obligatoria. Tampoco es que en EOL abusemos mucho del JS, hay un par de menús y dos tonterías más.

Por desgracia para ti, esta funcionalidad la consideraría dentro de las "funciones adicionales"

una respuesta (si se le podía llamar así), a otro usuario, con un p... GIF de 8.5MB

Opine lo que opine yo sobre el punto de vista técnico, no te cortes en ese aspecto. Si lo ves fuera de lugar, adelante. Eso sí, un hilo de fotografía yo lo veo como un sitio lógico para fundir megas, ¿no?

melado escribió:

una respuesta (si se le podía llamar así), a otro usuario, con un p... GIF de 8.5MB

Opine lo que opine yo sobre el punto de vista técnico, no te cortes en ese aspecto. Si lo ves fuera de lugar, adelante.

Esa imagen en particular era en una noticia de hace unos días.

melado escribió:Eso sí, un hilo de fotografía yo lo veo como un sitio lógico para fundir megas, ¿no?

En el hilo de fotografía lo hice porque estamos hablando de una imagen que rondaba los 16000 píxeles o más (a 3:2; sí, no he puesto ceros de más) y los MB estarían por encima de 20. Me pareció innecesario. Ya sólo le faltó ponerla en RAW.

Fue hace unos meses y no me acuerdo de los números en concreto, pero era una burrada, créeme. Lástima que el reporte lo haya borrado del correo, porque recuerdo que puse la razón.

Adiós EOL, una pena en lo que os estáis convirtiendo.

Saludos.

Sí, se carga normal.

melado escribió:Lo que me pregunto es si se podría hacer con un Service Worker en el lado del cliente...

Cada vez pinta más posible esto. Ha llegado a Chrome 66 (actualmente la estable es la 65) la posibilidad de abortar peticiones al vuelo:
https://bugs.chromium.org/p/chromium/is ... 750599#c15

Puedo proponer que EOL realice una carga primera de las imagenes que se enlazan en los BBCODE 'img', que mire el tamaño, y si el tamaño es mayor de determinados KB, que meta la imagen automaticamente en un DIV/A con un texto que diga 'imagen de x KBytes, para cargarla pulse aqui, el cual al ser pulsado, por javascript, cambie el tag HTML por un IMG con el SRC de la imagen correspondiente.

Ademas, podria configurarse en el perfil de usuario con una opcion del estilo 'No precargar imagenes mas grande de x KBytes para ahorrar datos'.

Pero claro, eso implica meter una opcion mas configurable en el perfil de usuario, meter un hook especifico en el posteo de los mensajes por el cual todas las IMG deben 'precargarse' para mirar el tamaño, guardar las URL de las imagenes con su tamaño en la BBDD, meter un hook a la hora de renderizar los mensajes para incluir los tags necesarios en caso de que dicha opcion de perfil este habilitada... y luego, despues de semejante trabajo, ¿que porcentaje de usuarios usaria dicha funcionalidad?

Bueno, además de eso ya he comentado que la opción de precargar las imágenes por parte del servidor no es viable. Ya se hace con las firmas y ni te imaginas la de problemas que tenemos por servidores que nos bloquean. Además el contenido que envían depende del user-agent, y mil variantes más que invalidan la solución.

Así que por ahora mi objetivo es hacerlo del lado del cliente con Service Workers, y todo apunta a que será posible próximamente.