IncludeBeer

La "checklist" des choses à vérifier quand votre application web CodeIgniter 4 ne fonctionne pas

Publié le 31 mai 2020 Dernière mise à jour le 7 juin 2020
Image de l'article
Origine de l'image: Ilya Pavlov

Vérifier la présence d'erreurs dans les logs d'Apache

La première chose à vérifier quand un site web ne fonctionne pas, c'est les logs du serveur web. Un des serveurs les plus populaire est Apache. Il existe d'autres serveurs populaires tel que Ngynx et IIS, mais je vais me concentrer sur Apache. Vérifiez s'il y a des erreurs dans le fichier error.log. S'il y a des problèmes de permissions de fichiers, de fichiers introuvables ou des erreurs de syntaxe dans le code PHP, ou que vous avez l'infâme page blanche dans votre navigateur web, il y a de fortes chances que des messages d'erreurs soient inscrit dans le fichier error.log.

Selon votre installation, les logs d'erreurs peuvent être à différents endroits ou avoir un nom différent de error.log. Les emplacements communs à vérifier sont :

/var/log/apache/error.log
/var/log/apache2/error.log
/var/log/httpd/error.log

Sur macOS, si vous utilisez MAMP, le log se trouve à cet endroit :

/Applications/MAMP/logs/apache_error.log

Si vous hébergez votre site chez DreamHost, le log d'erreurs se trouve dans le répertoire home de l'usager sous lequel s'exécute votre site web :

/home/nom-usager/logs/nom-domaine.com/http/error.log
/home/nom-usager/logs/nom-domaine.com/https/error.log

Si vous ne trouvez pas l'emplacement du log d'erreurs, créez une page test et appelez la fonction phpinfo(). Chercher le mot error_log dans cette page. Ça vous indiquera le répertoire et le nom du fichier.

<?php
phpinfo();
?>

Vérifier la présence d'erreurs dans les logs de CodeIgniter 4

Dans une application CodeIgniter 4, les logs se trouvent sous le répertoire writable/logs. Ils peuvent être consultés avec un logiciel FTP qui va l'ouvrir dans un éditeur texte. Mais la façon que je préfère est en ligne de commande en se connectant au serveur avec un terminal SSH. On peut alors utiliser les commande cat, grep et tail pour visionner le contenu.

$ cd mon-site-web/writable/logs
$ cat log-2020-05-01.log
INFO - 2020-05-01 10:13:57 --> Session: Class initialized using 'CodeIgniter\Session\Handlers\FileHandler' driver.
INFO - 2020-05-01 10:13:57 --> Session: Class initialized using 'CodeIgniter\Session\Handlers\FileHandler' driver.
INFO - 2020-05-01 10:13:58 --> Session: Class initialized using 'CodeIgniter\Session\Handlers\FileHandler' driver.
DEBUG - 2020-05-01 10:52:31 --> Test
INFO - 2020-05-01 10:52:31 --> Controller "App\Controllers\BlogController" loaded.
DEBUG - 2020-05-01 10:52:31 --> Appel d'une fonction qui n'existe pas
CRITICAL - 2020-05-01 10:52:31 --> Call to undefined method App\Controllers\BlogController::fonction_qui_nexiste_pas()
#0 /Applications/MAMP/htdocs/mon-site-web/system/CodeIgniter.php(910): App\Controllers\BlogController->index()
#1 /Applications/MAMP/htdocs/mon-site-web/system/CodeIgniter.php(398): CodeIgniter\CodeIgniter->runController(Object(App\Controllers\BlogController))
#2 /Applications/MAMP/htdocs/mon-site-web/system/CodeIgniter.php(306): CodeIgniter\CodeIgniter->handleRequest(NULL, Object(Config\Cache), false)
#3 /Applications/MAMP/htdocs/mon-site-web-public/index.php(45): CodeIgniter\CodeIgniter->run()
#4 {main}

Si l'application s'exécute en mode debug le fichier peut être très volumineux. Pour extraire seulement les erreurs, on peux utiliser grep -v. Dans CodeIgniter 3 les erreurs étaient toutes préfixées du mot ERROR. Mais dans CodeIgniter 4 il y a maintenant plusieurs types d'erreur. Il est donc plus simple de seulement éliminer les entrées INFO et DEBUG. Ça nous permet aussi de voir la pile (stack trace). L'option -v fait une recherche inverse et retourne toute les lignes, à l'exception des lignes contenant les mots DEBUG et INFO :

$ grep -v 'DEBUG\|INFO' log-2020-05-01.php
CRITICAL - 2020-05-01 10:52:31 --> Call to undefined method App\Controllers\BlogController::fonction_qui_nexiste_pas()
#0 /Applications/MAMP/htdocs/mon-site-web/system/CodeIgniter.php(910): App\Controllers\BlogController->index()
#1 /Applications/MAMP/htdocs/mon-site-web/system/CodeIgniter.php(398): CodeIgniter\CodeIgniter->runController(Object(App\Controllers\BlogController))
#2 /Applications/MAMP/htdocs/mon-site-web/system/CodeIgniter.php(306): CodeIgniter\CodeIgniter->handleRequest(NULL, Object(Config\Cache), false)
#3 /Applications/MAMP/htdocs/mon-site-web-public/index.php(45): CodeIgniter\CodeIgniter->run()
#4 {main}

On peux aussi visualiser les erreurs en temps réel avec la commande tail -f. Ceci permet d'affiche le contenu du fichier à mesure que des nouvelles lignes sont écrite dedans. On peux donc rafraîchir la page web dans le navigateur et voir apparaître les erreurs dans le terminal à mesure qu'elles se produisent :

$ tail -f log-2020-05-01.php

Si on ne veut pas être inondé de divers messages d'information, on peux alors combiner les deux commandes ensemble pour afficher uniquement les erreurs :

$ tail -f log-2020-05-01.php | grep -v 'DEBUG\|INFO'

Ajuster le niveau de logging de CodeIgniter 4

On peux ajuster le type d'informations qui est inscrit au log en modifiant le paramètre threshold dans le fichier app/Config/Logger.php ou logger.threshold dans .env. Les valeurs possibles sont de 0 à 9. Le système inscrit tous les message de niveau égal ou inférieur au seuil spécifié. Par exemple, dans un environnement de développement on peux mettre 9 pour que tous les types de message soient inscrit au log. En production on pourrait mettre 4 pour logger seulement les erreurs, soit tous les message de 1 à 4 :

Code Niveau Description
0 Désactive le logging - Aucune erreur ne sera inscrite au fichier de log.
1 emergency Messages urgents - Le système est inutilisable.
2 alert Messages d'alerte - Une action doit être prise immédiatement.
3 critical Messages critiques - Composante de l'application non disponible, exception inattendue.
4 error Erreur lors de l'exécution - Ne nécessite pas d'action immédiate, mais doit être surveillé.
5 warning Avertissements - Occurrences exceptionnelles qui ne sont pas des erreurs.
6 notice Notices - Événements normaux mais significatifs.
7 info Info - Événements intéressants, comme la connexion des utilisateurs, etc..
8 debug Debug - Informations de débogage détaillées.
9 Tous les messages

Vérifier les permissions des fichiers

Si les fichiers et les répertoires de l'application web n'ont pas les bonnes permissions, ça peut causer des problèmes. Particulièrement pour le répertoire writable. Il doit être accessible en écriture par le serveur web (Apache ou autre). Sinon, CodeIgniter ne sera pas capable d'écrire ses fichiers de log, de sessions et de cache. C'est un problème qui semble survenir assez fréquemment lors d'une nouvelle installation de CI4. Malheureusement, beaucoup de gens propose comme solution facile de mettre les permissions à 777. Mais ce n'est vraiment pas une bonne pratique à suivre. Je suggère de définir les permissions en lecture et en écriture pour le propriétaire des fichiers, et en lecture seulement pour les autres utilisateurs. C'est à dire 644 pour les fichiers et 755 pour les répertoires. Évidemment, tout dépend de la configuration de votre serveur web. Veuillez faire les ajustements qui vous semble le plus sécuritaire.

Sans aller trop dans les détails, les permissions sont définit ainsi : 4 = lecture, 2 = écriture, 1 = exécution. Donc l'accès en lecture et en écriture (4 + 2) est définit comme 6. On utilise trois chiffres pour définir les permissions du propriétaire du fichier, des membres du groupe puis le reste du monde. Donc le propriétaire a les droits d'accès en lecture et en écriture (6), les membres du groupe on accès en lecture seulement (4), et le reste du monde aussi (4) = 644. Pour les répertoires, ils ont la particularité qu'il faut la permission d'exécution pour pouvoir aller dans le répertoire et accéder à son contenu.

Pour modifier toute la hiérarchie de fichiers et répertoires avec ces permissions, utilisez la commande chmod pour changer les permissions et la commande find -type f pour trouver les fichiers et find -type d pour trouver les répertoires à modifier :

$ find /Applications/MAMP/htdocs/mon-site-web/ -type f -exec chmod 644 {} \+
$ find /Applications/MAMP/htdocs/mon-site-web/ -type d -exec chmod 755 {} \+

Pour plus d'informations, lisez les réponses à ces deux questions :

Vérifier le fichier .htaccess

Assurez-vous que le fichier .htaccess est bien présent dans le répertoire public de votre application CI4.

Vérifiez que le contenu du fichier correspond bien au fichier .htaccess de CodeIgniter 4 : https://github.com/codeigniter4/CodeIgniter4/blob/develop/public/.htaccess

Vérifier le nom du répertoire de l'application dans le fichier index.php

Vérifiez ce bloc de code dans le fichier public/index.php. Assurez-vous que le nom et l'emplacement du répertoire app est bon. Si vous avez gardé la structure originale, il est déjà bon. Mais si vous avez installé l'application à un endroit différent, changez cette ligne.

<?php
// Location of the Paths config file.
// This is the line that might need to be changed, depending on your folder structure.
$pathsPath = realpath(FCPATH . '../app/Config/Paths.php');
// ^^^ Change this if you move your application folder

Vérifier le fichier .env et les fichiers dans app/Config

Dans CodeIgniter 4, la configuration peut être faite dans le fichier .env ou dans les fichiers du répertoire app/Config. Assurez-vous que les paramètres de connexion à la base de données sont bons, ainsi que les autres paramètres de configuration. En particulier la variable CI_ENVIRONMENT. Cette variable peut-être définie dans le fichier .env ou .htaccess. Pour voir les messages d'erreurs en détail et avoir accès à la Toolbar, mettez la valeur development. Cette valeur devrait être utilisée uniquement dans des environnements de développement et de test. En production, mettez toujours production. Sinon vous exposez des informations sensibles et ça pourrait être un problème de sécurité.

# Fichier .env
CI_ENVIRONMENT = development
# Fichier .htaccess
SetEnv CI_ENVIRONMENT development

Attention de bien nommer le fichier .env avec un point au début du nom. Le fichier fournis par CI4 est seulement un fichier exemple et est nommé env sans le point. L'utilisation de ce fichier est facultative. Si vous décidez de l'utiliser, il faut en faire une copie nommée .env. Sinon, on peut simplement ignorer ce fichier et modifier directement les fichiers du répertoire app/Config.

$ cp env .env

Comment régler l'erreur "No input file specified"

L'erreur "No input file specified" peut survenir si le serveur Apache est configuré en CGI ou FastCGI. Je ne suis pas expert Apache et je ne pourrais pas expliquer pourquoi. Mais j'ai eu ce problème chez mon hébergeur alors que sur mon serveur local ça fonctionnait sans problèmes. La solution que j'ai trouvé est d'ajouter un ? pour que index.php devienne index.php? dans le fichier public/.htaccess :

  RewriteRule ^(.*)$ index.php?/$1 [L]

Voir les réponses à cette question sur Stackoverflow : https://stackoverflow.com/questions/14555996/no-input-file-specified