Symfony 4 : les fondamentaux par la pratique
4.7 (471 ratings)
Course Ratings are calculated from individual students’ ratings and a variety of other signals, like age of rating and reliability, to ensure that they reflect course quality fairly and accurately.
851 students enrolled

Symfony 4 : les fondamentaux par la pratique

Créer un site d'annonce avec interface d'administration pour apprendre tous les fondamentaux du Framework PHP Symfony 4
Bestseller
4.7 (471 ratings)
Course Ratings are calculated from individual students’ ratings and a variety of other signals, like age of rating and reliability, to ensure that they reflect course quality fairly and accurately.
851 students enrolled
Created by Lior Chamla
Last updated 3/2020
French
Price: $199.99
30-Day Money-Back Guarantee
This course includes
  • 21 hours on-demand video
  • 10 articles
  • Full lifetime access
  • Access on mobile and TV
  • Certificate of Completion
Training 5 or more people?

Get your team access to 4,000+ top Udemy courses anytime, anywhere.

Try Udemy for Business
What you'll learn
  • Développer une application Symfony complexe
  • Maîtriser le concept de Controllers et de Routes paramétrées ou pas
  • Maîtriser le langage de templating Twig et ses subtilités
  • Utiliser le composant Form pour créer des formulaires riches et des sous-formulaires
  • Utiliser des DataTransformers pour formater des données vers et depuis un formulaire
  • Mettre en place des validations de formulaire
  • Comprendre Doctrine et la liaison avec la base de données
  • Construire une base de données pas à pas grâce aux entités et au système de migrations
  • Créer des requêtes complexes grâce au DQL (Doctrine Query Language)
  • Créer des jeux de fausses données grâce aux Fixtures
  • Utiliser le composant Security pour sécuriser les pages, gérer les rôles et l'authentification des utilisateurs
  • Personnaliser les pages d'erreurs les plus communes
  • Comprendre la notion et l'utilité des Services
  • Construire un système de pagination de A à Z
  • Déployer une application Symfony sur différents types de serveurs (mutualisé ou container)
Course content
Expand all 226 lectures 21:12:39
+ Introduction
6 lectures 14:43

On apprend ici à quoi sert un Framework PHP et pourquoi utiliser Symfony ?

Preview 03:52

Découvrez la structure de cette formation et le projet que l'on va construire ensemble durant ces plus de 20 heures de vidéos.

Preview 04:56

Je vous présente les outils nécessaires pour suivre cette formation : PHP 7.1 minimum, Composer, WAMP ou Laragon, MySQL et bien sur VSCode

Preview 01:50

Je vous explique ici l'ensemble des outils nécessaires pour travailler !

Preview 01:14

Je vous explique ici tout ce qu'il faut mettre en place pour utiliser VSCode dans cette formation !

Preview 00:47

Sachez tirer profit au mieux de ces 20 heures de vidéo et faites en quelque chose !

Preview 02:04
+ Premiers pas : mise en place de notre application Symfony 4
17 lectures 01:32:22

Un projet Symfony, c'est beaucoup de code et beaucoup de fichiers (notamment des fichiers de configuration). En plus, c'est une structure de dossiers complexe et énormément de dépendances à télécharger.

Le créer à la main relèverait du calvaire, c'est pour cela qu'on peut utiliser Composer pour le faire à notre place grâce à sa commande create-project.

On peut le charger de créer toute la structure de dossier en s'inspirant d'un squelette qu'on trouve sur le github de Symfony : la recette symfony/website-skeleton permet d'obtenir tous les outils nécessaires à la création d'un véritable site Internet !

Preview 04:41

Une application Symfony, c'est beaucoup de dossiers qui peuvent paraître abstraits au départ, mais une fois les présentations faites, on se rend compte que tous ne sont pas forcément primordiaux et surtout que la structure est finalement très logique.

Découverte de la structure d'une application Symfony 4
06:16

Je vous fais ici un bref rappel de la notion de MVC et je vous explique la place centrale et le fonctionnement d'un Controller dans une application Symfony !

Preview 03:24

Le fonctionnement de Symfony repose essentiellement sur le pattern MVC : Models, Views et Controllers. 

Il est donc logique de penser que si l'on veut afficher une page, traiter un formulaire, créer une redirection, bref, créer un comportement, il faudra un Controller.

Créons donc un premier Controller ensemble afin de voir de quoi il s'agit, et comment on peut appeler une tâche particulière (comme le fait d'afficher une page HTML) à partir d'une adresse de notre site.

Créons notre premier Controller : le HomeController
06:49

Ce n'est jamais une bonne pratique que de mélanger les concepts et les préoccupations. D'une part on possède des traitements, et c'est la mission du Controller que de les gérer, d'autres parts on a des affichages, qui eux sont des Views et doivent donc être séparées.

Quitte à séparer le code d'affichage et celui des traitements, pourquoi en plus ne pas avoir une technologie d'affichage qui nous facilite la vie : c'est le but du langage de templating Twig !

Preview 04:15

Pourquoi utiliser le langage Twig alors que PHP sait très bien faire, lui aussi, office de langage de template ? Je vous explique ici les principaux avantages de Twig

Preview 01:19

L'interpolation n'est pas un concept unique de Twig, mais de beaucoup de langages de programmation / templating : c'est la possibilité d'afficher à un endroit donnée la valeur d'une variable ou la valeur retournée par une fonction.

Dans le langage Twig, si l'on cherche à afficher une valeur, il suffit d'utiliser la syntaxe des double accolades : {‌{ maValeur }}

Preview 02:50

Le langage Twig possède ce qu'il appelle des tags. Ce sont des comportements qu'il adopte en fonction de nos besoin. La syntaxe des tags est celle des accolades et pourcentages : {% monTag ... %}.

Parmi ces tags, on trouve des tags qui permettent de contrôler le flux d'exécution du code tels que les conditions ou les boucles for.

Comprendre Twig : les structures de contrôle (conditions et boucles)
11:06

Comme dans tout langage, un point très important reste la possibilité d'écrire des commentaires, du texte qui ne sera pas lu et évalué par le moteur Twig. La syntaxe des commentaires est celle des accolades et du hash : {# mon commentaire non évalué #}

Comprendre Twig : les commentaires
01:25

La notion de filtres (ou de pipes) existe dans divers Framework et a un but très simple : formater la façon dont une valeur va être affichée sans pour autant modifier la valeur elle même.

Avec Twig, lorsque l'on veut faire passer une valeur au sein d'un filtre avant de l'afficher, il suffit de faire suivre la valeur par le symbole pipe (|) puis de nommer le filtre que l'on souhaite utiliser : {‌{ maValeur | monFiltre }}

Comprendre Twig : les filtres
02:19

Lorsque l'on appelle une page web, l'adresse que l'on utilise peut être porteuse d'informations. Par exemple :

  • monsite.com/articles/il-fait-beau

  • monsite.com/articles/bientot-la-presidentielle

ne donneront pas la même page. La partie de l'URL qui change entre les deux s'appelle un paramètre. Il est possible avec le système de Routes de Symfony de créer des routes qui pourront contenir un ou plusieurs paramètres. Donc une ou plusieurs parties qui pourront différer d'une page à l'autre !

Preview 08:15

Lorsque l'on souhaite afficher une URL au sein d'une template Twig, une bonne pratique est de demander à la fonction path() de générer cette URL pour nous grâce au nom de la Route qui nous intéresse.

Ainsi, si on veut changer l'URL de la Route, on n'a plus à intervenir dans Twig, car notre template Twig lui se servira du nom de la route.

Comprendre Twig : générer une URL avec la fonction path()
05:55

L'héritage de gabarit est une fonctionnalité très puissante de Twig. Elle permet d'hériter de tout le code déjà disponible au sein d'un autre gabarit, en ne modifiant que les blocks (les parties spécifiques) du gabarit dont on hérite !

Comprendre Twig : l'héritage de gabarit (extends)
09:21

Lorsque l'on souhaite aller vite dans la création ou le prototypage d'une application, on peut utiliser un Framework CSS. Le plus connu jusqu'à aujourd'hui reste Bootstrap. On va donc le mettre en place, mais on ne souhaite pas avoir le même que tout le monde, on utilisera donc les thèmes de Bootswatch.com : des bootstraps personnalisés !

Mise en place d'un thème Bootstrap
07:08
Mise en place de la barre de navigation
03:48
Mise en place finale de la page d'accueil de notre application
12:43
Versionning de notre avancement avec GIT
00:48

Vérifiez que vous avez compris comment démarrer un projet Symfony en répondant à ces quelques questions :-)

Démarrage avec Symfony 4
7 questions
+ Relations avec la base de données
11 lectures 57:06

Avant de se lancer dans la découverte en détails des Entités, du Manager, des Repositories, des Migrations et des Fixtures, je vous fais un petit topo du fonctionnement de tout ça !

Preview 05:34

Avec Symfony 4, toute interaction avec la base de données se fait depuis les fichiers, ce sont les fichiers qui priment. Il en va de même pour la création de la base de données !

La CLI de Symfony nous offre une commande assez efficace : php bin/console doctrine:database:create

Celle ci va prendre connaissance des variables d'environnement pour créer la base de données.

Création de la base de données grâce à la CLI
02:15

Grâce à Doctrine, on représente chaque table de notre base de données par une Classe PHP qu'on appelle une Entité. L'entité sert à la fois de schéma, de modèle pour la table, mais aussi de représentation d'un enregistrement de cette table.

Avec la CLI, on peut créer automatiquement ou presque une Entité en tapant : php bin/console make:entity [nomEntite]

Comprendre Doctrine : créons notre première Entité pour représenter les annonces
05:52

Créer une entité ne suffit pas pour véritablement créer une table dans la base de données. Ce sont les scripts de migration qui ont pour but de faire passer la base de données d'un état A à un état B.

La commande php bin/console make:migration permet à Doctrine de prendre en compte nos entités, de voir les différences qui existent avec la base de données afin de créer les requêtes qui permettront à la base de données de refléter le plus fidèlement nos Entités.

Une fois que nos scripts de migration sont prêts, il nous reste à les exécuter avec la commande php bin/console doctrine:migrations:migrate pour que les changements soient bel et bien apportés !

Comprendre Doctrine : notre premier script de migrations
04:57

Il peut être très intéressant de travailler sur des jeux de fausses données qui représentent les futures données présentes dans l'application. C'est le but des Fixtures. Ce sont des scripts de création de fausses données qui peuvent être appelés en une ligne de commande afin d'établir des centaines d'enregistrements factices dans la base de données.

La librairie sur laquelle reposent les fixtures n'est pas installée par défaut, on peut l'installer grâce à composer en tapant : composer require orm-fixtures --dev

On peut créer une Fixture en appelant la commande php bin/console make:fixtures [NomFixtures] et une fois que le script est terminé, on peut l'appeler à volonté en tapant php bin/console doctrine:fixtures:load

Preview 07:44

Faker est un concept qui existe dans à peu près tous les langage et se décline sous la forme de librairies pour PHP, Javascript, Ruby, Python etc.

Son but est de nous fournir des données aléatoires mais réalistes (des prénoms, des noms de famille, des villes et adresses etc). Cette librairie est donc particulièrement appréciée lorsqu'il s'agit d'établir des jeux de fausses données.

Preview 07:06

La librairie Slugify écrite par Cocur est une simple classe PHP qui nous fournit des opérations de transformation de chaines de caractères : on part d'une chaine classique et on arrive sur son équivalent compatible en URL.

Par exemple : "C'est vraiment super" devient "c-est-vraiment-super".

Créer des slugs facilement avec Slugify
04:34

Grâce à Doctrine, nous manipulons les enregistrements d'une table via une Entité : chaque enregistrement est une instance de la classe Entité dont il est issu. Et Doctrine nous permet de travailler sur les enregistrements à différents stades de leur existence : on appelle ça le Cycle de vie d'une entité.

Il existe donc plusieurs étapes de la vie d'un enregistrement sur lesquelles on peut se greffer afin de réagir et de modifier l'enregistrement lui-même.

Preview 06:47

Un Schéma qui explique les événements du cycle de vie d'une entité Doctrine

Graphique sur les événements du cycle de vie d'une entité (non exhaustif)
00:14

Doctrine nous permet de représenter des tables par des classes appelées Entités. Et bien sur il nous permet aussi de représenter la façon dont différentes tables sont reliées les unes aux autres. On appelle ça les relations.

Il existe 4 types de relations :

  • OneToMany : Un objet A est lié à plusieurs objets B, et chaque objet B n'est lié qu'à un seul objet A (ex: une entreprise fait travailler plusieurs salariés, chaque salarié n'est lié qu'à une entreprise).

  • ManyToOne : Plusieurs objets A peuvent être liés à un objet B, et chaque objet B ne possède qu'un seul objet A (ex: plusieurs salariés travaille dans une seule entreprise, chaque entreprise est liée à plusieurs salariés). C'est le miroir de la relation OneToMany.

  • OneToOne : Un objet A est lié à un seul objet B, et chaque objet B n'est lié qu'à un seul objet A (ex: Chaque animal est adopté par une personne, chaque personne n'adopte qu'un seul animal).

  • ManyToMany : Un objet A est lié à plusieurs objets B et chaque objet B peut être lié à plusieurs objets A (ex: Une entreprise fait travailler plusieurs salariés, et un salarié peut travailler dans plusieurs entreprises).

Comprendre Doctrine : les relations entre Entités avec l'Entité Image
08:11

A chaque nouvelle Entité (et donc chaque nouvelle table) que l'on créé, on peut enrichir la Fixture afin d'ajouter de fausses données pour cette table aussi.

Enrichir la Fixture pour créer des images
03:52

Vérifions ensemble que vous avez compris l'essentiel de cette section sur la base de données ;-)

Le lien entre Symfony et les bases de données
6 questions
+ Notre premier Controller : le AdController pour la gestion des annonces
11 lectures 58:17

On créé une page statique qui affiche une liste d'annonces fixes (non issues de la base de données) pour préparer le terrain à la liste des véritables annonces.

Affichage de la liste des annonces
06:16

On étudie ici la fonction findAll() des Repositories Doctrine de façon à récupérer la liste de toutes les annonces via le AdRepository et à les afficher dans le template précédemment créé.

Preview 06:07

Dans Symfony, quand une de nos fonctions a besoin de quelque chose, elle peut le demander à Symfony directement grâce à l'injection de dépendance. C'est un concept qui existe dans beaucoup de frameworks et qui consiste à laisser un acteur unique et central (ici, Symfony) créer les objets dont nos fonctions ou classes ont besoin.

Preview 07:47

Les Repositories de Doctrine savent à quelle table spécifique ils s'adressent. Il est donc possible d'utiliser des fonctions comme findOneByX(...) ou encore findByX(...) avec X représentant un champ de la table.

Ces fonctions nous permettent de chercher et de faire remonter les données souhaitées sous la forme d'instances de la classe Entity.

Récupération d'une annonce avec son slug grâce au Repository
07:36
Affichage d'une annonce
06:04
Un peu de CSS personnalisé
03:30

Grâce à Doctrine, il est très facile d'exploiter des données qui sont reliées les unes aux autres. On peut très simplement parcourir une collection d'objets liés à un objet qu'on étudie.

Parcourir les images liées à une annonce grâce à la relation entre les 2 entités
08:58
Mise à jour de la barre de navigation
01:17

On veut créer un lien vers la page d'une annonce, mais comment faire pour préciser de quelle annonce il s'agit ? Grâce à la fonction path() de Twig !

Liens paramétrés dans la liste des annonces
02:40

Dans un template Twig (et dans tout fichier en théorie), lorsque l'on voit un code qui se répète, on peut le centraliser à un endroit unique pour ensuite utiliser ce code aux différents endroits où on en a besoin. Pour ce faire, on peut créer une variable Twig avec la syntaxe {% set maVariable = ... %}

Preview 02:21

Le ParamConverter est une brique de Symfony qui est vraiment très pratique. Comme son nom l'indique, son but est de convertir un paramètre d'une route en un véritable objet issu de la base de données. 

Par exemple, si une Route attend un paramètre "slug", on peut demander à Symfony de nous passer directement l'objet dont le slug est celui qu'on a reçu.

Preview 05:41

Vérifions ensemble si les notions absolument essentielles sont retenues !

Les Controllers et leurs utilitaires
6 questions
+ Symfony et les formulaires
15 lectures 01:14:26

Une nouveauté de Symfony 3 pourrait vous causer des problèmes pendant les futures sections, prenez les devants :-)

A l'attention des étudiants qui sont sous Symfony 4.3
00:29

Si l'on veut un jour pouvoir afficher un formulaire pour créer de nouvelles annonces, encore faut-il avoir une page qui puisse le présenter !

Créer la page de création d'une annonce
03:43

On va désormais créer le formulaire que l'on souhaite afficher. On fait ça directement au sein de notre Controller grâce à la fonction "createFormBuilder()". Elle nous donne une constructeur de formulaire qu'il est très simple de manipuler pour obtenir un objet de la classe Form.

Découverte du FormBuilder : le fabricant de formulaire
04:53

Le formulaire étant créé, il faut maintenant l'afficher et donc comprendre comment Twig peut nous aider dans cette tâche !

Comprendre Twig : afficher un formulaire Symfony
08:27
Attention à AdBlock (extension Chrome et Firefox)
00:55

La mission du Controller n'est pas de créer et de configurer des formulaires, ce n'est qu'une facilité qu'on nous offre. Sa réelle mission est d'écouter une requête HTTP et de fabriquer pour elle une réponse HTTP.

Grâce à Symfony, on peut externaliser la création du formulaire afin qu'elle n'encombre pas le Controller. Un autre avantage est qu'en plus, si l'on souhaite se resservir du formulaire ailleurs, on pourra le faire d'autant plus facilement.

Créer une classe de Formulaire externe et réutilisable
03:52

Twig nous propose différentes fonctions qui permettent d'afficher les champs du formulaire, leur label ou leur message d'erreur. Suivez le guide !

Comprendre Twig : les fonctions d'affichage de formulaire
02:25

Maintenant qu'on connait les fonctions d'affichage des champs avec Twig, essayons de voir comment mettre en forme le formulaire pour qu'il s'intègre un peu plus à notre thème Bootstrap !

Comprendre Twig : mise en forme du formulaire
03:31

On comprend qu'on va avoir un fichier trop volumineux si on s'attarde à mettre en forme chaque champ et on découvre alors la notion de thèmes de formulaires.

Comprendre Twig : les thèmes de formulaires
08:47

On comprend que créer notre propre thème est tout à fait passionnant mais prend beaucoup de travail et de temps. On découvre donc qu'il existe un thème dédié à Bootstrap 4 pour nos formulaires et qu'il est en plus livré avec Symfony !

Comprendre Twig : le thème de formulaire Bootstrap 4
03:00

Ici, on cherche à voir comment configurer précisément chaque champ de notre formulaire grâce aux options des champs !

Configurer les champs de formulaire
09:48

Quand le visiteur a fini de remplir son formulaire et qu'il le soumet, ce qu'on souhaite faire c'est prendre en compte les informations qu'il a rempli afin de les enregistrer : étudions cela dans cette vidéo.

Récupérer et sauvegarder les données du formulaire
07:49

Parfois, la réponse que le Controller cherche à renvoyer n'est pas l'affichage d'une page mais plutôt une redirection vers une autre page. On peut faire cela grâce à la fonction redirectToRoute() de notre formulaire !

Effectuer une redirection vers la page de la nouvelle annonce
02:10

Lorsqu'une action vient d'avoir lieu, on veut pouvoir en tenir l'utilisateur informé. Pour cela on utilise le système très rependu des messages Flash. Dans nos controllers on peut utiliser la fonction addFlash() afin d'ajouter un message qui sera ensuite affiché à l'utilisateur.

Utiliser les messages Flash pour notifier le visiteur
10:39

Lorsque l'on constate qu'on répète plusieurs fois un même code, à différents endroits, il est très utile de pouvoir le centraliser à un endroit unique pour ensuite y faire appel plusieurs fois (on appelle ça le DRY : Don't Repeat Yourself). 

On découvre comment faire cela avec Twig grâce à son tag include !

Comprendre Twig : les inclusions de template
03:58
+ Aller plus loin avec les formulaires
14 lectures 01:16:02

Parfois, on veut imbriquer des sous-formulaires au sein d'un formulaire plus global. Ici par exemple, nous souhaitons pouvoir créer des images qui seront liées à notre annonce en même temps que l'on créé l'annonce elle même. 

On peut faire ça grâce à un type de champ particulier : le CollectionType !

Preview 07:01

L'affichage de nos sous-formulaires laisse à désirer, on voit ici comment on peut affiner cet affichage grâce aux fonctionnalités de Twig et des thèmes de formulaires.

Comprendre Twig : personnaliser l'affichage des sous-formulaires
06:45

On veut désormais pouvoir afficher dynamiquement des sous-formulaires pour gérer les images de l'annonce. Pour ce faire, il faut se familiariser avec la notion de prototype : il représente le code HTML nécessaire à l'affichage d'un élément de notre collection de sous-formulaires !

Ajouter un élément dynamiquement grâce au prototype du CollectionType
07:41

On veut maintenant pouvoir supprimer un des sous-formulaires que notre CollectionType affiche.

Supprimer un élément dynamiquement grâce au CollectionType
06:31

On voit ici une première approche de la persistance des données issues d'une collection de sous-formulaires.

Faire persister les éléments liés avec le CollectionType
04:53

On corrige ici un bug Javascript que nous avions introduit plus tôt concernant les index des sous-formulaires.

Correction d'un bug sur les index des sous-formulaires
03:49

On fait en sorte que le champ Slug ne soit plus obligatoire pour pouvoir soumettre le formulaire, il devient optionnel.

Rendre le champ "slug" non obligatoire (option required)
03:30

La validation de formulaires est un point central dans n'importe quelle application web. On veut interdire certaines valeurs, on veut aussi contraindre les valeurs données par l'utilisateur par rapport à certaines règles précises, et surtout, on veut prévenir l'utilisateur si des erreurs se sont produites.

Symfony nous permet de faire tout cela très simplement grâce à ses règles de validations appelées des contraintes (Constraints).

La validation de formulaire avec Symfony
07:59

Ici, on ne cherche plus à valider un champ particulier de l'annonce, mais plutôt l'unicité de l'annonce : on ne veut pas que l'utilisateur puisse créer une annonce dont le titre est déjà pris par une autre annonce !

C'est ce que permet de faire l'annotation @UniqueEntity !

Valider l'unicité d'une entité et éviter les doublons !
03:30

On veut maintenant créer un formulaire d'édition de l'annonce qui se basera sur la même classe de formulaire que la création de l'annonce !

Créer un formulaire d'édition pour nos annonces
08:52

On voudrait être sur que les données entrées pour les sous-formulaires du formulaire d'annonce soient aussi validées par des contraintes de validation. Par défaut, seul l'entité principale est validée, pas les entités liées.

Avec Symfony, on peut faire ça très simplement avec la contrainte de validation qui s'appelle Valid placée sur la relation avec les autres entités !

Valider les sous-formulaires du CollectionType
04:30

On corrige ici un simple bug que l'on a introduit plus tôt dans notre Javascript

Correction d'un bug lors de la suppression d'éléments du CollectionType
04:41

Encore une fois, quand on constate qu'un code est dupliqué à plusieurs endroits, on se doit de le centraliser afin de rendre notre site plus évolutif !

C'est ce que l'on va faire entre les deux formulaires d'édition et de création d'annonce qui sont relativement identiques !

Refactorisation du code entre les formulaire de création et d'édition
05:16

On a bien avancé, donc on versionne le code.

Versionning de notre avancement avec GIT
01:04
+ Les utilisateurs et l'authentification dans Symfony
21 lectures 01:55:33

Si l'on veut pouvoir gérer des utilisateurs, il nous faut une entité qui sera le reflet de la table qui contiendra ces utilisateurs dans la base de données : l'entité User

Création d'une entité User pour stocker nos utilisateurs
04:16

Les utilisateurs du site pourront créer des annonces, on leur donne donc une relation 1 à plusieurs avec l'entité Ad

La relation OneToMany entre les annonces (Ad) et les utilisateurs (User)
05:41

On profite de notre Fixture pour créer des utilisateurs avec de fausses données

Mise à jour de la Fixture pour créer de faux utilisateurs
06:57

Découvrez l'API RandomUser.me qui vous fourni des données de profils utilisateurs de façon aléatoire dont notamment des avatars !

Des avatars aléatoires pour nos faux utilisateurs avec RandomUser.me
05:21

Il est absolument proscrit d'avoir des mots de passe en clair dans une base de données dans le cas où celle ci viendrait à être compromise, il faut donc encoder les mots de passe et Symfony possède l'outil idéal pour le faire ;-)

L'encodage des mots de passe de nos utilisateurs
04:34

Si l'on veut que le composant de Sécurité de Symfony comprenne et puisse utiliser notre entité User comme celle qui représente les utilisateurs de notre système, il faut que l'entité User implémente une interface particulière : la UserInterface !

Découverte de l'interface UserInterface
05:38

Pour que le composant de Sécurité comprenne que nous utilisateurs viennent de la base de données, il faut le lui préciser en créant ce qu'on appelle un provider (un fournisseur de données utilisateurs).

Authentification : déclare un nouveau provider (entité User)
02:55

Il faut désormais que l'on permette aux utilisateurs de se connecter, et pour ça il faut commencer par un formulaire de connexion !

Authentification : créer le formulaire de connexion
07:06

Une fois que le formulaire est prêt, il faut prévenir le composant de Sécurité qu'on veut s'en servir pour l'authentification des utilisateurs. Pour cela il faut lui préciser qu'on voudra utiliser la méthode form_login et lui donner les détails de l'implémentation !

Authentification : authentifier réellement l'utilisateur
04:12

On veut maintenant permettre aux utilisateurs connectés de se déconnecter du site, cela se fait en précisant au composant de Sécurité qu'on veut cette possibilité !

Authentification : permettre à l'utilisateur de se déconnecter
03:06

On découvre un petit utilitaire ici : la classe AuthenticationUtils qui permet d'avoir des informations sur l'authentification (erreur, dernier email utilisé ...)

Authentification : repérer les erreurs avec la classe AuthenticationUtils
04:24

On créé désormais un formulaire d'inscription pour nos utilisateurs.

Créer le formulaire d'inscription : le RegistrationType
08:03

On utilise ici la Programmation Orientée Objet pour mettre en commun du code entre deux classes différentes en créant une classe parente !

Refactorisation du code entre les classes AdType et RegistrationType
03:38

Il faut désormais enregistrer les informations du formulaire d'inscription, y compris l'encodage du password.

Enregistrer les données du formulaire d'inscription
05:56

On cherche à s'assurer que le formulaire d'inscription sera valide en utilisant les contraintes de validation de Symfony !

Valider le formulaire d'inscription
04:45

On veut pouvoir s'assurer que la personne confirme bien son mot de passe et on utilise pour ça une contrainte de validation particulière : EqualTo()

Créer une confirmation de mot de passe durant l'inscription
04:27

On met simplement à jour la barre de navigation pour faire la différence entre un utilisateur authentifié et un utilisateur anonyme !

Mise à jour de la barre de navigation
02:56

On créé le formulaire de modification de profil pour les utilisateurs authentifiés

Créer un formulaire d'édition du profil utilisateur
07:24

On créé un formulaire de modification de mot de passe pour l'utilisateur authentifié

Créer un formulaire de modification du mot de passe
10:58

On sauvegarde le nouveau mot de passe.

Sauvegarder le nouveau mot de passe
08:04

Nous souhaitons pouvoir afficher une erreur de validation sur un champ qui n'a pas de validation, il nous faut donc trouver un moyen de faire ceci, on étudie donc l'API de la classe Form

Créer une erreur personnalisée sur le formulaire de modification de mot de passe
05:12
+ Intégration des utilisateurs dans le reste du site
8 lectures 37:14

Ce que l'on souhaite faire maintenant c'est intégrer nos utilisateurs dans les autres affichages, et notamment intégrer l'auteur d'une annonce dans la page d'une annonce

Afficher l'auteur dans la page d'une annonce
07:33

On créé une page de profil d'un utilisateur qui nous permet d'en apprendre plus sur lui et de voir ses annonces

Créer une page de profil pour les utilisateurs
11:26

Maintenant que les utilisateurs ont une page à eux, il faut qu'on puisse faire des liens vers cette page partout où c'est nécessaire !

Faire les liens vers la page de profil d'un utilisateur
01:44

On créé une page "Mon compte" pour les utilisateurs authentifiés

Créer la page "Mon compte"
02:22

Grâce à Twig, on place des liens qui concernent l'utilisateur uniquement destinés à l'utilisateur authentifié

Ajouter des liens de gestion du compte utilisateur
03:19

On enrichi notre barre de navigation afin d'offrir plus d'ergonomie aux utilisateurs authentifiés

Mise en place d'une dropdown dans la barre de navigation
06:09

Jusqu'ici, une annonce nouvellement créée n'était pas liés à un utilisateur. Il faut donc désormais que chaque nouvelle annonce soit liée à l'utilisateur authentifié (qui a créé l'annonce).

Prendre en compte l'utilisateur connecté lorsqu'on créé une annonce
03:52

On versionne notre avancement.

Versionning de notre avancement avec GIT
00:49
+ La sécurité et les autorisations dans Symfony 4
9 lectures 47:11

Si l'on souhaite mettre en place un système de rôles, il nous faut créer une table qui va contenir les différents rôles existant dans notre base de données.

Mise en place des rôles d'utilisateurs
06:12

On modifie la fixture pour créer un rôle d'Administrateur et un utilisateur qui possède ce rôle : l'administrateur du site.

Modification de la Fixture pour créer un rôle ADMIN et un administrateur
05:10

Si l'on souhaite que le composant de Sécurité puisse connaitre les rôles de chaque utilisateur, il faut utiliser la fonction getRoles(), mais comment faire pour transformer des rôles qui sont des entités, en simple chaîne de caractères ?

Récupération des rôles dans l'entité User
10:47

Maintenant que tout est en place, on souhaite sécuriser notre controller des annonces afin d'être sur que chaque chose soit faite par un utilisateur qui en a le droit !

On utilise pour ça des annotations particulières :

  • @IsGranted("nomDuRole") permet de s'assurer que l'utilisateur possède bien un rôle donné

  • @Security(ExpressionDeSecurite) permet de créer des règles de sécurité plus précises

Preview 09:25

On sécurise désormais le controller des comptes utilisateurs !

Sécuriser le AccountController avec les annotations @IsGranted() et @Security()
03:26

Grâce à Twig, on affiche désormais les liens qui correspondent à chaque utilisateur authentifié

Afficher des liens et bouton en fonction du statut de l'utilisateur
03:32

Maintenant qu'on a mis en place des sécurisations, on peut se permettre de proposer à un utilisateur de supprimer une annonce en utilisant Doctrine et son manager.

Permettre aux utilisateurs de supprimer leurs annonces
05:52

On versionne notre avancement avec GIT

Versionning de notre avancement avec GIT
01:12

On a terminé la gestion de la sécurité dans l'application, on peut désormais passer à la section suivante !

Conclusion et ouvertures
01:35
+ Gérer les pages d'erreurs dans Symfony 4
4 lectures 17:39

Dans l'environnement de développement, les pages d'erreurs sont faites pour débuger facilement mais elles ne sont pas adaptées à la production. Par ailleurs les pages d'erreurs qui existent en production sont tout à fait banales. On peut évidemment créer ses propres pages d'erreurs et c'est ce qu'on étudie ici.

Comprendre la gestion des pages d'erreurs dans une application Symfony 4
02:44

La première page d'erreur que l'on souhaite revoir, c'est celle qui concerne l'erreur 404. Pour modifier cet affichage il suffit de surcharger le gabarit d'origine de Twig : error404.html.twig

Créer une page d'erreur 404 personnalisée et la tester
06:09

La deuxième erreur qu'on veut personnaliser est la page 403. C'est le même phénomène : on surcharge le template original de Twig qui s'appelle error403.html.twig.

Créer une page d'erreur 403 personnalisée et la tester
04:43

Il peut être tenant de faire apparaitre sur une page d'erreur le message d'erreur précis. Mais à ce moment là il faut être particulièrement vigilent avec le cache de Symfony.

Faire attention au cache en environnement de production
04:03
Requirements
  • Maîtrise de PHP
  • Maîtrise de la programmation orientée objets (POO)
  • Maîtrise de HTML et CSS
Description

On n'apprend jamais mieux que par la pratique. Cette formation destinée à tous les développeurs qui veulent en savoir plus sur le Framework Symfony 4 vous permettra de créer étape après étape un véritable site d'annonces sur lequel les utilisateurs pourront :

  • S'inscrire, s'authentifier et gérer leur compte

  • Créer des annonces afin de mettre en location leur bien

  • Réserver une location

  • Commenter et noter l'annonce après que la location ait eu lieu

De  plus, le site fournira aux administrateurs une véritable interface de gestion sécurisée. On passera donc par l'ensemble des étapes classiques de la création d'une application web.

Les notions sont distillées tout au long des vidéos et ne sont abordées que lorsqu'on en a vraiment besoin et qu'on peut donc les mettre immédiatement en pratique.

Alors embarquez avec moi pour ces 20 heures de vidéo et devenez un véritable développeur Symfony 4, vous aurez alors des bases solides pour continuer par vous même votre apprentissage de toutes les subtilités du Framework !

Who this course is for:
  • Les développeurs PHP qui veulent avoir une première expérience avec un Framework
  • Les développeurs PHP qui connaissent déjà un Framework et veulent découvrir Symfony 4