Avertissement : cet article sur les erreurs Laravel courantes est en cours de construction.
Nous allons lister dans cet article les différentes erreurs que vous pourriez rencontrer sous Laravel.
Des erreurs Laravel au cours d’un développement, nous y avons tous ou nous y sommes tous confrontés un jour. Si, si je vous assure !
Cet article évolutif va les lister au fur et à mesure de nos développements et de vos contributions.
Pour chacune, nous nous efforcerons de vous donner une explication sur la raison de cette erreur et une solution permettant de résoudre les erreurs Laravel rencontrée.
N’hésitez pas à nous faire dans les commentaires des erreurs Laravel courantes que vous rencontrez ou que vous avez rencontré afin que nous puissions compléter cette page.
Sommaire des erreurs Laravel courantes :
- Failed to clear cache. Make sure you have the appropriate permissions
- SQLSTATE[HY000] [2002] php_network_getaddresses: getaddrinfo failed: Hôte inconnu
Failed to clear cache. Make sure you have the appropriate permissions
Explication :
Cette erreur se produit lorsque vous lancez la commandephp artisan cache:clear
et que le sous-dossier data n’existe pas dans le chemin storage/framework/cache. C’est souvent le cas lors d’une installation vierge de Laravel.
Solution :
Il suffit alors de le créer manuellement via la commandemkdir storage\framework\cache\data
Vous pourrez alors utiliser à nouveau la commande de suppression du cache de Laravel via Artisan.
SQLSTATE[HY000] [2002] php_network_getaddresses: getaddrinfo failed: Hôte inconnu
Explication :
Cette erreur peut survenir notamment lorsque vous changer la base de données d’un site déjà existant.
Par exemple lorsque vous passez d’un site en développement vers un site de production ou vice et versa.
Comme Laravel place en cache les données de configuration, il tente de se connecter à la base de données du site précédent et ne prends pas en compte les nouvelles informations de connexion que vous lui avez fournis dans le fichier .env.
Solution :
Si cela est possible un simple :php artisan config:clear
devrait suffire. Toutefois, il est probable que vous vous retrouviez avec le message d’erreur suivant en console :In PDOConnection.php line 50: SQLSTATE[HY000] [2002] php_network_getaddresses: getaddrinfo failed: Hôte inconnu.
Dans ce cas, il sera nécessaire de vider le cache manuellement.
Pour cela, rendez vous dans l’arborescence de votre projet sous le répertoire :bootstrap/cache
et supprimez le fichier config.php.
Rechargez à présent votre page et vous ne devriez plus avoir cette erreur.
Illuminate\Database\QueryException : SQLSTATE[HY000]: General error: 1215 Cannot add foreign key constraint
Dans la cadre de l’utilisation des migrations, vous souhaitez associer une clé étrangère à votre table dans une relation one-to-many.
Par exemple : un utilisateur a plusieurs produits en ventes. Un produit mis en vente appartient à un utilisateur.
Vous avez défini votre fichier de migration pour votre table products comme ci-dessous :
public function up()
{
Schema::create('products', function (Blueprint $table) {
$table->bigIncrements('id');
$table->text('title');
$table->text('ref');
$table->integer('user_id')->unsigned();
$table->text('url');
$table->foreign('user_id')->references('id')->on('users')->onDelete('cascade');
$table->timestamps();
});
}
Là vous êtes contents de vous. Vous lancez votre migration en toute confiance :
php artisan migrate
two fingers in the nose
Comme dirait votre collègue de bureau !
Et là, votre console vous vomit dessus le message suivant :
Ne vous arrachez pas les cheveux !
Est ce que vous savez pourquoi Laravel vous envoie tant de haine au visage ?
Tout simplement parce que le champ user_id que vous avez défini doit être du même type que l’id de la table users.
Jettons un oeil à la migration de base fournie par Laravel lorsque l’on active l’authentification.
public function up()
{
Schema::create('users', function (Blueprint $table) {
$table->bigIncrements('id');
$table->uuid('uuid');
$table->string('first_name')->nullable();
$table->string('last_name')->nullable();
$table->string('email')->unique();
$table->string('avatar_type')->default('gravatar');
$table->string('avatar_location')->nullable();
$table->string('password')->nullable();
$table->timestamp('password_changed_at')->nullable();
$table->unsignedTinyInteger('active')->default(1);
$table->string('confirmation_code')->nullable();
$table->boolean('confirmed')->default(config('access.users.confirm_email') ? false : true);
$table->string('timezone')->nullable();
$table->timestamp('last_login_at')->nullable();
$table->string('last_login_ip')->nullable();
$table->boolean('to_be_logged_out')->default(false);
$table->rememberToken();
$table->timestamps();
$table->softDeletes();
});
}
Vous avez compris votre erreur ?
Non ?
Allez je vous mets sur la piste :
Et oui, la colonne ‘id’ de la table user n’est pas un simple integer comme au bon vieux temps, mais un bigInteger.
La solution :
Votre colonne user_id doit donc être défini comme étant un bigInteger et là votre migration devrait se passer sans problème.