Autoriser un type de fichier bloqué dans WordPress

Si vous voyez “Sorry, this file type is not permitted” au moment d’envoyer un fichier dans la Médiathèque, vous êtes face à un blocage de sécurité. Le piège, c’est que l’erreur ressemble à un simple “format non supporté”, alors que la cause peut être WordPress, un plugin, ou même votre serveur.

Le problème

Le message d’erreur apparaît généralement dans l’admin WordPress, au moment d’envoyer un fichier via Médias → Ajouter ou via un sélecteur de médias (dans un article, une page, Elementor, Divi, Avada, etc.).

Message typique (WordPress 6.9.4, interface anglaise ou site en anglais) :

Sorry, this file type is not permitted for security reasons.

En français, vous pouvez voir une variante comme :

Désolé, ce type de fichier n’est pas autorisé pour des raisons de sécurité.

Circonstances fréquentes que j’ai souvent croisées en dépannage :

Vous tentez d’envoyer un SVG (très courant), un JSON, un WEBP sur un site ancien, un ICO, un CSV, un ZIP, ou un fichier “exotique” (AI, PSD…).
Après une mise à jour (WordPress, thème, plugin de sécurité), l’upload d’un type jusque-là accepté se met à échouer.
Sur un multisite, seul le super-admin peut envoyer certains formats.
Le fichier passe en local, mais pas en production (WAF, ModSecurity, règles serveur).

À la fin, vous saurez :

Identifier qui bloque (WordPress vs plugin vs serveur).
Autoriser un type de fichier proprement via un filtre (sans modifier le cœur de WordPress).
Éviter les solutions dangereuses (ex. autoriser “tout”, ou autoriser SVG sans durcissement).

Résumé rapide

WordPress n’autorise pas tous les types de fichiers : il compare l’extension et le type MIME, puis peut refuser pour sécurité.
La méthode recommandée est le filtre upload_mimes (et parfois wp_check_filetype_and_ext pour les cas tordus).
Beaucoup d’échecs viennent d’un snippet qui écrase la liste des mimes au lieu de l’étendre.
Les SVG sont un cas à part : les autoriser “brut” est risqué (XSS). Il faut au minimum limiter aux admins et assainir.
Si l’erreur est intermittente ou dépend du fichier, suspectez un WAF/ModSecurity, des permissions, ou des limites PHP.

Les symptômes

Symptômes visibles côté admin (les plus courants) :

Message “Sorry, this file type is not permitted…” juste après la sélection du fichier.
Le fichier n’apparaît pas dans la Médiathèque, même après rafraîchissement.
Avec certains builders (Elementor / Divi 5 / Avada), vous voyez un toast/notification “Upload failed” ou “Invalid file type”.
Dans la console navigateur (F12 → Network), la requête d’upload renvoie une réponse JSON d’erreur, ou un code HTTP 403/406 si un WAF intervient.

Symptômes côté logs (selon configuration) :

Dans wp-content/debug.log (si activé), vous ne voyez parfois rien : WordPress refuse avant de déclencher une erreur PHP.
Dans les logs serveur, vous pouvez voir des traces ModSecurity (403) ou un blocage WAF “Request denied”.

Symptômes “pièges” que j’ai vus :

Vous essayez d’envoyer un fichier qui a la bonne extension mais un MIME interne différent (ex. un “.jpg” qui est en réalité un PNG renommé).
Un plugin de cache/minification n’est pas la cause directe, mais il masque les erreurs dans l’interface (vous croyez à un bug UI).
Un plugin de sécurité durcit les mimes et refuse même des formats normalement acceptés.

Tableau de diagnostic rapide

Symptôme	Cause probable	Vérification	Solution
Refus immédiat + message “file type not permitted”	MIME non autorisé par WordPress	Testez avec un JPG/PNG standard	Solution 1 (upload_mimes)
Refus uniquement pour SVG	SVG bloqué par défaut (sécurité)	Essayez PDF/JPG : ça passe	Solution 1 + durcissement SVG
Erreur 403/406 dans Network	WAF / ModSecurity	Regardez les headers/response, logs hébergeur	Solution 3
Ça marchait avant, plus maintenant	Snippet/plugin a écrasé les mimes	Désactivez snippets/plugins (Health Check)	Solution 2
Ça passe pour admin, pas pour éditeur	Rôles/capacités, multisite	Testez avec un compte admin	Limiter par capacité / réseau

Pourquoi ça arrive

Version débutant : WordPress maintient une liste de “types de fichiers autorisés”. Quand vous envoyez un fichier, il vérifie l’extension (.pdf, .jpg, .svg) et le type MIME (ex. image/jpeg, application/pdf). Si le type n’est pas dans la liste, WordPress refuse pour éviter que vous envoyiez un fichier potentiellement dangereux.

Version technique : l’upload passe par wp_handle_upload(), puis WordPress utilise des contrôles autour de l’extension/MIME. La liste des types autorisés est filtrable via upload_mimes. Et, selon les cas, la détection “réelle” du type peut passer par wp_check_filetype_and_ext (utile quand l’extension ne correspond pas au contenu). Documentation officielle : upload_mimes.

Causes classées du plus fréquent au plus rare :

Le type n’est pas autorisé (SVG, JSON, etc.).
Un snippet ou plugin “mimes” mal écrit qui retourne un tableau incomplet et bloque tout le reste.
Un plugin de sécurité (ou durcissement hébergeur) qui retire des types.
Mauvaise détection MIME (fichier corrompu, extension trompeuse, outil d’export qui produit un MIME atypique).
Blocage serveur (WAF/ModSecurity, antivirus, règles Nginx/Apache).
Multisite : restrictions supplémentaires au niveau réseau.

Prérequis avant de commencer

Sauvegarde avant toute modification (fichiers + base). Ne testez pas un snippet “au hasard” en production.
WordPress 6.9.4 (avril 2026) et PHP 8.1+ recommandés. Si vous êtes en dessous, attendez-vous à des comportements différents et à des plugins qui cassent.
Un moyen sûr d’ajouter du code :
- idéal : un mini-plugin (recommandé),
- ou un mu-plugin (plugin “must-use”),
- ou functions.php d’un thème enfant (pas le thème parent).
Outils utiles :
- Query Monitor (pour voir ce qui se passe côté WordPress).
- Health Check & Troubleshooting (diagnostic de conflits sans casser le site public).
Pour les logs : activez temporairement WP_DEBUG et WP_DEBUG_LOG si vous savez ce que vous faites. Référence : Debug WordPress.

Solution 1 : autoriser le type de fichier via le filtre upload_mimes (méthode propre)

Un filtre (hook de type “filter”) permet de modifier une valeur que WordPress s’apprête à utiliser. Ici, upload_mimes vous donne le tableau des types autorisés, et vous pouvez y ajouter le vôtre.

Où coller le code (choisissez une seule option) :

Recommandé : créez un mini-plugin dans wp-content/plugins/bpcab-uploads-mimes/bpcab-uploads-mimes.php, puis activez-le.
Alternative : wp-content/mu-plugins/bpcab-uploads-mimes.php (chargé automatiquement).
Dernier recours : functions.php de votre thème enfant.

Code AVANT (cassé) : autoriser “en vrac” ou autoriser trop large

J’ai vu ce snippet sur des blogs : il “autorise tout” ou il ajoute des mimes dangereux sans restriction. C’est une mauvaise idée.

<?php
// MAUVAIS EXEMPLE : autoriser arbitrairement des types risqués
add_filter('upload_mimes', function($mimes) {
	$mimes['svg']  = 'image/svg+xml';
	$mimes['php']  = 'application/x-php';
	$mimes['exe']  = 'application/octet-stream';
	return $mimes;
});

Pourquoi c’est cassé : vous ouvrez la porte à des fichiers exécutables ou interprétables. Même si WordPress n’exécute pas un .php uploadé dans la médiathèque, une mauvaise configuration serveur peut le faire. Niveau sécurité, c’est un “non”.

Code APRÈS (corrigé) : autoriser un type précis, avec garde-fous

Exemple concret : autoriser SVG et JSON, mais uniquement pour les administrateurs. C’est un compromis fréquent sur des sites de contenu.

<?php
/**
 * Plugin Name: BPCAB - Autoriser certains uploads (mimes)
 * Description: Ajoute des types MIME autorisés (ex: SVG/JSON) avec restrictions. Compatible WP 6.9.4+ / PHP 8.1+.
 * Version: 1.0.0
 */

defined('ABSPATH') || exit;

/**
 * Filtre = on modifie une donnée (la liste des mimes autorisés).
 * Ici, on limite volontairement à certains rôles/capacités.
 */
add_filter('upload_mimes', function(array $mimes): array {

	// Sécurité : n'autorisez pas ces types à tout le monde.
	// "manage_options" est typiquement réservé aux administrateurs.
	if (!current_user_can('manage_options')) {
		return $mimes;
	}

	// Autoriser SVG (attention : voir notes de sécurité plus bas)
	$mimes['svg']  = 'image/svg+xml';

	// Autoriser JSON (utile pour Lottie, exports, configs…)
	$mimes['json'] = 'application/json';

	// Exemple : autoriser CSV (exports)
	$mimes['csv']  = 'text/csv';

	return $mimes;
}, 10);

Pourquoi ça corrige

WordPress compare l’extension à une liste de mimes. Si l’extension n’existe pas dans ce tableau, il refuse. En ajoutant $mimes['svg'] = 'image/svg+xml', vous dites à WordPress : “ce type est acceptable”. La restriction current_user_can('manage_options') évite que n’importe quel auteur puisse envoyer des fichiers potentiellement sensibles.

Explication bloc par bloc (sans jargon inutile)

add_filter() : enregistre une fonction qui modifie une valeur. Ici, la valeur est la liste des types autorisés.
upload_mimes : le nom du filtre. Référence : developer.wordpress.org.
current_user_can() : vérifie si l’utilisateur a une capacité. Référence : current_user_can().
Le tableau $mimes : clé = extension, valeur = MIME.

Note critique : SVG = cas spécial (risque XSS)

Un SVG peut contenir du JavaScript ou des liens malveillants. Autoriser l’upload SVG sans assainissement, c’est une source classique de XSS (attaque par script). Si vous devez autoriser SVG sur un site multi-auteurs, je recommande fortement :

Limiter aux admins (comme ci-dessus),
Et assainir le SVG via une librairie/extension spécialisée (voir la section “Variante / alternative”).

Pour comprendre le cadre sécurité côté WordPress, voyez la doc sur la validation des fichiers et l’API Filesystem : Security APIs.

Solution 2 : corriger un snippet / plugin qui bloque (ou écrase) les mimes

Le scénario que je rencontre le plus : quelqu’un a ajouté un snippet “autoriser SVG” trouvé en ligne, mais il a été codé de façon à remplacer la liste des mimes au lieu de l’étendre. Résultat : WordPress n’autorise plus PNG/JPG/PDF, et vous avez l’impression que “l’upload est cassé”.

Code AVANT (cassé) : écrase la liste des mimes

Ce code retourne un tableau neuf, donc il supprime tous les types par défaut :

<?php
// MAUVAIS : remplace tous les mimes autorisés par seulement SVG
add_filter('upload_mimes', function($mimes) {
	return [
		'svg' => 'image/svg+xml',
	];
});

Symptôme typique : même un JPG est refusé, ou l’upload devient incohérent selon les écrans.

Code APRÈS (corrigé) : fusionne sans supprimer

Corrigez en ajoutant des entrées au tableau existant.

Où corriger :

Si le code est dans un plugin de snippets (type “Code Snippets”), corrigez le snippet directement (et désactivez-le si vous ne pouvez pas l’éditer sans risque).
Si c’est dans functions.php, corrigez dans le thème enfant.
Si c’est dans un plugin tiers, évitez de modifier le plugin : surchargez via un mini-plugin (comme Solution 1) et désactivez l’option du plugin si possible.

<?php
// BON : conserve les mimes existants et ajoute SVG
add_filter('upload_mimes', function(array $mimes): array {

	// On conserve la liste existante, puis on ajoute.
	$mimes['svg'] = 'image/svg+xml';

	return $mimes;
}, 10);

Cas réel : conflit de priorités de hook

Un autre piège : deux snippets utilisent upload_mimes. L’un ajoute, l’autre écrase. L’ordre d’exécution dépend de la priorité (le 3e argument de add_filter). Plus le nombre est petit, plus ça s’exécute tôt.

Si vous soupçonnez un écrasement, vous pouvez forcer votre ajout à s’exécuter après (priorité plus haute) :

<?php
add_filter('upload_mimes', function(array $mimes): array {
	$mimes['svg'] = 'image/svg+xml';
	return $mimes;
}, 999); // Priorité très haute = passe après la plupart des snippets

Ce n’est pas “magique”, mais sur le terrain ça règle souvent les cas où un plugin retouche la liste trop agressivement.

Variante : l’extension est bonne, mais WordPress détecte un autre MIME

Vous pouvez tomber sur un fichier .csv détecté comme application/vnd.ms-excel (ça arrive selon l’export). Ou un JSON détecté comme text/plain. Dans ces cas, autoriser seulement application/json ne suffit pas toujours.

Vous pouvez élargir de façon contrôlée :

<?php
add_filter('upload_mimes', function(array $mimes): array {

	if (!current_user_can('manage_options')) {
		return $mimes;
	}

	// JSON : certains exports arrivent en text/plain
	$mimes['json'] = 'application/json';
	$mimes['txt']  = $mimes['txt'] ?? 'text/plain'; // On ne casse pas l'existant

	return $mimes;
}, 10);

Si vous êtes dans un cas où WordPress refuse malgré le bon mime, passez à la Solution 3 (diagnostic fin, logs, WAF, et vérification du MIME réel).

Solution 3 : diagnostiquer côté serveur (mod_security, WAF, permissions) + WP-CLI

Quand l’erreur WordPress est un “faux ami”, vous le voyez vite : dans l’onglet Network, la requête d’upload renvoie 403/406, ou le serveur coupe la requête. Dans ce cas, ajouter upload_mimes ne change rien.

Étape 1 : regarder la réponse HTTP dans le navigateur

Ouvrez l’outil développeur (F12) → onglet Network, puis retentez l’upload. Cliquez la requête (souvent async-upload.php).

HTTP 200 avec un message d’erreur WordPress : plutôt un problème de mimes WordPress/snippet.
HTTP 403 : blocage WAF/permissions.
HTTP 406 : ModSecurity est un suspect très fréquent.
HTTP 413 : fichier trop gros (ce n’est pas votre erreur initiale, mais ça peut se mélanger).

Étape 2 : vérifier les permissions et le dossier uploads

Un serveur mal configuré peut empêcher l’écriture dans wp-content/uploads. En général, WordPress affiche un autre message, mais selon les plugins, vous pouvez voir une erreur générique.

Vérifiez que wp-content/uploads existe.
Vérifiez que le serveur web peut écrire dedans.

Référence : Configuration WordPress (et plus largement la partie administration avancée).

Étape 3 : tester via WP-CLI (si vous avez accès)

WP-CLI ne “simule” pas parfaitement l’upload HTTP, mais il est très utile pour éliminer des hypothèses : droits, environnement, plugins actifs, etc. Référence officielle : WP-CLI Commands.

Commandes utiles :

# Voir les infos de base
wp --info

# Vérifier versions WordPress et PHP côté CLI
wp core version
php -v

# Lister plugins et repérer sécurité / snippets
wp plugin list --status=active

Pour isoler un conflit, j’utilise souvent Health Check (solution “safe” en admin). Mais si vous êtes en environnement de staging, vous pouvez aussi désactiver temporairement un plugin de sécurité/snippets et retester.

Étape 4 : suspecter ModSecurity / WAF (cas très courant en hébergement mutualisé)

Si le serveur renvoie 406/403 uniquement sur certains fichiers (souvent SVG, JSON, ou des noms spécifiques), le WAF peut bloquer sur “signature”. Dans ce cas :

Essayez de renommer le fichier (ex. animation-lottie.json → data.json) pour voir si le blocage dépend du contenu/nom.
Contactez l’hébergeur avec l’heure exacte + l’URL + le code HTTP.
Si vous avez un WAF type Cloudflare, vérifiez les événements de sécurité.

Ce n’est pas un problème WordPress à corriger par code : c’est une règle de sécurité à ajuster côté serveur.

Vérifications après correction

Après avoir appliqué une solution, testez de manière reproductible :

Testez l’upload d’un PNG (contrôle : doit passer).
Testez l’upload du type que vous voulez autoriser (ex. SVG/JSON/CSV).
Testez avec un compte non-admin si vous avez mis une restriction par capacité.
Videz les caches si vous utilisez un plugin de cache (et faites un hard refresh navigateur). Ce n’est pas censé influencer l’upload, mais j’ai déjà vu des interfaces builder garder un état “upload failed”.

Si vous utilisez un page builder :

Elementor : testez l’upload via le sélecteur de médias dans un widget Image (et via Médias → Ajouter).
Divi 5 : testez depuis le module Image et depuis la Médiathèque. Divi remonte parfois un message plus générique, mais la cause reste la même.
Avada : testez dans Fusion Builder et dans Médias. Certains écrans Avada affichent “Upload failed” sans le détail.

Si ça ne marche toujours pas

Procédure que j’applique sur des sites clients, dans cet ordre (du moins intrusif au plus intrusif).

1) Vérifier que votre code est bien chargé

Si vous avez collé le code dans functions.php, assurez-vous d’être dans le thème enfant actif.
Si vous avez créé un plugin, vérifiez qu’il est activé.
Évitez de coller le code dans un endroit “visuel” (ex. un module HTML Divi/Elementor). Ça ne marche pas : PHP ne s’exécute pas là.

2) Isoler un conflit plugin/thème avec Health Check

Activez le mode dépannage de Health Check : ça désactive les plugins uniquement pour votre session, sans impacter les visiteurs. Puis :

Testez l’upload. Si ça marche : conflit plugin.
Réactivez les plugins un par un (ou par groupe) jusqu’à reproduire le blocage.

J’ai souvent vu le coupable être :

un plugin de sécurité,
un plugin de snippets,
un plugin “media optimizer” qui filtre les uploads.

3) Vérifier WP_DEBUG (temporairement)

Activez le debug le temps du diagnostic, puis désactivez-le. Référence officielle : Debug WordPress.

<?php
// wp-config.php (temporaire)
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Retestez l’upload, puis lisez wp-content/debug.log.

4) Contrôler le MIME réel du fichier

Un fichier peut être mal exporté. Exemple classique : un “SVG” qui contient en réalité du HTML, ou un JSON encodé bizarrement. Re-téléchargez une version “propre” depuis la source, ou re-exportez.

5) Vérifier les limites PHP (si vous voyez plutôt des timeouts/413)

Ça ne produit pas exactement “file type not permitted”, mais sur certains sites le message est masqué par le builder.

upload_max_filesize
post_max_size
memory_limit

Référence : php.ini directives (php.net).

6) Vérifier le serveur (403/406)

Regardez les logs Apache/Nginx si vous y avez accès.
Demandez à l’hébergeur si ModSecurity bloque la requête (fournissez l’heure et l’IP).

Pièges et erreurs courantes

Symptôme	Cause probable	Solution recommandée
Vous avez collé le code, rien ne change	Code collé au mauvais endroit (module HTML, thème parent, mauvais fichier)	Utilisez un mini-plugin ou un mu-plugin, puis retestez
Erreur critique après ajout du snippet	Point-virgule manquant / parenthèse oubliée	Revenez en arrière via FTP, corrigez la syntaxe, utilisez un éditeur avec coloration
Même les JPG ne passent plus	Snippet qui écrase `$mimes` au lieu d’ajouter	Solution 2 (fusionner sans supprimer)
Ça marche pour admin, pas pour auteur	Restriction par capacité (volontaire) ou multisite	Ajustez la capacité, ou autorisez seulement certains rôles
403/406 dans Network	WAF/ModSecurity	Solution 3 (hébergeur/WAF)
Vous suivez un vieux tutoriel, ça ne marche pas	Code obsolète / plugin non maintenu / approche dangereuse	Revenez à `upload_mimes` + restriction + assainissement (SVG)
Vous avez “autorisé SVG”, puis vous voyez des comportements étranges	SVG malicieux ou non assaini	Utilisez une solution qui nettoie les SVG (voir alternative)
Vous testez directement en production	Absence de staging / pas de sauvegarde	Testez sur staging, puis déployez

Variante / alternative

Méthode sans code (plugin)

Si vous débutez et que vous voulez éviter le PHP, un plugin spécialisé est souvent plus sûr, surtout pour les SVG (car il peut assainir le contenu).

Pour SVG : cherchez un plugin qui fait explicitement du sanitize (nettoyage) et qui limite par rôle. Évitez les plugins “Enable SVG” non maintenus ou qui se contentent d’ajouter le MIME sans nettoyage.
Pour des types simples (CSV, JSON) : un plugin de gestion des mimes peut suffire, mais gardez la logique “autoriser le minimum”.

Référence utile côté WordPress : les plugins doivent respecter les pratiques de sécurité. Voir : Security APIs et le répertoire : WordPress.org Plugins.

Méthode plus avancée (développeurs) : contrôler finement le type détecté

Quand vous avez des faux positifs (extension OK mais détection MIME différente), vous pouvez intervenir plus bas niveau avec le filtre wp_check_filetype_and_ext. Il sert à ajuster le type détecté par WordPress.

Attention : c’est puissant. Faites-le uniquement pour un cas précis, et idéalement restreint aux admins.

<?php
/**
 * Ajuste la détection MIME pour des cas spécifiques.
 * Exemple : certains JSON sont détectés en text/plain.
 *
 * À placer dans un mini-plugin ou mu-plugin.
 */
add_filter('wp_check_filetype_and_ext', function(array $data, string $file, string $filename, array $mimes) : array {

	if (!current_user_can('manage_options')) {
		return $data;
	}

	$ext = strtolower(pathinfo($filename, PATHINFO_EXTENSION));

	// Cas ciblé : JSON détecté trop génériquement
	if ($ext === 'json') {
		$data['ext']  = 'json';
		$data['type'] = 'application/json';
	}

	return $data;
}, 10, 4);

Doc officielle : wp_check_filetype_and_ext.

Éviter ce problème à l’avenir

Autorisez le minimum : n’ajoutez que les extensions nécessaires (et pas “toutes les images” ou “tout ce que le client demande”).
Limitez par rôle : sur un blog multi-auteurs, réservez les formats sensibles (SVG, JSON) aux admins.
Préférez un mini-plugin plutôt que functions.php : quand vous changez de thème, vous perdez la config (et vous oubliez pourquoi ça marchait).
Évitez les snippets non sourcés : beaucoup de vieux tutos autorisent des types dangereux ou utilisent des approches qui ne tiennent pas compte des contrôles modernes.
Staging obligatoire : testez l’upload sur une copie du site avant de déployer.
Surveillez les plugins de sécurité : après mise à jour, vérifiez si un réglage “file upload types” a changé.

Si vous devez documenter votre configuration pour un client/une équipe, laissez un commentaire clair dans le code (quoi, pourquoi, qui a demandé), et notez la date. C’est le genre de détail qui fait gagner une heure le jour où ça recasse.

Ressources

Questions fréquentes

Est-ce que je peux “autoriser tous les types de fichiers” ?

Techniquement oui, mais c’est une très mauvaise idée. Vous augmentez fortement la surface d’attaque (fichiers exécutables, contenus injectables). Autorisez uniquement ce dont vous avez besoin, et si possible uniquement pour les admins.

Pourquoi WordPress bloque les SVG alors que c’est “juste une image” ?

Un SVG est un fichier texte qui peut embarquer des scripts ou des liens. C’est donc un vecteur XSS potentiel. Si vous l’autorisez, faites-le avec restriction de rôle et, idéalement, assainissement via un plugin dédié.

J’ai ajouté `upload_mimes`, mais ça ne marche pas pour moi. Pourquoi ?

Soit un autre plugin/snippet écrase votre liste après coup (priorité), soit le serveur bloque la requête (403/406), soit le fichier est détecté avec un MIME inattendu. Suivez la section “Si ça ne marche toujours pas”, et regardez le code HTTP dans Network.

Est-ce compatible avec Elementor, Divi 5 et Avada ?

Oui. Ces builders utilisent l’uploader WordPress (Médiathèque). Si WordPress autorise le type, l’upload fonctionnera aussi dans leurs interfaces. Si vous avez un 403/406, le builder affichera juste un message plus vague.

Je suis en multisite : est-ce différent ?

Oui, un multisite peut avoir des restrictions supplémentaires, et certains réglages sont gérés au niveau réseau. Commencez par tester avec un super-admin, puis appliquez la même logique (autoriser le minimum, limiter par rôle).

J’ai un fichier .json mais WordPress dit “type non permis” alors que j’ai autorisé JSON

Le fichier peut être détecté comme text/plain ou un autre MIME selon l’outil qui l’a généré. Testez un autre export, puis si nécessaire utilisez le filtre wp_check_filetype_and_ext de manière ciblée (Solution “avancée”).

Est-ce que ça peut venir d’un cache ?

Le cache n’est généralement pas la cause directe d’un refus MIME, mais il peut vous tromper côté interface (builder qui garde un état d’erreur). Après correction, videz le cache du plugin et faites un rafraîchissement forcé du navigateur.

Quel est l’endroit le plus sûr pour mettre ce code ?

Un mini-plugin (ou un mu-plugin). Ça évite de perdre le code lors d’un changement de thème et ça réduit le risque qu’un builder ou un thème injecte des modifications imprévues.

Est-ce que ça peut venir d’une version PHP trop ancienne ?

Indirectement oui : des plugins récents (sécurité, media) peuvent se comporter mal ou se désactiver partiellement sur une vieille version PHP. En avril 2026, visez PHP 8.1+ minimum, idéalement plus récent si votre hébergeur le propose.