Manuel:Erreurs et symptômes communs

Voir aussi : Comment déboguer

Vous voyez une page blanche

Une page blanche indique une erreur PHP qui n'est pas affichée à l'écran. Pour forcer cela, ajoutez les lignes suivantes au fichier LocalSettings.php, sous <?php :

error_reporting( E_ALL );
ini_set( 'display_errors', 1 );

Vous pouvez également définir une valeur pour error_log dans PHP.ini et lire le journal des erreurs PHP pour savoir ce qui se passe. Dans certains cas, les erreurs PHP peuvent également être enregistrées dans le journal des erreurs du serveur web.

Les rapports d'erreur peuvent inclure :

• "Avertissement [...] Il n'est pas sûr de s'appuyer sur les paramètres de fuseau horaire du système. Vous devez *obligatoirement* utiliser le paramètre date.timezone ou la fonction date_default_timezone_set()." Vérifiez si date.timezone = est correctement initialisé (ou simplement initialisé) dans php.ini.
• Certains fichiers peuvent être rapportés comme étant manquants (p. ex. le dossier media dans votre dossier /includes n'est plus présent, vous pouvez recevoir le message disant qu'un processus de traitement d'images "a échoué dans l'ouverture du flux"). Vérifiez le package d'installation original sur MediaWiki (assurez-vous de consulter la version appropriée) pour voir si c'est le cas. Si oui, il vous suffit de copier les fichiers manquants dans votre répertoire MediaWiki. Il peut être nécessaire de rafraîchir le cache et de redémarrer le serveur Web par la suite.
• Le socket MySQL ne peut être trouvé. Si LocalSettings.php est initialisé sur la bonne socket MySQL mais que php.ini ne l'est pas, cela peut entraîner un écran vide sans erreur signalée de la part du serveur web ou de PHP. La solution est de mettre à jour l'entrée mysql.default_socket dans le fichier php.ini.

De nombreuses personnes rapportent obtenir des pages blanches dans les versions récentes après soumission d'articles à leur nouveau wiki. Une cause probable est la limite de mémoire dans les installations PHP par défaut (souvent 8 MB). Veuillez vérifier les journaux d'erreur de PHP et d'Apache. Pour modifier cette valeur, éditez /etc/php.ini et augmentez le paramètre "memory_limit". Par exemple pour l’amener à 32 MB , remplacez le texte existant par memory_limit = 32M. Assurez-vous de redémarrer le serveur web après avoir changé cette valeur.

La taille limite de la mémoire peut également avoir été définie dans votre fichier LocalSettings.php. Rechercher la ligne contenant la déclaration de memory_limit et augmenter selon le besoin. 20M peut ne pas suffire si vous utilisez la version 1.15.1. Modifier la valeur en memory_limit = 32M par exemple. Ce changement ne nécessite pas de redémarrer Apache.

Si la page ne se bloque pendant le chargement que durant un certain temps (comme 30 secondes) en effectuant une action spécifique, puis qu'elle se traduit par une page vide ou une erreur HTTP 500, le problème est dû au temps de connexion à un serveur. Il peut s'agir du serveur de la base de données, ou du serveur mail quand il réalise une action spécifique (si vous l'avez configuré dans les paramètres de messagerie). S'il s'agit du serveur de courriel, vérifiez que la connexion est possible à partir du serveur qui exécute MediaWiki, en utilisant par exemple un client Telnet vers le serveur et le port configurés dans $wgSMTP .

Si vous pouvez voir brièvement le contenu de la page, et que la page entière devient vide, le problème est probablement causé par la présence d'une instruction JavaScript document.write, document.writeln, ou document.open dans l'un des scripts du wiki. Vous pouvez vérifier si c'est le cas en ouvrant la console de votre navigateur (cliquez sur F12) et en rechargeant la page. Si l'onglet réseau renvoie un statut HTTP 200, et que le transfert n'est que de quelques kilo octets, il est très probable que ce soit le problème. Ce sont d'anciennes méthodes de l'interface Document qui font que la page entière est vide si elle est utilisée en dehors de la page HTML, mais qu'elle s'affiche sur les pages JavaScript du wiki. Leur utilisation est fortement déconseillée, comme indiqué dans la spécification HTML . Vous pouvez désactiver JavaScript dans votre navigateur, ou initialiser $wgUseSiteJs et $wgAllowUserJs à false pour désactiver ces scripts jusqu'à ce que vous corrigiez les scripts cassés.

Erreurs MediaWiki

Aucune page n'a de contenu, mais du texte est présent à l'édition d'une page

Facultativement avec ces messages d'erreur :

PHP Warning: preg_replace(): Compilation failed: group name must start with a
  non-digit at offset 4 in /var/www/wiki/htdocs/includes/MagicWord.php

Ceci est dû à une modification dans PCRE 8.34 qui n'autorise plus que les noms des groupes sélectionnés commencent par un chiffre. Vous devez mettre à jour MediaWiki avec une version compatible. Voir Mettre à jour à PCRE 8.33 ou plus . Le problème est résolu dans toutes les versions actuellement prises en charge de MediaWiki (voir tâche T60640). PCRE 8.33 et 8.34 ont été publiés en 2013.

Voir le rapport : Topic:Rz2zo0m88rrxqrfn, Thread:Project:Support desk/MediaWiki don't work with PCRE 8.34 (2)

Les vignettes des images ne fonctionnent pas ou ne s'affichent pas

Cette section énumère les problèmes et les solutions liés aux vignettes qui ne sont pas générées ou qui ne s'affichent pas.

Erreur de création de la vignette: fichier non trouvé

Cela peut arriver à cause de mauvaises valeurs dans les variables globales comme expliqué dans :

• Manuel:$wgUploadDirectory
• Manuel:$wgUploadPath
• Manuel:$wgScriptPath

Bogue du point décimal local dans srcset

Si les vignettes d'images ne sont tout simplement pas affichées et qu'il n'y a pas d'erreur visible sur ces pages, regardez le source HTML de la page et recherchez srcset. Si vous trouvez quelque chose comme <img ... srcset="/images/thumb/File.png/600px-File.png 1,5x, /images/thumb/File.png/800px-File.png 2x">, où figure 1,5x au lieu de 1.5x, le problème est causé par tâche T181987, et vous devriez ajouter ceci à LocalSettings.php :

setlocale(LC_NUMERIC, "C");

Assurez-vous qu'il n'y a pas de définition de $wgShellLocale dans votre LocalSettings.php, ou ajoutez aussi ceci :

$wgShellLocale = "C.UTF-8";

SVG

Voir aussi : Manuel:Gestion des images

D'abord déterminez la valeur du paramètre $wgSVGConverter . Par défaut, il est configuré pour utiliser ImageMagick pour la conversion.

Utilisation de ImageMagick

Vous devez avoir au minimum ImageMagick 6.x.x. Vérifiez que votre variable $wgImageMagickConvertCommand est valide. Les paramètres communs sont :

$wgImageMagickConvertCommand = "/usr/bin/convert";
$wgImageMagickConvertCommand = "/usr/local/bin/convert";

Si cela ne fonctionne pas, essayez le paramètre $wgSVGConverterPath .

$wgSVGConverterPath = "/usr/bin";
$wgSVGConverterPath = "/usr/local/bin";

Les hôtes partagés peuvent fournir différentes versions d'ImageMagick pour répondre aux besoins des différents utilisateurs. Veuillez utiliser la version 6.x.x.

• Pour déterminer la version d'ImageMagick, recherchez les fichiers d'aide de votre fournisseur d'hébergement ou utilisez /usr/bin/convert --version ou /usr/local/bin/convert --version pour les trouver.
• Sur les hôtes partagés Linux de GoDaddy /usr/bin/convert pour la version 5.5.6 et /usr/local/bin/convert pour la version 6.2.8.

Si la génération des vignettes avec ImageMagick échoue avec un message dans le journal des erreurs du serveur web similaire à « Memory allocation failed » ou « /bin/ulimit4.sh : Segmentation fault /usr/bin/convert ... » ou « convert : Unable to extend cache ... », la valeur de $wgMaxShellMemory peut être augmentée.

Lorsque le chemin n'a pas de caractères non ASCII

• Vérifiez si les variables locales UTF-8 sont disponibles sur votre serveur en exécutant locale -a
• Quand il n'est pas disponible, exécutez locale-gen en_US.utf8 ou mettez le dans les variables locales avec UTF-8 de votre pays et modifiez la valeur de $wgShellLocale en fonction de ceci.

Lorsque vous utilisez IIS/FastCGI sous Windows, le compte d'invité utilisé a également besoin d'une autorisation pour s'exécuter sur C:\Windows\System32\cmd.exe sinon vous recevrez l'erreur « Unable to Fork » indiquant que la création de branche n'est pas possible.

Utilisation de Batik

MediaWiki impose des limites de temps d'exécution et de mémoire pour les commandes shell sous Linux. Si vous recevez l'erreur Error occurred during initialization of VM, Could not reserve enough space for object heap, Could not create the Java virtual machine. concernant la création impossible de la machine virtuelle Java par manque d'espace, essayez d'augmenter la valeur de $wgMaxShellMemory .

Utilisation de rsvg

Sur certaines installations Linux et BSD rsvg est renommé  :

Au lieu des valeurs (par défaut)

$wgSVGConverters = array( 'rsvg' => '$path/rsvg -w$width -h$height $input $output' );

vous pouvez utiliser

$wgSVGConverters = array( 'rsvg' => '$path/rsvg-convert -w $width -h $height -o $output $input' );

JPEG

Symptome : Ce message d'erreur dans un cadre grisé :

Erreur de création de vignette : Paramètres de vignette non valides

Cause possible : le nombre de pixels dans l'image originale dépasse $wgMaxImageArea . La valeur par défaut 1.25e7 est trop petite pour de nombreux appareils modernes. Dommage que le diagnostic n'indique pas vraiment le problème.

Vous pouvez augmenter la valeur de $wgMaxImageArea ou passer à l'utilisation d'ImageMagick qui évite cette restriction (initialiser $wgUseImageMagick et $wgImageMagickConvertCommand ).

Les images de grande taille peuvent prendre un temps de traitement important. Limiter la taille des images est un bon principe.

JPEG (utilisant GD)

Symptome : Ce message d'erreur dans un cadre grisé :

Error creating thumbnail: Incomplete GD library configuration: missing function imagecreatefromjpeg

Certaines versions de PHP 4.x et 5.x de PHP contiennent un bogue où libjpeg est détecté mais n'est pas activé pendant l'étape ./configure; c'est assez commun avec les systèmes Red Hat / RHEL / CentOS. Si vous ne voulez pas utiliser ImageMagick, la solution est de recompiler PHP. D'abord cherchez (à partir de phpinfo()) ce qu'étaient les sélecteurs existants ./configure, et ajoutez --with-jpeg-dir avant --with-gd.

make clean
./configure --with-différents-sélecteurs --with-jpeg-dir --with-gd --with-sélecteurs-supplémentaires
make
make test
# passer sous ''root''
make install

Ensuite démarrez le serveur web (pour Apache de Red Hat : service apache stop puis service apache start ). Pour tester, afficher simplement la page File:... à nouveau (inutile de la recharger). Pour plus d'information, voir les commentaires sur PHP: imagecreatefromjpeg (synopsis de la fonction)

Impossible d'enregistrer la vignette sur la destination

Si vous obtenez l'erreur « Error generating thumbnail / Error creating thumbnail: Unable to save thumbnail to destination » qui indique que la vignette générée n'a pas pu être enregistrée sur la cible et que le répertoire $wgUploadDirectory a les autorisations correctes (à tous les niveaux), vérifiez que $wgTmpDirectory existe réellement. (A la différence de certaines variables de chemin telles que $wgCacheDirectory , $wgTmpDirectory n'est pas créé au moment de l'exécution). Un message d'erreur plus détaillé peut être obtenu si vous activez la journalisation avec $wgDebugLogFile .

Cette erreur peut également se produire lorsque le mode lecture seule ($wgReadOnly ) a été défni dans LocalSettings.php. Vous pouvez essayer de supprimer $wgReadOnly pour voir si cela résout votre problème.

Erreur de création de la vignette Code d'erreur : 25

Si vous obtenez l'erreur Error creating thumbnail Error code: 25 concernant la création impossible des vignettes avec ImageMagick, essayez d'augmenter $wgMaxShellFileSize .

Ajouter manuellement les fichiers des vignettes

Dans les cas où il n'est pas possible de créer les vignettes dynamiquement sur demande (par exemple, pour des images très grandes, « Error creating thumbnail: unable to extend cache », « Error creating thumbnail: convert: no images defined » ou similaires) concernant les erreurs de cache non extensible ou de conversion d'image, il est possible d'ajouter manuellement les fichiers de vignette. Cela implique de créer des images plus petites dans les tailles souhaitées et les téléverser dans le répertoire thumb/ de $wgUploadDirectory .

Par exemple, un fichier téléversé sur :

images/f/f8/Foo.png

devrait avoir ses vignettes sur :

images/thumb/f/f8/Foo.png/100px-Foo.png
images/thumb/f/f8/Foo.png/600px-Foo.png

La taille en pixels est la dimension horizontale. Un exemple de script Bash pour créer des vignettes est disponible sur Phabricator:P7049.

Erreur de création de vignette : Code d'erreur : -1 sur l'hébergement mutualisé OVH

Pour une raison non identifiée, la création de vignettes sur certains hébergements OVH mutualisés échoue avec cette erreur, même si l'exécution de la commande dans le shell SSH fonctionne.

La solution est d'empêcher spécifiquement l'utilisation de ImageMagick en initialisant $wgUseImageMagick à false dans LocalSettings.php :

$wgUseImageMagick = false;

Désolés ! Nous n’avons pas pu traiter votre modification en raison d’une perte de données de session. Veuillez réessayer. Si cela ne fonctionne toujours pas, essayez de vous déconnecter et de vous reconnecter.

Page principale : Manual:How to debug/Login problems

Limites de contenu

Si votre serveur Apache dispose du correctif Hardened PHP, vous devrez peut-être modifier plusieurs variables dans votre fichier /etc/php.ini si vous souhaitez avoir des pages wiki avec de grandes quantités de contenu. En particulier, considérez les paramètres pour varfilter.max_value_length, hphp.post.max_value_length, hphp.request.max_value_length. Les paramètres par défaut peuvent limiter la taille de vos pages à moins de 10 Ko ou 64 Ko.

Une autre possibilité est que si votre serveur Apache utilise mod_security, cela peut interférer avec MediaWiki. Vous devrez le désactiver pour que MediaWiki fonctionne correctement.

Vous n’avez pas spécifié de nom d’utilisateur valide / Modifications et aperçus de pages complètement vierges / Impossible de téléverser

Cela est dû à quelque chose qui tronque ou envoie des données POST du navigateur au serveur Web.

Dans une instance au moins, cela a été causé par le fait que post_max_size et upload_max_filesize dans php.ini étaient trop élevés (2048 Mo). Les ramener à des valeurs plus saines (8 Mo) résout le problème. Apparemment, aucune donnée POST n’arrive à MediaWiki.

Sur une autre instance, mod_auth_sspi interférait avec les messages http vers MW. L’utilisation de FireFox et la saisie des informations d’identification du domaine fonctionneraient correctement, mais MS Internet Explorer échouerait. Il s’agit d’un défaut connu dans mod_auth_sspi 1.0.4.

Plusieurs options s’offrent à vous pour que cela fonctionne :

• Désactivez SSPIOfferSSPI ← les utilisateurs seront invités et devront entrer les informations d’identification du domaine, comme en mode BASIC
• Définir SSPIPerRequestAuth sur ← Je ne vois pas en quoi c’est une configuration saine, mais cela a fonctionné (sauf sur la connexion à latence élevée avec laquelle je suis obligé de faire face)
• Rétrograder vers la version 1.0.3, mais c’est fondamentalement la même chose que #2 ci-dessus.

Le wiki apparaît sans les styles appliqués et les images sont manquantes

Si le wiki a l’air correct quand vous le parcourez à partir du même serveur où il est hébergé mais qu’il apparaît sans styles CSS appliqués (pas de couleurs, pas d’arrière-plan, pas d’images, formatage très minimal, etc.) si vous y accédez à partir d’autres machines (ou de certaines d’entre-elles), la cause la plus probable est que le serveur a des problèmes pour déterminer l’adresse IP ou le nom d’hôte utilisé pour y accéder, ou qu'il est mal configuré. Cela entraîne la génération de l'URL des styles et des images avec l’adresse IP de rebouclage 127.0.0.1 de l’hôte local (localhost) ou d’un nom d’hôte inconnu en dehors du serveur. Vous pouvez voir le code source de n'importe quelle page et vérifier à quoi ressemblent les URL et ce qui se passe quand vous essayez de les accéder directement à partir de votre navigateur.

La solution est d'initialiser manuellement la variable $wgServer avec le nom de l'hôte que chacun utilisera pour accéder au wiki.

Si votre wiki est accessible à partir d'un réseau interne et d'un réseau externe, vous devrez peut-être utiliser l'adresse externe pour $wgServer. N'oubliez pas le numéro de port si vous utilisez un port non standard, comme dans le cas si votre FAI a bloqué le port 80 (Exemple : $wgServer = "http://example.domain.com:8080";)

Si les styles ne sont pas appliqués, même pendant la navigation sur le wiki du serveur où il est hébergé, le problème peut être une erreur PHP sur le script load.php ResourceLoader . Essayez d'afficher le fichier load.php de votre installation MediaWiki dans votre navigateur web et voyez si des erreurs sont apparues ou simplement une page blanche (voir la section Vous voyez une page blanche). Vous devriez voir un message similaire à /* No modules requested. Max made me put this here */. Si c'est le cas, il peut s'agir d'un problème avec le fichier .htaccess du serveur web.

Si vous voyez à la place une erreur 404 Not found, cela peut être un problème lié aux règles de réécriture du serveur web et à la configuration des URL courtes.

Si vous recevez des réponses Erreur 500 de l'URL load.php, analysez les journaux d'erreur du serveur web pour obtenir plus d'informations sur les erreurs. Il semble y avoir un problème avec certaines versions de PHP et Gentoo génère des segfault dans Apache. Cela peut également se produire si vous avez activé APC; déclarer apc.serializer=php dans php.ini pourrait aider.

Depuis MediaWiki 1.23, vous pouvez obtenir un wiki avec la plupart des styles d'habillage spécifiques à Vector, comme la barre latérale placée en fin de la page. Cela peut être dû à une faible valeur de pcre.backtrack_limit dans certaines distributions comme FreeBSD. Vous savons que les valeurs de 10 000 posent problème. Augmentez cette valeur à 100 000 ou la valeur par défaut actuelle de 1 000 000.

Depuis MediaWiki 1.26, certains habillages et particulièrement Vector, peuvent présenter ce problème. Si l'erreur Internal error Problematic modules: {"startup":"error"} apparaît dans la console d'erreur de votre navigateur, l'origine la plus probable concerne les droits insuffisants de MediaWiki pour écrire dans le répertoire temporaire, soit parce que PHP n'a pas le droit d'écriture dans /tmp (C:\WINDOWS\TEMP sous Windows), ou parce qu'il existe une restriction open_basedir et que ce chemin n'y est pas inclus. Voir tâche T119934. Vous pouvez également définir $wgTmpDirectory si vous ne pouvez pas modifier les autorisations dans le répertoire temporaire par défaut du système.

Erreur : mot magique 'speciale' incorrect

Version de MediaWiki :

≥ 1.20

Si vous recevez ce message d'erreur après la mise à jour, vous devez exécuter le script de maintenance rebuildLocalisationCache.php avec l'option --force :

php rebuildLocalisationCache.php --force

Les chaînes traduites affichent leur ID de message au lieu du résultat de traduction

Si vous voyez ceci, essayez d'exécuter le script de maintenance rebuildLocalisationCache.php avec l'option --force :

php rebuildLocalisationCache.php --force

Cela obligera MediaWiki à reconstruire le cache des traductions.

Barre d'outils absente, JavaScript n'est pas opérationnel

Depuis MediaWiki 1.32 , MediaWiki n'intègre plus la barre d'outils wikicode "Propulsé par JavaScript". Nous avons supprimé l'ancienne barre d'outils de style tableau de bord connue sous le nom de Editeur de wikicode 2006 pour donner le choix aux administrateurs système, entre une ou plusieurs extensions disponibles pour cela, s'ils ont besoin de cette fonctionnalité. Les versions des archives tarball MediaWiki ont inclus l'extension de remplacement pour cela, l'extension WikiEditor avec l'Editeur de wikicode 2010, pour beaucoup d'années maintenant. Assurez-vous que cette extension a été installée.

Si JavaScript ne fonctionne pas (l'un des symptômes est que la barre d'outils d'édition n'apparaît pas lors de la modification d'une page), cela peut être dû à une erreur JavaScript. Ouvrez la console d'erreur de votre navigateur web (généralement en appuyant sur F12), rechargez la page et voyez si des messages d'erreur apparaissent. Si une erreur est affichée, vous obtiendrez plus d'informations en déclarant $wgShowExceptionDetails . Parfois, le problème est que le répertoire temp du système n'est pas accessible en écriture. Dans ce cas, vous pouvez également définir $wgTmpDirectory s'il ne vous est pas possible de modifier les droits dans le répertoire temporaire par défaut du système.

Si vous obtenez des erreurs similaires à Uncaught SyntaxError: Unexpected token < ou Error: SyntaxError: syntax error (...) Source Code: <script (...), l'origine est souvent que le fournisseur d'hébergement injecte automatiquement du code HTML pour vous suivre (ou de la publicité) dans le script Load.php utilisé par ResourceLoader pour charger les scripts et le CSS utilisé par MediaWiki. Ouvrez un ticket chez votre fournisseur d'hébergement en lui demandant de désactiver cette injection. Si cela n'est pas possible, migrez votre site vers un autre fournisseur d'hébergement. Cela arrive habituellement avec des fournisseurs d'hébergement gratuit.

Chaque page affiche une erreur fatale et le journal contient "MagicWordArray::parseMatch: parameter not found"

Essayez de reconstruire le cache des traductions :

php maintenance/rebuildLocalisationCache.php

Issu de ce fil de discussion.

Tous les téléversements échouent avec le message "The file you uploaded seems to be empty..."

Cela peut être dû à de mauvaises règles de réécriture lors de la configuration des URLs courtes. Essayez de les désactiver (ainsi que les variables de configuration connexes de MediaWiki) pour voir si cela résoud le problème.

Un autre problème peut être la limite imposée par le serveur Web quant au nombre de données que le serveur peut recevoir sur une seule requête. Voir Limiter la taille des téléversements pour certaines variables de configuration. Si mod_security ou suhosin sont installés, ils peuvent également limiter la taille des fichiers téléversés, en rejetant le téléversement entièrement sans que PHP le remarque.

Vérifiez également la directive de configuration upload_tmp_dir de php.ini, et assurez-vous que le dossier dispose des droits d'écriture appropriés pour le compte de l'utilisateur qui exécute PHP. Sous Windows, cette directive pointe souvent sur C:\Windows\TEMP, qui ne sont peut-être pas accessibles dans certaines circonstances. Dans ce cas, vous pouvez définir un dossier temporaire différent tel que C:\TEMP\ avec vos propres droits. Pour éliminer les autres problèmes, donnez temporairement toutes les autorisations à ce dossier (sous Windows, ajoutez le groupe d'utilisateurs local Tous les utilisateurs avec les autorisations complètes), puis restreignez les autorisations si nécessaire dès que vous aurez vérifié que les téléchargements fonctionnent.

Si tous les téléchargements échouent avec le message Le fichier que vous voulez téléverser semble vide. Ceci peut être dû à une erreur dans le nom du fichier. Veuillez vérifier que vous désirez vraiment téléverser ce fichier., et que les journaux d'erreur Apache contiennent des entrées comme :

Notice: Undefined index: tmp_name in /srv/www/htdocs/mediawiki/includes/WebRequest.php on line 1153
Notice: Undefined index: size in /srv/www/htdocs/mediawiki/includes/WebRequest.php on line 1140
Notice: Undefined index: error in /srv/www/htdocs/mediawiki/includes/WebRequest.php on line 1167

C'est un problème lié à la version PHP utilisée par votre serveur. Ce problème a été rapporté plusieurs fois avec PHP 5.3.8 sur SLES11 sp2. Vous devrez peut-être mettre à jour PHP ou le recompiler vous-même.

WAMP/Apache sous Windows : certaines pages spéciales sont are inaccessibles

Il peut arriver sous Windows avec Apache, que certaines Pages spéciales soient inaccessibles et produisent une erreur qui dans les journaux se traduit par :

[core:error] The given path is misformatted or contained invalid characters: [client 127.0.0.1] AH00127: Cannot map GET /wiki/Special:SpecialPages HTTP/1.1 to file

Cela peut être causé par divers bogues PHP. L'un d'entre eux est lorsque le wiki est installé dans une jonction NTFS. Si ce n'est pas le problème, essayez de mettre à jour pour une version plus récente de PHP (voir ce fil de discussion sur le forum)

Erreur "403 Forbidden" ou redirection sur la page d'accueil lors de l'enregistrement d'une modification

C'est un problème courant avec les hôtes partagés qui ont activé mod_security. Pour savoir si c'est un problème de mod_security ou pas, créez une simple page de test et enregistrez-la avec un texte court (comme un point pour tout contenu). Si la modification est enregistrée mais pas les autres, cela est dû à mod_security . Demandez au support client de votre hébergeur de le désactiver complètement ou quelles sont les règles qui concernent vos modifications.

Si même en sauvegardant une modification très simple vous êtes redirigé vers la page principale ou vers la même page sans que la modification n'apparaisse, il peut s'agir d'un problème avec la façon dont vous avez configuré $wgServer ou d'une autre variable de configuration qui contrôle le chemin du script index.php, ou de conflits avec les règles de réécriture dans la configuration de votre serveur web.

Page de connexion avec cookies désactivés

You may get a message like MediaWiki utilise des témoins (cookies) pour conserver la connexion mais vous les avez désactivés. Veuillez les activer et vous reconnecter..

Si les cookies ne sont pas désactivés dans votre navigateur, cela peut être l'un des problèmes :

• Vous avez $wgSessionsInMemcached initialisé à true mais MediaWiki ne peut pas se connecter à Memcached. Désactivez ce paramètre ou vérifiez la configuration de Memcached.
• Mauvaise configuration de cookie. Les variables de configuration concernant les cookies doivent fonctionner avec leurs valeurs par défaut. Essayez de ne pas les redéfinir.
• session_save_path() n'est pas correctement configuré sur le serveur, ou le serveur n'a pas les droits pour écrire sur ce chemin.
• Si vous utilisez une sorte de proxy de mise en cache devant MediaWiki, vérifiez qu'il ne filtre aucun cookie.
• session.referer_check() est mal initialisé. Normalement vous devriez le laisser vide.

En déclarant un journal de débogage vous devriez voir les cookies reçus par MediaWiki et ce serait une première étape pour voir s'il sont effectivement reçus par MediaWiki ou pas.

MediaWiki ne fonctionne pas lorsque les guillemets magiques sont opérationnels

Version de MediaWiki :

≤ 1.23

Version de MediaWiki :

≥ 1.24

Les apostrophes magiques (magic quotes) était une fonctionnalité de PHP qui est devenue obsolète en PHP 5.3 et supprimée dans PHP 5.4. Si vous obtenez cette erreur, vous devez désactiver les citations magiques dans les paramètres de serveur. Voir comment faire cela.

Discussions : Thread:Project:Support_desk/Problems_with_installing_mediawiki, Topic:S79xdn9u15xw55vj, Topic:Sdpbmy9q9e0ttp6k, Topic:S7g4rybniat2i36e, Topic:S6vqwk0tysl6m8lc

Erreur à la création des vignettes: Fichier dont la taille est supérieure à 12,5 méga pixels

Il peut être utile d'augmenter $wgMaxImageArea pour se débarrasser du problème (essayé avec MediaWiki 1.26.2).

Erreur interne du serveur à l'ouverture des images

Si les images ne s'affichent pas sur les pages, et que l'ouverture manuelle de l'URL de toute image produit une page d'erreur interne du serveur, le problème est probablement causé par le fichier .htaccess du répertoire images. Ce fichier de configuration contient certaines règles de réécriture pour empêcher que les anciennes versions d'Internet Explorer ne soient affectées par une faille des scripts inter site. Cependant, certains hôtes comme strato.de empêchent de désactiver la directive RewriteOptions dans .htaccess, ce qui génère une erreur pour toute demande de fichier dans le dossier des images. Si vous ne pouvez pas activer les règles de réécriture sur le fichier .htaccess, vous devrez peut-être décommenter ou supprimer ces lignes de .htaccess ou tout ce qu'il contient. Voir ce fil de discussion.

Les modifications ne sont pas dans les modifications récentes, ces dernières ne sont pas à jour

Par défaut, il y a un filtre dans les Modifications récentes pour masquer les modifications faites par les robots. Désactivez ce filtre pour voir si les modifications apparaissent.

S'il est activé et que l'affichage des modifications faites par robot ne figure pas dans la liste des modification récentes, le problème vient souvent d'une extension installée qui provoque une erreur lorsque les modifications récentes sont mises à jour. La mise à jour des modifications récentes lors de l'exécution d'une modification ou autre action est retardée jusqu'à ce que la page soit envoyée au navigateur. Cependant, une erreur peut annuler ces mises à jour et l'erreur ne sera pas affichée à l'utilisateur. Pour détecter de telles erreurs, déclarez un fichier comme journal du debogage (n'oubliez pas de le désactiver une fois vos investigations terminées), et enregistrez une nouvelle modification de page. Si une erreur se produit, elle devrait y être tracée — mais notez-bien que vous allez y trouver beaucoup d'autres éléments, essayez de chercher « error » ou « exception ». Une erreur peut fournir une trace de la pile d'exécution et indiquer l'extension qui en serait la cause.

Vérifiez que vos extensions sont compatibles avec votre version de MediaWiki.

Les pages des catégories, les pages liées, et l'utilisation du fichier ne sont pas mis à jour

Les informations sur les pages d'une catégorie, les liens vers d'autres pages wiki et les images incluses dans les pages sont tracés dans des tables spéciales. La mise à jour de ces tables n'est pas faite immédiatement après la sauvegarde des modifications mais dévolue à une tâche mise en file d'attente des travaux pour des raisons de performance. Si la mise à jour dure trop longtemps, essayez d'ajuster $wgJobRunRate ou d'initialiser $wgRunJobsAsync à false dans LocalSettings.php. Cela peut se produire avec certaines installations, en particulier depuis MediaWiki 1.27 (voir tâche T142751).

Erreur : Could not open lock file for "mwstore://local-backend/local-public/./../image.png

Ce message indique qu'il est impossible d'ouvrir le fichier indiqué qui est verrouillé. Vérifiez que le répertoire images dispose de droits autorisant l'écriture. Par exemple : chown -R www-data:www-data images et chmod -R 777 images. Si vous avez activé SELinux, cela peut également poser problème.

Notice: Did not find alias for special page 'Foo'. Perhaps no aliases are defined for it? [Called from SpecialPageFactory::getLocalNameFor in ...

Ce message indique qu'il n'y a pas d'alias pour la page spéciale indiquée et donne l'endroit où il a été appelé. Vous devez créer un fichier d'alias. Donc mettez quelque chose comme ceci dans votre fichier extension.json :

	"ExtensionMessagesFiles": {
		"SpecialMyExt": "MyExt.alias.php"
	},
	"MessagesDirs": {
		"MyExt": [
			"i18n"
		]
	},

Puis créez un fichier d'alias comme ceci :

MyExt.alias.php

<?php
/**
 * Aliases for Special:Foo
 *
 * @file
 * @ingroup Extensions
 */

$specialPageAliases = [];

/** English (English) */
$specialPageAliases['en'] = [
   'MyExt' => [ 'MyExt' ],
];

Vérifiez qu'il n'existe pas d'autres éléments $wgMessagesDirs possédant la même clé. Les clés de $wgExtensionMessagesFiles qui sont aussi dans $wgMessagesDirs seront sautées.

Warning: Invalid argument supplied for foreach() in ./includes/objectcache/SqlBagOStuff.php

Vous avez peut-être déplacé votre wiki sans importer la base de données, donc elle est vide.

Warning: Invalid argument supplied for foreach() in ./includes/cache/localisation/LocalisationCache.php on line 459

To fix the warning uncomment in LocalSettings.php line

#$wgCacheDirectory = "$IP/cache";

Il semble y avoir un problème avec la connexion à votre session; cette action a été annulée par précaution contre l'usurpation de session. Veuillez soumettre à nouveau le formulaire.

Veuillez suivre Manuel:Comment déboguer/Problèmes de login .

Appel d'une méthode non définie

Si une extension MediaWiki affiche cette erreur après avoir été installée, vérifiez que vous avez téléchargé la version ou la branche de cette extension correspondant à la version ou à la branche de votre installation MediaWiki.

Impossible d'exécuter des programmes externes, proc_open() est désactivé

La fonction a été déclarée obsolète dans php.ini. Ceci empêche l'utilisation de ImageMagick pour redimensionner les images pour créer les vignettes. Contactez votre fournisseur d'hébergement ou essayez d'utiliser gd au lieu de ImageMagick en initialisant $wgUseImageMagick à false.

<span id="CAS_update_failed_on_user_touched_for_user_ID_'*'_(read_from_slave);_the_version_of_the_user_to_be_saved_is_older_than_the_current_version">

CAS update failed on user_touched for user ID '*' (read from slave); the version of the user to be saved is older than the current version

Ce message indique un échec lors de la mise à jour du CAS où la version de l'utilisateur est plus ancienne que la version actuelle. Cette erreur peut avoir plusieurs causes. Un cas simple est si le contenu de user.user_touched est vide ou sera initialisé ultérieurement.

Vous pouvez vérifier que l'heure du serveur est bien initialisée et synchronisée. Vérifiez également le contenu de cette colonne et remplissez-la avec un contenu valide, par exemple avec cette instruction SQL :

UPDATE `user` SET user_touched='20241121114211'
WHERE HEX(
	user_touched
)='0000000000000000000000000000';
-- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-- 28 zéro

Où la date est au format AAAAMMJJHHMMSS pour la date et l'heure actuelle. Voir phab:T247751.

Erreur Lua : erreur interne

Page principale : Extension:Scribunto#Troubleshooting

Une erreur de base de données s'est produite sur un QUERY. Cela peut être dû à un bogue dans le logiciel.

Si vous avez récemment mis à niveau MediaWiki, ou installé ou mis à niveau des extensions, essayez d'exécuter le script de maintenance update.php . (Voir aussi Mise à jour ).

Si cela ne vous aide pas, alors vous avez peut-être vraiment rencontré un bogue du logiciel. Essayez d'obtenir plus de détails sur l'échec de la requête (Comment déboguer ) et créez un ticket pour le bogue .

La clé $wgSecretKey n'est pas sécurisée, générée avec mt_rand()

Votre système ne prend pas en charge /dev/urandom donc la clé a été générée avec mt_rand(). Voir $wgSecretKey .

MediaWiki nécessite PHP 7.4.3 ou plus récent ; vous utilisez PHP 7.3.17

Si la version PHP de votre serveur web est assez récente, vérifiez s'il n'y a pas plusieurs versions de PHP installées en parallèle.

Créez un fichier nommé info.php avec pour contenu sur une seule ligne <?php phpinfo(); et placez ce fichier dans le répertoire web. Tentez d'y accéder avec votre navigateur. Cela affichera la version PHP utilisée par votre serveur web.

Erreurs PHP

Erreur fatale : Allowed memory size of X bytes exhausted (tried to allocate Y bytes)

Ce message indique qu'il n'y a plus assez de mémoire pour allouer Y octets.

Augmenter la limite de la mémoire PHP dans php.ini :

memory_limit = 64M      ; Quantité maximale de mémoire qu'un script peut utiliser (32 Mo)

Version de MediaWiki :

≥ 1.16

Vous pouvez ajouter une valeur plus grande à $wgMemoryLimit dans LocalSettings.php.

Version de MediaWiki :

≤ 1.15

Dans les versions 1.15 et antérieures, la limite de la mémoire déclarée dans php.ini peut être redéfinie par défaut dans LocalSettings.php avec la ligne :

ini_set('memory_limit', '20M');

Vous pouvez augmenter la limite de la mémoire ici, ou mettre cette ligne en commentaire dans LocalSettings.php pour utiliser la limite spécifiée dans php.ini.

Cette erreur peut apparaître pour d'autres raisons. Recherchez l'utilisation d'Unicode sur les systèmes qui ne le prennent pas correctement en charge. Recherchez le nom du fichier et la ligne et si vous trouvez que vous êtes dans une section de traduction de langue qui utilise des caractères non ASCII, supprimez cette section. Si vous avez augmenté la RAM allouée à PHP à 512 Mo et que vous avez *encore* le même problème d'erreur mémoire, il n'est pas sûr qu'il s'agisse d'un problème de mémoire en soi.

Lisez l'information de php.net sur la configuration des limites des ressources PHP.

Erreur fatale : Class 'DOMDocument' not found in xxxxxxxx/Preprocessor_DOM.php on line nnn

Cette erreur indique que la classe DOMDocument n'a pas été trouvée et indique d'où elle a été appelée.

Cette erreur se produit lorsque PHP n'a pas été compilé avec le support DOM, ou que l'extension DOM/xml est absente.

• Installez le bon package php-xml pour votre distribution. Exemple : sudo yum install php-xml
• Alternativement, modifiez la classe MediaWiki 'preprocessor' en LocalSettings.php (voir $wgParserConf )

$wgParserConf['preprocessorClass'] = 'Preprocessor_Hash';

Fatal error: Invalid opcode 153/1/8. in xxx/includes/cache/MessageCache.php on line nnn

Ce message d'erreur fatale indique qu'un code d'opération non valide a été utilisé et fournit l'endroit. Ce problème semble indiquer qu'il s'agit d'un problème avec un accélérateur de code PHP qui ne correspond pas à la version installée de PHP ou qu'il est obsolète. Essayez de mettre à jour l'accélérateur. report

Warning: Cannot modify header information - headers already sent by (...)

Cet avertissement indique que l'entête ne plus être modifiée car les entêtes ont déjà été envoyées. La plupart du temps votre éditeur de texte ajoute un marqueur d'ordre des octets (BOM — byte order mark) quand vous modifiez les fichiers PHP de MediaWiki, mais tout autre contenu précédant le <?php ouvrant provoque le même problème. Cela se produit habituellement avec LocalSettings.php - mais voir le message d'erreur pour le fichier exact. Notez que les BOM sont invisibles dans la plupart des éditeurs de texte. Pour supprimer le BOM, modifiez le fichier avec quelque chose de meilleur que le Notepad de Windows, mais si vous n'avez pas le temps - ouvrez le fichier néanmoins avec Notepad et choisissez Enregistrer sous..., puis sélectionnez Unicode (UTF-8 Without signature) - Codepage 65001 comme type de fichier.

Strict Standards: date_default_timezone_get(): It is not safe to rely on the system's timezone settings.

Ceci indique que conformément aux standards, il n'est pas fiable de se référer aux paramètres du fuseau horaire. Si vous obtenez Strict Standards: erreurs dans la sortie HTML, c'est parce que votre variable de configuration PHP error_reporting vaut E_ALL, mais depuis PHP 5.4.0, E_STRICT fait partie de E_ALL. Les E_STRICT ne sont pas des erreurs, mais des avertissements sur l'interopérabilité du code et la compatibilité avant du code PHP; ils ne doivent pas être visibles dans les environnements de production.

Ajoutez simplement votre fuseau horaire à LocalSetting.php, par exemple

$wgLocaltimezone = 'Europe/Berlin';

Ce qui suit ne fonctionne pas dans tous les cas. Il est préférable de mettre ceci dans php.ini qui doit être présent dans tous les répertoires concernés.

Vous pouvez masquer les erreurs E_STRICT en mettant la ligne de code suivante à l'intérieur de votre LocalSettings.php , ou si une ligne avec la fonction error_reporting existe, la remplacer par :

error_reporting( E_ALL & ~( E_STRICT | E_NOTICE ) );

Vous pouvez désactiver complètement les rapports d'erreur PHP en utilisant ceci :

error_reporting( 0 );

Voir aussi : Configurer les rapports d'erreur en PHP.

Si rien ne fonctionne, vérifiez le début de LocalSettings.php file : Si cette erreur survient pendant la configuration, le LocalSettings.php généré pourrait inclure le message d'erreur tout au début (exemple). Si c'est ce qui s'est passé, modifiez le fichier en supprimant tout avant <?php et vérifiez qu'il n'y a rien (aucun espace) avant <?php.

Erreur fatale : impossible de redéclarer wfprofilein()

Cela pourrait arriver si vous avez mis à niveau MediaWiki et que vous avez un fichier StartProfiler.php à la racine du répertoire d'installation, probablement parce que vous aviez activé le profilage dans une ancienne installation. Pour résoudre le problème, il suffit de supprimer ce fichier.

Avertissement : fichiers inaccessibles

Après avoir fait le transfert, des avertissements PHP peuvent apparaître disant que certains fichiers ne sont pas accessibles. Ceci probablement causé par tâche T37472 : La colonne md_deps de la table module_deps contient les chemins absolus des fichiers; ils sont utilisés pour localiser les images et les fichiers LESS desquels dépend ce CSS. Ces chemins sont cassés quand le wiki est par exemple déplacé vers un autre répertoire ou vers un autre serveur. En attendant que ce bogue soit résolu, vous pouvez utiliser ce contournement pour corriger manuellement les entrées erronnées de la table module_deps :

-- Mettre à jour des entrées de la table <code>module_deps</code>
SET @old='wiki.old-domain.org';
SET @new='wiki.new-domain.org';

UPDATE `module_deps` SET `md_deps` = REPLACE( `md_deps`, @old, @new );

Cela peut être utilisé pour mettre à jour les mauvais segments de chemin et corriger l'erreur.

Versions de MediaWiki :

1.17 – 1.26

Un problème similaire peut apparaître lorsque MediaWiki essaie de lire les messages de ResourceLoader. Dans ce cas la solution est de tronquer les tables correspondantes :

-- Tronquer les caches liés aux messages
TRUNCATE TABLE `msg_resource`;
TRUNCATE TABLE `msg_resource_links`;

Erreur fatale : Exception non interceptée : extension.json n'existe pas

Version de MediaWiki :

≥ 1.25

Voir aussi : Manuel:Enregistrement des extensions

Si cette erreur survient lorsque vous essayez d'installer une extension, cela signifie généralement que l'extension nécessite toujours d'utiliser le constructeur du langage PHP natif require_once au lieu de la méthode wfLoadExtension() plus récente.

Erreurs d'installation

LocalSettings.php non accessible en lecture

• Sur une machine Linux, utiliser chown ou chgrp pour corriger les droits d'accès au fichier LocalSettings.php.
• Sur certaines machines Linux, désactivez temporairement SELinux en exécutant la commande sudo setenforce 0.

L'installeur n'a pas de style lors de l'installation sous IIS

L'installeur n'a pas de style et au lieu de la feuille de style, /mw-config/index.php?css=1 affiche ce message d'erreur pour indiquer que le répertoire de cache n'est pas accessible en écriture : "Less_Exception_Parser from line 447 of ...\vendor\oyejorge\less.php\lib\Less\Parser.php: Less.php cache directory isn't writable: C:\Windows\TEMP"

Assurez-vous que l'utilisateur du serveur web, qui est par défaut IUSR, est autorisé à accéder au répertoire C:\Windows\TEMP. Au minimum les droits en lecture et en écriture sont nécessaires.

Erreur lors de la sélection de la base de donnée wikidb : 1044 accès refusé pour l'utilisateur 'username'@'localhost' à la base de données 'wikidb'

Voir aussi : Guide d'installation

Vous devez donner les droits sur wikidb.*.

GRANT ALL ON wikidb.* TO 'username'@'localhost' IDENTIFIED BY 'password';

ou si votre serveur web est sur une boîte différente de votre serveur de base de données - vous devez configurer l'accès distant à MySQL et accorder les droits différemment

GRANT ALL ON wikidb.* TO 'username'@'192.168.0.x' IDENTIFIED BY 'password';

NOTE : remplacez 192.168.0.x par l'adresse IP de votre serveur web. Noter que les apostrophes (') doivent rester.

La base de données renvoie le message d'erreur "1142: CREATE command denied to user 'username'@'localhost' for table 'user_properties' (localhost)"

Ce message indique que le CREATE a été refusé suite aux proriétés actuelles de l'utilisateur.

Comme ci-dessus, ou utiliser temporairement l'utilisateur Mysql root.

Impossible de trouver un pilote de base de données compatible

Le support PHP MySQL n'est pas installé ou activé - Voir https://php.net/book.mysqli. Selon votre système d'exploitation, vous devrez peut-être installer un package supplémentaire. Par exemple, sous debian/ubuntu, exécutez sudo apt install php-mysql.

Erreurs dans la casse du nom de fichier

Si vous utilisez un client FTP différent de FileZilla pour téléverser les fichiers sur votre serveur, vérifiez les paramètres du client pour qu'il ne mette pas les noms de fichier en majuscules ou en minuscules. Les noms de fichiers MediaWiki sont sensibles à la casse.

Erreurs de téléversement non terminé

Le paquet MediaWiki comprend beaucoup de fichiers répartis sur des dizaines de répertoires. Soyez prudent lors du téléversement. Si le transfert est interrompu, vous pourriez avoir des fichiers manquants ou incomplets. Vous devrez peut-être réessayer votre téléversement plusieurs fois, surtout si vous avez une connexion peu fiable.

403 Interdit avec des liens symboliques

Si votre serveur Web produit une page Erreur 403 interdite et que vous utilisez des liens symboliques, assurez-vous que votre fichier Apache httpd.conf a Options FollowSymLinks pour autoriser les liens symboliques et pour que chaque répertoire menant à votre répertoire lié a les droits +x pour l'utilisateur qui exécute httpd.

HTTP 500 erreur interne durant l'installation

Si votre serveur web génère une erreur 500 Internal Error au début du processus d'installation, il est possible que vous deviez mettre les droits sur le répertoire mw-config à 755. Si vous avez changé les droits sur le répertoire de configuration et que vous obtenez toujours une erreur d'accès en écriture, essayez de modifier le propriétaire pour qu'il soit Apache.

chown -R apache:apache /var/www/html/mediawiki/*

HTTP 500 Erreur interne après l'installation

Si vous avez téléchargé le code MediaWiki à partir de Git et qu'après l'avoir installé vous obtenez 500 Internal Error lorsque vous tentez d'accéder à votre installation MediaWiki à partir du navigateur web, allez dans le dossier de votre installation MediaWiki et exécutez les commandes suivantes :

find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;

SELinux

Page principale : SELinux

Les distributions Linux qui prennent en charge les extensions de sécurité SELinux ('Security Extensions') sont de plus en plus courantes. Sur ces systèmes, les scripts PHP ne seront pas toujours en mesure d'écrire dans le répertoire de configuration, après avoir attribué les droits standard d'accès aux fichiers. Vous devrez également utiliser la commande chcon pour modifier le type de fichier SELinux.

Annonce nécessaire sur les sites hébergés

Si vous exécutez le logiciel MediaWiki sur un site gratuit qui nécessite des bannières ou des publicités préfixées, cela peut entraîner le non-fonctionnement de MediaWiki en semblant générer des pages vides après la bannière publicitaire. Vous devrez contacter votre hôte et demander de que leur publicité soit compatible avec MediaWiki, ou choisir un hôte différent.

Debian, Apache2, et PHP

Si vous exécutez MediaWiki sous Debian avec Apache2 et PHP5 et que vous rencontrez des problèmes de connexion à MySQL, par exemple vous recevez le message suivant dans votre navigateur : (Can't contact the database server: MySQL functions missing, have you compiled PHP with the --with-mysqli option?) essayez de décommenter extension=mysqli.so dans le fichier /etc/php5/apache2/php.ini.

Si cela ne fonctionne pas, essayez ceci...

Vérifiez que le module MySQL pour Php est installé :

dpkg --list | grep php-mysql

Si vous devez installer le module php5-mysql, entrez :

apt-get install php-mysql

Puis redémarrez Apache2 :

/etc/init.d/apache2 restart

'user_password' ne peut avoir de valeur par défaut

Assurez-vous que MySQL ne fonctionne pas en mode strict.

Préfixe de table manquant

Si vous utilisez un service d'hébergement, le nom de base de données et le nom d'utilisateur de base de la base de données peuvent avoir un préfixe supplémentaire (normalement l'identifiant utilisateur attribué par votre fournisseur d'hébergement). Par exemple, si vous avez créé une base de données nommée db01 avec le nom d'utilisateur u01 et que votre identifiant utilisateur est ocom (donné par votre fournisseur d'hébergement), vous devez saisir le nom de base de données et le nom d'utilisateur de la base de données en tant que ocom_db01 et ocom_u01 respectivement.

Echec de connexion à MySQL avec l'erreur [2013] ou [2002]

Si vous obtenez l'erreur : failed with error [2013] Lost connection to MySQL server during query. ou failed with error [2002] Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (13)., cela peut être dû à l'utilisation d'un mauvais nom d'hôte de la base de données ou un problème de droits avec le fichier mysql.soc ou le répertoire.

Si vous utilisez un fournisseur d'hébergement, assurez-vous d'utiliser le bon nom d'hébergeur pour la base de données.

Le manuel MySQL dispose de pages intéressantes traitant des erreurs communes (telles que celles-ci). Aller sur la page pour les liens de documentation d'autres versions MySQL.

Si vous n'êtes même pas sûr que MySQL soit installé, essayez la commande mysql à partir de la ligne de commande; s'il n'est pas installé, voir les Instructions particulières au système.

Binaires de l'utilitaire UNIX non trouvés

Les erreurs comprennent :

• GNU diff3 non trouvé
• Logiciel Git de contrôle des versions non trouvé
• ImageMagick non trouvé

PHP doit pouvoir accéder à /usr/bin. Dans php.ini (probablement /etc/php/php.ini), ajoutez :/usr/bin/ à la variable de configuration open_basedir comme ci-dessous :

open_basedir = /srv/http/:/home/:/tmp/:/usr/share/pear/:/usr/share/webapps/:/var/www/:/usr/bin/

Pour désactiver GIT, initialiser $wgGitBin avec un chemin autorisé mais qui n'existe pas.

$wgGitBin = "";

"Interdit : vous n'avez pas le droit d'accéder à /mediawiki/ sur ce serveur."

C'est généralement un problème avec la configuration de votre logiciel de serveur Web et n'est pas lié à MediaWiki lui-même. Voir par exemple ce fil de discussion de Stackoverflow ou les autres forums des serveurs web.

Trop de redirections (ERR_TOO_MANY_REDIRECTS)

Lorsque cela se produit sur chaque page, c'est généralement dû à une mauvaise configuration de Manuel:URL courte , probablement suite à une erreur de règle de redirection.

Cela peut également se produire lorsque $wgForceHTTPS est initialisé à true, et que MediaWiki ne détecte pas correctement le protocole utilisé par le client et continue à envoyer une redirection vers https: . Cela peut se produire lorsque MediaWiki est configuré derrière un proxy inverse qui n'initialise pas l'entête HTTP X-Forwarded-Proto à https.

Erreurs durant la mise à jour

Champ rc_timestamp non trouvé dans la table recentchanges. Ne doit pas se produire.

Peut se produire par exemple lors de la mise à jour de MW 1.27 vers une autre version. Si la base de données est vide de tout contenu, ce message peut apparaître. Voir phab:T236671.

Cela peut se produire si vous n'avez pas spécifié le même $wgDBprefix que celui de votre installation d'origine, ce qui empêche MediaWiki de retrouver ses tables. Vérifiez les tables existantes dans la base de données et voyez quel préfixe commun elles partagent, puis mettez à jour ce paramètre en conséquence.

Une autre cause peut être que vous avez défini une base de données vide. Réinstallez le contenu de la base de données à partir d'une sauvegarde et procédez à la migration.

"Can not upgrade from versions older than 1.31, please upgrade to that version or later first" (or variants)

Some upgrades cannot be performed without an intermediary upgrade. For instance, to upgrade from a wiki older than 1.33 to MW 1.39.1, you will need to upgrade to 1.35 first. See task phab:T326071.

This error message can also be a red herring. It may appear when you are trying to update an empty database, without tables. Create the database first by installing the wiki.

Parsoid / VisualEditor

Voir Parsoid/Troubleshooting et Résolution des problèmes VisualEditor .

Voir aussi

• Manual:Config script#Installation errors
• Manual:How to debug