Comment gérer le rendu SVG dans wordpress?

Avec l'avancement des navigateurs Internet, je me retrouve de plus en plus à l'aise à utiliser SVGS lors du codage de sites Web ... en particulier pour les icônes et les graphiques simples qui peuvent être remplacés à la volée par pngs.

Il semble que wordpress supporte presque SVGS. Je dis presque parce que:

1. Ce n'est pas par défaut un type de fichier autorisé dans wordpress. Vous devez donc ajouter cela avant de télécharger des SVG

2. Vous ne pouvez pas voir une vignette SVG dans la galerie multimédia. (voir l'image ci-dessous)

3. Parfois, lorsque vous l'ajoutez à l'éditeur (via le bouton Ajouter un média), l'éditeur ne connaît pas la taille SVG, donc bien qu'il ajoute le SVG en tant qu'image, sa largeur et sa hauteur sont nulles.

4. Lorsque vous cliquez sur "Modifier l'image" dans la fenêtre contextuelle de téléchargement des médias, vous obtenez un message disant "l'image n'existe pas". Voir l'image ci-dessous.

Je suis d'accord avec l'élément 1 de cette liste, mais quelqu'un a-t-il compris comment corriger un élément 2 3 et 4?

Mise à jour sur l'élément 1:

Pour autoriser un nouveau type MIME (tel que SVG), vous pouvez simplement ajouter un hook dans functions.php

function allow_new_mime_type($mimes) {

    $mimes['svg'] = 'image/svg+xml';

    return $mimes;
}
add_filter( 'mime_types', 'allow_new_mime_type' );

Vous devriez maintenant pouvoir télécharger des SVG. Vous pouvez trouver plus d'informations dans ce tutoriel . Cela ne résout que le point 1, qui, comme je l'ai mentionné précédemment, n'est pas un problème pour moi (bien que je pense qu'il devrait être autorisé par défaut).

Mise à jour sur l'élément 2:

J'ai creusé et trouvé la fonction qui décide si une pièce jointe est une image ou non. Il semble que tout se résume à cette fonction dans wp-includes / post.php

/**
 * Check if the attachment is an image.
 *
 * @since 2.1.0
 *
 * @param int $post_id Attachment ID
 * @return bool
 */
function wp_attachment_is_image( $post_id = 0 ) {
    $post_id = (int) $post_id;
    if ( !$post = get_post( $post_id ) )
        return false;

    if ( !$file = get_attached_file( $post->ID ) )
        return false;

    $ext = preg_match('/\.([^.]+)$/', $file, $matches) ? strtolower($matches[1]) : false;

    $image_exts = array( 'jpg', 'jpeg', 'jpe', 'gif', 'png' );

    if ( 'image/' == substr($post->post_mime_type, 0, 6) || $ext && 'import' == $post->post_mime_type && in_array($ext, $image_exts) )
        return true;
    return false;
}

Comme vous pouvez le voir, un tableau d'extensions d'image valides est défini dans cette fonction. Je ne vois aucun filtre qui pourrait être utilisé pour modifier ce tableau. Mais c'est un début ...

Je ne sais pas pourquoi la dernière instruction if renvoie false pour svgs. Même si je n'ajoute pas l'extension svg au tableau $ image_exts, la première condition devrait retourner true, n'est-ce pas?

if ( 'image/' == substr($post->post_mime_type, 0, 6)

Cela vérifie si 'image /' est interrogé sur les six premiers caractères du type MIME, qui pour svg est image / svg + xml (les six premiers sont "image /").

MISE À JOUR

Après une enquête plus approfondie, il semble que le problème ne soit pas du tout avec wp_attachment_is_image, mais parce que la taille de l'image (largeur et hauteur) n'est pas ajoutée aux métadonnées de la pièce jointe lorsque le SVG est téléchargé. C'est parce que la fonction pour calculer l'image utilisée est la fonction php getimagesize (), qui ne renvoie pas de taille d'image pour SVG. J'ai trouvé une réponse sur stackoverflow sur la fonction getimagesize et sur le comportement des svgs. Voyez-le ici.

Jetez un œil à wp_prepare_attachment_for_js()ce qui rassemble les métadonnées des pièces jointes à utiliser sur les pages Média. Le filtre éponyme nous permet d'ajouter ou de modifier des métadonnées.

L'exemple suivant peut être déposé dans functions.php. Remarque: cela nécessite la prise en charge de SimpleXML en PHP.

function common_svg_media_thumbnails($response, $attachment, $meta){
    if($response['type'] === 'image' && $response['subtype'] === 'svg+xml' && class_exists('SimpleXMLElement'))
    {
        try {
            $path = get_attached_file($attachment->ID);
            if(@file_exists($path))
            {
                $svg = new SimpleXMLElement(@file_get_contents($path));
                $src = $response['url'];
                $width = (int) $svg['width'];
                $height = (int) $svg['height'];

                //media gallery
                $response['image'] = compact( 'src', 'width', 'height' );
                $response['thumb'] = compact( 'src', 'width', 'height' );

                //media single
                $response['sizes']['full'] = array(
                    'height'        => $height,
                    'width'         => $width,
                    'url'           => $src,
                    'orientation'   => $height > $width ? 'portrait' : 'landscape',
                );
            }
        }
        catch(Exception $e){}
    }

    return $response;
}
add_filter('wp_prepare_attachment_for_js', 'common_svg_media_thumbnails', 10, 3);

Ce n'est pas quelque chose que vous allez pouvoir facilement "pirater" avec un plugin ou un petit ensemble de code.

En résumé, les SVG ne sont pas, dans l’ensemble, des «images» au sens de toutes les images qui l’ont précédé. Les SVG sont des images vectorielles et les premières à obtenir une réelle traction sur le Web.

Toutes les images précédentes étaient basées sur un bitmap. Le système de gestion d'image de WordPress a été écrit spécifiquement pour y faire face, et cette conception inhérente est située à chaque point du système.

C'est une hypothèse sous-jacente que les images ont des largeurs et des hauteurs, par exemple. Les SVG n'ont ni l'un ni l'autre, ils peuvent être de n'importe quelle taille. Il existe un "éditeur" de base pour les images intégrées à WordPress, dont aucune fonctionnalité ne peut vraiment s'appliquer aux SVG.

Le système multimédia est lentement en cours de réaménagement, l'accent étant mis ici sur «lentement». Il y a beaucoup de compatibilité descendante à maintenir et de nouvelles conceptions à mettre en œuvre. De plus, la plupart des gens sont beaucoup plus intéressés à prendre en charge la vidéo, l'audio et les listes de lecture. Au fur et à mesure que ce travail de refonte est effectué et que les sections de la bibliothèque deviennent plus abstraites, ce genre de chose deviendra plus facile à prendre en charge au fil du temps. Mais ce n'est pas encore là, et ce ne sera pas avant un moment. C'est pourquoi le type mime SVG n'est pas pris en charge, car l'ajout de ce type mime jusqu'à ce que toutes les pièces sous-jacentes fonctionnent serait une voie de rupture.

Pour les SVG, le wp_attachment_is_imagedevrait renvoyer false, car wp_attachment_is_imageest utilisé pour déterminer s'il faut afficher ou non le bouton de l'éditeur et s'il image_downsizeessaie ou non de redimensionner l'image dans les vignettes et autres. Aucun de ces éléments ne fonctionnerait de toute façon pour les SVG. Pour prendre correctement en charge les SVG, vous devez écrire un nouveau système pour ajouter entièrement des métadonnées pour ces images, puis ajouter la prise en charge de celui-ci à tous les endroits où les métadonnées peuvent être utilisées. Comme vous pouvez l'imaginer, ce n'est pas un petit travail.

Juste en lisant la source (pas en testant), je peux voir que l'extension doit correspondre:

if ( 'image/' == substr($post->post_mime_type, 0, 6) || $ext && 'import' == $post->post_mime_type && in_array($ext, $image_exts) )

qui se lit comme (pseudo code)

si image/est les 6 premiers caractères de la propriété $ post object post_mime_type OU il y a une extension OU importest la propriété $ post objects post_mime_type ET l'extension de fichier actuelle est l'une de (Array)

Et cela signifie que la dernière déclaration décidera toujours si le résultat ifest vrai ou non.

D'après ce que je peux lire get_attached_file(), il y a un filtre qui permettrait de simuler l'extension:

return apply_filters( 'get_attached_file', $file, $attachment_id );

En d'autres termes, vous pouvez essayer de renvoyer le même fichier mais avec une extension différente. Cela n'entrerait pas en conflit avec d'autres parties, car la wp_attachment_is_image()juste revient bool.