archivos SVG que no se han cargado desde la última actualización de WP

16

Tengo un fragmento en mi archivo PHP de funciones que me permite subir archivos SVG. Desde la actualización a la última versión de WP de hoy, ya no puedo cargar svgs. También probé un segundo fragmento de código del sitio web de trucos CSS y tampoco funciona.

¿Alguien sabe a) lo que pudo haber causado esto con la última actualización yb) ¿Alguien sabe alguna solución?

Aquí está el código que normalmente uso:

function svg_mime_types( $mimes ) {
   mimes['svg'] = 'image/svg+xml';
   return $mimes;}
add_filter( 'upload_mimes', 'svg_mime_types' );  

Muchas gracias

Paul.

    
pregunta Paul12_ 11.01.2017 - 22:16

3 respuestas

16

En WordPress 4.7.1 se introdujo un cambio que comprueba el tipo de mimo real de un archivo cargado. Esto interrumpe la carga de tipos de archivos como SVG o DOCX. Ya existen tickets para este problema en WordPress Core, donde puede leer más sobre esto:

  • Algunos archivos que no son de imagen no se cargan después de 4.7.1 ( enlace )
  • El soporte de carga SVG se rompió en 4.7.1 ( enlace )

Un temporal y una solución recomendada (por el tiempo hasta que se solucione este problema) es el siguiente complemento:
Desactivar Real MIME Check

Si no quieres usar ese complemento, esta es la misma funcionalidad:

add_filter( 'wp_check_filetype_and_ext', function($data, $file, $filename, $mimes) {
    global $wp_version;

    if ( '4.7.2' !== $wp_version ) {
       return $data;
    }

    $filetype = wp_check_filetype( $filename, $mimes );

    return [
        'ext'             => $filetype['ext'],
        'type'            => $filetype['type'],
        'proper_filename' => $data['proper_filename']
    ];

}, 10, 4 );

Tenga en cuenta que este recorte tiene una comprobación de versión incluida para deshabilitar la solución tan pronto como se actualice WordPress.

Editar

Inicialmente, el problema se estableció en 4.7.2. Pero como 4.7.2 fue un lanzamiento de seguridad urgente , la solución no lo hizo en esa versión Ahora se supone que está arreglado en 4.7.3.

    
respondido por el Gchtr 12.01.2017 - 19:51
5

Parece que esto podría estar relacionado con este ticket enlace , parece algo que se rompió en 4.7.1

    
respondido por el Mark Kaplun 12.01.2017 - 02:16
2

Parece que nadie acaba de trabajar con lo que es y eso es muy malo, así que así es como lo manejé ...

Historia / Fondo

Creé un cargador SVG en 2015 basado en un artículo de CSS-Tricks que analiza lo que era. También obtuve la cuadrícula trabajando para la vista previa de la imagen, y utilicé algunas otras correcciones. Complemento simple (los complementos de tipo de archivo IMO deben ser simples)

Solución

Hubo algunos cambios para 4.7. El PITA real fue que para image/ mime tipos WP ahora está utilizando GD en las imágenes. Para evitar esto, configuré la extensión svg para usar application/svg+xml para que GD no se metiera con el archivo.

Actualización: a partir de la versión 4.7.2, en algunos casos, también se produjo una chispa brillante

Luego, a través de Hook, lo conectamos de nuevo a image/svg+xml . Es el mismo que se usa en otras respuestas, pero primero lo guardamos en nuestro caso específico para eliminar efectos (es un archivo SVG); podemos confiar en la lectura de $data['ext'] (debería ser más económico que la función para obtener información del archivo como solo una comparación y un acceso de matriz / hash).

Actualización: a partir de 4.7.2 $data['ext'] no siempre se establece, por lo que ahora si su longitud es < 1 extensión de extracción (potencialmente insegura) del nombre de archivo usando %código%. La razón por la que realmente estoy luchando con FileInfo es que esencialmente confiar en una extensión de PHP es demasiado opaco y no siempre funcionará para todos (especialmente no aquellos que compilan sin o sin acceso para habilitar las extensiones si no están allí). Me gustaría algo que funcione en lugar de una extensión. Ya no se trata de tener la información correcta, por lo que, para aquellos que confían en la salida de strtolower(end(explode('.', $filename))) y tienen la extensión (creo que es la predeterminada en 5.6+), debería funcionar. Además, debido a que este es un complemento, no está modificando el núcleo, puede desactivar este código o anular el registro del gancho.

enlace

Ver

Otras soluciones

Permitir subidas sin filtrar es una solución horrible porque, como otros han dicho, al vincular a este hilo, las personas podrían cargar archivos php a través del cargador de medios (eso es malo y si lo haces, debes detenerte y pensar).

Forzar cada archivo a través de cualquier función sin controles (irónicamente, si tiene FileInfo en el tipo mime, no puede simplemente tener un simple control ext). Esto tiene el potencial de crear efectos de alcance mucho más amplios para resolver un problema relativamente específico e introduce más trabajo en general (advertir que mi complemento también introduce más trabajo para que los usuarios de administración puedan hacer funcionar la IU de medios de administración)

Si dejamos el mime como application / svg + xml y simplemente filtramos los tipos de mime que cargaría la imagen, pero AFAIK requeriría que se usen correcciones como imagen destacada, etc. Hay mucho trabajo por hacer para garantizar la experiencia universal de SVG así que elegí escoger batallas con cuidado.

Espero que esto ayude.

    
respondido por el MrMesees 19.01.2017 - 17:50

Lea otras preguntas en las etiquetas