J'utilise Codeigniter, et au lieu de messages d'erreur, je reçois simplement une page vierge. Est-il possible d'afficher des messages d'erreur PHP à la place? Il est très difficile de déboguer quand je n'ai aucun retour.
Mon environnement est Ubuntu avec Apache.
Étant donné qu'aucune des solutions ne semble fonctionner pour vous jusqu'à présent, essayez celle-ci:
ini_set('display_errors', 1);
http://www.php.net/manual/en/errorfunc.configuration.php#ini.display-errors
Ceci indique explicitement à PHP de afficher les erreurs. Certains environnements peuvent avoir cette option désactivée par défaut.
Voici à quoi ressemblent les paramètres de mon environnement dans index.php
:
/*
*---------------------------------------------------------------
* APPLICATION ENVIRONMENT
*---------------------------------------------------------------
*/
define('ENVIRONMENT', 'development');
/*
*---------------------------------------------------------------
* ERROR REPORTING
*---------------------------------------------------------------
*/
if (defined('ENVIRONMENT'))
{
switch (ENVIRONMENT)
{
case 'development':
// Report all errors
error_reporting(E_ALL);
// Display errors in output
ini_set('display_errors', 1);
break;
case 'testing':
case 'production':
// Report all errors except E_NOTICE
// This is the default value set in php.ini
error_reporting(E_ALL ^ E_NOTICE);
// Don't display errors (they can still be logged)
ini_set('display_errors', 0);
break;
default:
exit('The application environment is not set correctly.');
}
}
Assurez-vous que php5-mysql
est installé.
J'ai eu le même problème et, comme Shayan Husaini l'a fait remarquer, j'ai eu une erreur de syntaxe non détectée.
Je l'ai résolu en utilisant le php linter dans le terminal:
php -l file.php
Vous pouvez également utiliser quelque chose comme ceci pour utiliser le linter dans chaque fichier d'un dossier:
find -type f -name "*.php" -exec php -l '{}' \;
Et pour filtrer uniquement ceux avec des erreurs:
find -type f -name "*.php" -exec php -l '{}' \; | grep '^[^N]'
Cela devrait montrer les fichiers avec des erreurs d'analyse et la ligne où l'erreur est.
Ce problème se produit lorsque vous rencontrez une erreur de syntaxe php de base dans votre code. Dans le cas où vous avez des erreurs de syntaxe, l'analyseur php n'analyse pas complètement le code et n'affiche rien, donc toutes les suggestions ci-dessus ne fonctionneraient que si vous avez d'autres erreurs de syntaxe.
vous pouvez le définir dans l'index principal.php
define('ENVIRONMENT', 'development');
/*
*---------------------------------------------------------------
* ERROR REPORTING
*---------------------------------------------------------------
*
* Different environments will require different levels of error reporting.
* By default development will show errors but testing and live will hide them.
*/
if (defined('ENVIRONMENT'))
{
switch (ENVIRONMENT)
{
case 'development':
error_reporting(E_ALL);
break;
case 'testing':
case 'production':
error_reporting(0);
break;
default:
exit('The application environment is not set correctly.');
}
}
Cela m’arrive à chaque fois que je fais un autoload dans autoload.php comme la 'base de données'
Pour résoudre ce problème, si vous utilisez Windows
Ouvrez votre php.ini. Rechercher et décommenter cette ligne - extension=php_mysql.dll
(Veuillez également vérifier si la directive PHP pointe vers l'emplacement de vos extensions.
Le mien est extension_dir = "C:\php-5.4.8-Win32-VC9-x86\ext"
)
Redémarrez Apache et actualisez votre page
J'ai eu le même problème il y a quelques jours. Mon environnement de développement est Win8 et le site Web fonctionnait très bien, mais lorsque j'ai téléchargé les fichiers sur le serveur de production (Linux), une page vierge était affichée.
Il s'avère que les noms de fichiers des modèles et des contrôleurs doivent commencer par une lettre majuscule .
Le fichier doit s’appeler "Blog.php", avec une "B" majuscule.
Les noms de classe doivent commencer par une lettre majuscule.
Dans l'environnement Windows, cela n'aura pas d'importance, car windows ne différencie pas les majuscules et les minuscules , mais dans l'environnement Linux, les fichiers ne seront pas affichés.
J'espère que j'ai aidé.
Assurez-vous de ne pas avoir de fichier index.html vide dans votre dossier racine. Ça arrive :)
Essayez d'ajouter ceci à votre fichier index.php
error_reporting(E_ALL);
Si vous utilisez CI 2.0 ou une version plus récente, vous pouvez modifier le type ENVIRONMENT
dans votre index.php
en define('ENVIRONMENT', 'testing');
.
Vous pouvez également ajouter php_flag display_errors on
à votre fichier .htaccess
.
Tout d’abord, vous devez donner l’autorisation de votre dossier Codeigniter, c’est peut-être le problème de l’autorisation, puis démarrer votre serveur.
vérifiez si error_reporting est activé sur le serveur ou non, si cet identifiant est désactivé, vous n'obtiendrez aucune erreur et n'afficherez qu'une page vierge Si vous êtes sur un serveur partagé, vous pouvez activer le rapport d’erreurs via htaccess. Dans codeIgniter ajouter ce qui suit dans votre htaccess
php_flag display_errors On
et mettre
error_reporting(E_ERROR); ## or what ever setting desired in php
espérons que cela fonctionnera pour vous
après l’installation de xamp/wamp, vous remarquerez peut-être quelques erreurs de même nature. Si votre site Web fonctionnait déjà, ne vous inquiétez pas, il s'agit d'un problème lié à la configuration.
1) vérifier les connexions de base de données dans le fichier database.php du dossier de l'application 2) vérifier l'URL de vérification du fichier config.php est correcte ou non? 3) Par défaut, les balises courtes sont désactivées dans les nouvelles installations puis suivez la procédure ci-dessous
dans le fichier php.ini, changez "short_open_tag = Off" en "short_open_tag = On"
Assurez-vous de redémarrer Apache après cela.
j'espère que cela t'aides.
j'étais également confronté au même problème et ai essayé presque toutes les choses mais finalement j'ai redémarré mon serveur et j'ai trouvé que tout a commencé à bien fonctionner .. je ne sais pas comment ..... je pense que c'était un problème côté serveur c'est pourquoi mon PHP CODE ne donnait aucune erreur.
Si vous avez ceci dans votre php.ini:
display_error = On;
et vous l'avez en même temps dans votre application CI
error_reporting(0);
vous obtiendrez HTTP/1.1 200 OK et une page entièrement bancaire.
En effet, lorsque display_error est activé, php-fpm renvoie toujours le code HTTP 200 ..__ et toutes les erreurs de sortie sont interdites par error_reporting (0).
Pour l'application CI, l'entrée index.php définit l'environnement d'exécution comme suit:
if(isset($_SERVER['SERVER_ENV'])) {
define('ENVIRONMENT', $_SERVER['SERVER_ENV']);
} else {
define('ENVIRONMENT', 'development');
}
if (defined('ENVIRONMENT'))
{
switch (ENVIRONMENT)
{
case 'development':
error_reporting(E_ALL);
ini_set('display_errors', 1);
break;
case 'testing':
case 'production':
error_reporting(0);
break;
default:
exit('The application environment is not set correctly.');
}
}
En bref, lorsque vous définissez la directive ENV dans la conf de votre serveur Web, dites fastcgi_params de Nginx:
fastcgi_param SERVER_ENV production;
alors CI sera automatiquement défini
error_reporting(0);
Utilisez-vous le symbole @ n'importe où?
Si vous avez quelque chose comme:
@include('page_with_error.php');
Vous obtiendrez une page blanche.
chargez votre assistant url lorsque vous créez une fonctioneg,
visibility function_name () {
$this->load->helper('url');
}
cela vous montrera des erreurs ou une vue que vous avez chargée.
Une autre méthode consiste à vérifier si vous avez dépassé le contrôle d'erreur par erreur dans votre code. Recherchez dans tout votre code toute instance de error_reporting (). Si vous l'appelez sans paramètres, il ne fait que renvoyer le niveau actuel et est sans danger. Si vous l'appelez avec un paramètre, tel que 0 (zéro), le rapport d'erreur sera désactivé.
Vous pouvez tester cela dans CodeIgnitor en consultant leur bibliothèque principale sous ../system/core/Common.php et en recherchant une section se trouvant à peu près à la ligne 615 qui ressemble à ceci:
if (($severity & error_reporting()) !== $severity)
{
return;
}
Ajouter quelque chose comme:
if (($severity & error_reporting()) !== $severity)
{
echo "Suppressing errors!";
return;
}
et vous devriez être capable de piéger les erreurs dépassées et de déboguer à partir de là.
J'avais le même problème, j'ai installé la dernière version de xamp et découvert que mon site ne fonctionnait pas. Après des recherches et une perte de temps, j'ai trouvé que.
J'ai besoin d'activer la balise suivante dans le fichier php.ini short_open_tag = On
Assurez-vous de redémarrer Apache après cela.
J'espère que cela vous aidera, la plupart de ces problèmes sont liés au fichier php.ini ou à une nouvelle installation si votre site était déjà en cours d'exécution en tant que personnes confrontées au même problème.
L'erreur, dans mon cas, se produisait parce que mon serveur Apache était configuré pour exécuter PHP
comme Fast CGI
, je l'ai changé en FPM
et cela a fonctionné.
Souvent, lorsque codeigniter n’affiche rien, il se produit une erreur de syntaxe. Surtout si l'application fonctionnait de manière transparente précédemment, il suffit de regarder vos dernières modifications. Pour moi, cette fois, l'expérience a été toute l'application, pas seulement une page. J'ai donc fait une brève analyse cérébrale des modifications les plus récentes que j'ai effectuées et travaillé à l'envers, en examinant chaque fichier sur lequel j'avais travaillé ce jour-là. Il s’est avéré qu’il s’agissait de clauses «où» dans deux fichiers de modèle: par exemple, j’avais
$this->db->where('Type' => 'Blog'); rather than $this->db->where('Type', 'Blog');
Codeigniter ne semble pas émettre de message d'erreur lorsque je faisais référence à une vue qui n'existait pas.
Dans mon exemple, j'avais dans mon contrôleur:
$this->load->view('/admin/index/access_controls/groups/add');
Comme le fichier n’existait pas, j’ai reçu un blanc "Une page d’erreur est survenue". J'ai changé le code en:
$this->load->view('/admin/access_controls/groups/add');
C'est ainsi que j'ai résolu le même problème que vous semblez avoir, espérons que cela aidera quelqu'un un jour.
Je me suis heurté à cela parce que j'avais une CLI exécutée via cron en tant qu'utilisateur root, créant ainsi des fichiers journaux avec root: root. Lorsque vous essayez de naviguer vers un URI, tout fonctionne correctement, mais la présentation d'une page vierge par un CI risque de ne pas être autorisée, car elle ne dispose pas de l'autorisation d'écriture dans le fichier journal.