il y a de nombreuses raisons pour lesquelles on pourrait tomber dans cette erreur et donc une bonne liste de contrôle de ce qu'il faut vérifier d'abord aide considérablement.

considérons que nous sommes en train de résoudre le problème de la ligne suivante:

require "/path/to/file"

Liste de contrôle

1. Vérifier le chemin du fichier pour les fautes de frappe

• soit vérifier manuellement (en contrôlant visuellement le chemin)

• ou de déplacer tout ce qui est appelé par require* ou include* à sa variable, d'écho, de le copier, et essayez d'accéder à partir d'un terminal:

  $path = "/path/to/file";
  
  echo "Path : $path";
  
  require "$path";
  

  puis, dans un terminal:

  cat <file path pasted>
  

2. Vérifiez que le chemin d'accès du fichier est correcte concernant Considérations relatives et absolues sur la trajectoire

• s'il commence par une barre oblique " / " alors il ne se réfère pas à la racine du dossier de votre site web (la racine du document), mais à la racine de votre serveur.
  • par exemple, l'Annuaire de votre site Web pourrait être /users/tony/htdocs
• si il ne commence pas par un slash ( / ), alors il est soit en s'appuyant sur le chemin de l' (voir ci-dessous) ou le chemin est relatif. S'il est relatif, alors PHP calculera relativement au chemin du répertoire de travail courant .
  • ainsi, pas relativement au chemin de la racine de votre site web, ou au fichier où vous tapez
  • pour cette raison, toujours utiliser des chemins de fichier absolus

meilleures pratiques:

afin de rendre votre script robuste en si vous déplacez des choses, tout en générant un chemin absolu à l'exécution, vous avez 2 options:

1. utiliser require __DIR__ . "/relative/path/from/current/file" . La __DIR__ constante magique renvoie le répertoire du fichier courant.

2. définir un SITE_ROOT constante de soi-même :

   • à la racine de l'Annuaire de votre site web, créez un fichier, par exemple config.php

   • dans config.php , d'écrire

     define('SITE_ROOT', __DIR__);
     

   • dans chaque fichier où vous voulez faire référence au dossier racine du site, incluez config.php , puis utilisez la constante SITE_ROOT où que vous aimiez:

     require_once __DIR__."/../config.php";
     ...
     require_once SITE_ROOT."/other/file.php";
     

ces 2 pratiques rendent également votre application plus portable parce qu'elle ne repose pas sur les paramètres ini comme le chemin d'inclusion.

3. Vérifiez votre chemin d'inclusion

une autre façon d'inclure des fichiers, ni relativement ni purement absolue, est de se fier au" chemin d'inclusion 15191250920 . C'est souvent le cas pour les bibliothèques ou les cadres tels que le cadre Zend.

une telle inclusion ressemblera à ceci:

include "Zend/Mail/Protocol/Imap.php"

Dans ce cas, vous voulez assurez-vous que le dossier où "Zend" est, fait partie du chemin.

vous pouvez vérifier le chemin d'inclusion avec:

echo get_include_path();

vous pouvez y ajouter un dossier avec:

set_include_path(get_include_path().":"."/path/to/new/folder");

4. Vérifiez que votre serveur a accès à ce fichier

il se peut que l'utilisateur qui exécute le processus serveur (Apache ou php) n'ait tout simplement pas l'autorisation de lire ou d'écrire dans ce fichier.

pour vérifier sous quel utilisateur le serveur exécute, vous pouvez utiliser posix_getpwuid :

$user = posix_getpwuid(posix_geteuid());

var_dump($user);

pour connaître les permissions sur le fichier, tapez la commande suivante dans le terminal:

ls -l <path/to/file>

et regardez permission notation symbolique

5. Vérifier les paramètres de PHP

si aucune des réponses ci-dessus n'a fonctionné, alors le problème est probablement que certains paramètres de PHP lui interdisent d'accéder à ce fichier.

trois réglages pourraient être pertinents:

1. open_basedir
   • si cela est défini, PHP ne pourra pas accéder à un fichier en dehors du répertoire spécifié (pas même par un lien symbolique).
   • cependant, le comportement par défaut est qu'il ne doit pas être défini, auquel cas il n'y a pas de restriction
   • vous pouvez vérifier cela en appelant phpinfo() ou en utilisant ini_get("open_basedir")
   • vous pouvez modifier le paramètre soit en éditant votre php.fichier ini ou votre httpd.fichier conf
2. mode sans échec
   • s'il s'agit tourné sur des restrictions peuvent s'appliquer. Cependant, ceci a été supprimé dans PHP 5.4. Si vous êtes toujours sur une version qui supporte la mise à niveau en mode de sécurité vers une version PHP qui est toujours supportée .
3. allow_url_fopen et allow_url_include
   • ceci s'applique uniquement à l'inclusion ou à l'ouverture de fichiers par le biais d'un processus réseau tel que http:// système de fichiers local
   • cette valeur peut être vérifiée avec ini_get("allow_url_include") et définie avec ini_set("allow_url_include", "1")

Coin des affaires

si aucune des réponses ci-dessus n'a permis de diagnostiquer le problème, voici quelques situations spéciales qui pourraient se produire:

1. L'Inclusion de bibliothèque s'appuyant sur le chemin d'inclusion

il peut arriver que vous incluiez une bibliothèque, par exemple le cadre Zend, en utilisant un chemin relatif ou absolu. Par exemple:

require "/usr/share/php/libzend-framework-php/Zend/Mail/Protocol/Imap.php"

mais vous obtenez toujours le même type d'erreur.

cela pourrait se produire parce que le fichier que vous avez (avec succès) inclus, a lui-même une instruction include pour un autre fichier, et cette deuxième instruction include suppose que vous avez ajouté le chemin de la bibliothèque de l'include path.

par exemple, le fichier cadre de Zend mentionné ci-dessus pourrait contenir les éléments suivants :

include "Zend/Mail/Protocol/Exception.php" 

qui n'est ni une inclusion par un chemin relatif, ni par un chemin absolu. Il suppose que le répertoire du framework Zend a été ajouté au chemin include.

Dans un tel cas, la seule solution est d'ajouter le répertoire de votre chemin.

2. SELinux

si vous utilisez Linux amélioré par la sécurité, alors cela pourrait être la raison du problème, en refusant l'accès au fichier depuis le serveur.

pour vérifier si SELinux est activé sur votre système, lancez la commande sestatus dans un terminal. Si la commande n'existe pas, alors SELinux n'est pas sur votre système. Si elle n'existe pas, alors il devrait vous dire si elle est appliquée ou non.

pour vérifier si les politiques SELinux sont la raison pour le problème, vous pouvez essayer de l'éteindre Temporairement. Toutefois, soyez prudent, car cela désactivera entièrement la protection. Ne faites pas cela sur votre serveur de production.

setenforce 0

si vous n'avez plus le problème avec SELinux éteint, alors c'est la cause profonde.

à résolvez le , vous devrez configurer SELinux en conséquence.

les types de contexte suivants seront nécessaires:

• httpd_sys_content_t pour les fichiers que vous voulez que votre serveur puisse lire
• httpd_sys_rw_content_t pour les fichiers sur lesquels vous souhaitez accès en lecture et écriture
• httpd_log_t pour les fichiers journaux
• httpd_cache_t pour le répertoire de cache

par exemple, pour assigner le type de contexte httpd_sys_content_t à votre répertoire racine de site web, exécutez:

semanage fcontext -a -t httpd_sys_content_t "/path/to/root(/.*)?"
restorecon -Rv /path/to/root

si votre fichier est dans un répertoire personnel, vous devrez aussi activer le booléen httpd_enable_homedirs :

setsebool -P httpd_enable_homedirs 1

dans tous les cas, il pourrait y avoir une variété de raisons pour lesquelles SELinux refuserait l'accès à un fichier, selon vos politiques. De sorte que vous aurez besoin de se renseigner. ici est un tutoriel spécifique sur la configuration de SELinux pour un serveur web.

3. Symfony

si vous utilisez Symfony, et rencontrez cette erreur lors du téléchargement vers un serveur, alors il se peut que le cache de l'application n'ait pas été réinitialisé, soit parce que app/cache a été téléchargé, ou que le cache n'a pas été effacé.

vous pouvez le tester et le corriger en exécutant ce qui suit: commande de la console:

cache:clear

4. Non ACSII charactersinside Zip file

apparemment, cette erreur peut aussi se produire lors de l'appel zip->close() lorsque certains fichiers à l'intérieur du zip ont des caractères non ASCII dans leur nom de fichier, comme "é".

une solution possible consiste à envelopper le nom du fichier dans utf8_decode() avant de créer le fichier cible.

Crédits Fran Cano pour déterminer et de proposer une solution à ce problème