Ressource interprétée comme une image mais transférée avec le type MIME text/html - Magento
Je reçois une erreur ci-dessous lors du téléchargement d'une nouvelle image de produit pour ma boutique Magento.
Resource interpreted as image but transferred with MIME type text/html
Y a-t-il une raison pour que cela se produise?
Cela pourrait bien se produire si votre chemin d’image est mal défini. Par exemple, par rapport au répertoire actuel "images/myimage.gif" par rapport à la racine Web "/images/myimage.gif".
La référence à "text/html" peut suggérer que le serveur retourne une erreur.
J'ai remarqué ce problème dans mon journal de console JavaScript. Il s'agissait simplement d'un fichier CSS recherchant une image d'arrière-plan qui n'existait pas et du serveur envoyant un message d'erreur 404 à la place.
Il faut servir les images avec le type MIME approprié -
Ajoutez cette ligne dans le fichier .htaccess (en supposant qu'il s'agisse d'Apache2 httpd):
AddType image/gif .gif
astuce: mod_rewrite peut nécessiter une exclusion pour les images:
RewriteCond %{REQUEST_URI} !\.(png|gif|jpg)$
RewriteRule ...
... tout le reste pourrait être 404 en effet.
J'ai eu le même problème une fois, à cause de capitalisation .
Mes collègues travaillaient sur un Mac et ont ajouté des fichiers contenant des boîtiers de chameaux, mais ils sont apparus en minuscules en CSS. Cela fonctionne bien sur Mac, mais je travaillais sur Linux . Mac ne distingue pas les noms de fichiers ayant des cas différents, mais Linux le fait. La plupart des serveurs fonctionnent sous Linux.
exemple:
epicimage.jpg !== EpicImage.jpg
Grâce aux outils de développement Chrome, le problème pouvait être résolu très facilement. En cliquant simplement sur l'URL de l'image, il m'a montré notre page 404. Mystère résolu: D
Veuillez vérifier extension de votre image, que le programme utilisé crée l’image étiquette son extension en majuscules ou en minuscules, certains serveurs les lisant différemment.
Mon problème était avec cette ligne dans le CSS
background-image: url('');
Qui aurait dû être:
background-image: none;
Après de nombreuses recherches, j'ai découvert que le problème était dû à une combinaison de facteurs, ce qui empêchait le serveur de savoir quel type de document il était et se mêlait à des types de codage tels que UTF-8
Ainsi, dans .htaccess, modifiez le tour de commentaires pour obtenir le texte suivant, en donnant un jeu de caractères par défaut UTF-8.
############################################
## Prevent character encoding issues from server overrides
## If you still have problems, use the second line instead
#AddDefaultCharset Off
AddDefaultCharset UTF-8
Cela a arrêté l'erreur correcte affichée dans Google (merci, monsieur Google): "Ressource interprétée comme une image mais transférée avec le type mime text/html"
Et le fait que les images apparaissent dans d'autres navigateurs (où il n'y avait aucune erreur affichée).
J'ai vérifié pratiquement toutes les questions similaires sur StackOverflow en essayant de résoudre un problème similaire.
Après toutes les tentatives de modification de mon fichier htaccess et de l'insertion d'arguments en tête php, ce qui a été résolu pour moi était ... simplement de changer la casse du nom de l'image.
Ugh . (Cela fonctionnait bien dans le même navigateur hébergé localement, aussi ... donc bien sûr, je ne pense pas que ce soit le problème à l'origine.)
Si votre chemin d'image et votre nom de fichier sensible à la casse sont correctement définis et si vous ne pouvez pas modifier le fichier .htaccess de votre serveur, coder le fichier SVG en tant qu'URI de données constitue une solution frontale. css-tricks.com explique comment: http://css-tricks.com/using-svg/
Pour moi, cette erreur de type mime ne s'est révélée que lors du test de Safari 4.05 selon les exigences du client et uniquement dans la console. En fin de compte, cela était dû au fait que Safari avait manipulé la fonction element.style.backgroundImage="url()"; de style javascript sans grâce. De toute évidence, Safari recherchait cette URL vide, aussi, pour Strixy et stevecomrie, "none" est le meilleur choix. Il s’agit essentiellement du même problème que mentionné ci-dessus, à savoir que la duplication de Ressource est interprétée comme une autre mais transférée avec le type MIME text/javascript? , où <script src=""> était le coupable.
Pour les utilisateurs de magento2
Si vous avez modifié ce fichier app/etc/di.xml Avec ce qui suit
<item name="view_preprocessed" xsi:type="object">Magento\Framework\App\View\Asset\MaterializationStrategy\Copy</item>
assurez-vous que la chaîne de chemin d'accès est sensible à la casse (CaseSensitive pour un système d'exploitation autre que Windows)
Si vous faites face à des erreurs 404 après l'installation de magento2 dans Ubuntu .
Installer et activer rewrite module
a2enmod rewrite
Puis Modifier
/etc/Apache2/sites-available/000-default.conf
Ajouter les lignes suivantes à la fin
<Directory "/var/www/html">
AllowOverride All
</Directory>
Pour moi, mon chemin d'accès était mal défini par rapport au fichier css qui tentait d'extraire l'image à partir de laquelle l'erreur était déclenchée dans la console.
Je devais sortir 2 répertoires et ensuite dans celui qui avait mon image.Le .. avant que la barre oblique vous fait sortir d'un répertoire. Chaque . vous amène un autre répertoire.
ex. url (../Folder/ImagesFolder/image.gif)
Peut-être que les images n'avaient pas la permission de lire
J'ai aussi eu ce problème, quand j'utilise TinyPNG pour compresser des images, j'ai eu ce message d'erreur "Ressource interprétée comme une image mais transférée avec un type MIME text/html". Ensuite, j'ajoute une permission aux images, cela fonctionne.
Cela m'est arrivé lorsque j'incluais l'image SVG via img tag. Si vous incluez une image SVG via une balise, vous devez plutôt passer à la balise Object:
<object type="image/svg+xml" data="imageFile.svg">
Test SVG Logo
</object>