Le cache sous Symfony 6

L’utilisation d’un cache est un excellent moyen de rendre votre application plus rapide. Le composant de cache Symfony est livré avec de nombreux adaptateurs pour différents stockages. Chaque adaptateur est développé pour une haute performance.

L’exemple suivant montre une utilisation typique du cache :

use Symfony\Contracts\Cache\ItemInterface;

// The callable will only be executed on a cache miss.
$value = $pool->get('my_cache_key', function (ItemInterface $item) {
    $item->expiresAfter(3600);

    // ... do some HTTP request or heavy computations
    $computedValue = 'foobar';

    return $computedValue;
});

echo $value; // 'foobar'

// ... and to remove the cache key
$pool->delete('my_cache_key');

Symfony supporte les contrats de cache et les interfaces PSR-6/16. Vous pouvez en savoir plus à ce sujet dans la documentation du composant.

Configuration du cache avec FrameworkBundle

Lorsque vous configurez le composant de cache, il y a quelques concepts que vous devez connaître :

Pool
Il s’agit d’un service avec lequel vous allez interagir. Chaque pool aura toujours son propre espace de noms et ses propres éléments de cache. Il n’y a jamais de conflit entre les pools.
Adaptateur
Un adaptateur est un modèle que vous utilisez pour créer des pools.
Fournisseur
Un fournisseur est un service que certains adaptateurs utilisent pour se connecter au stockage. Redis et Memcached sont des exemples de tels adaptateurs. Si un DSN est utilisé comme fournisseur, un service est automatiquement créé.
Il y a deux pools qui sont toujours activés par défaut. Il s’agit de cache.app et cache.system. Le cache système est utilisé pour des éléments tels que les annotations, le sérialiseur et la validation. Le cache.app peut être utilisé dans votre code. Vous pouvez configurer quel adaptateur (template) ils utilisent en utilisant la clé app et system comme :

# config/packages/cache.yaml
framework:
    cache:
        app: cache.adapter.filesystem
        system: cache.adapter.system

Comment personnaliser les pages d’erreur

Dans les applications Symfony, toutes les erreurs sont traitées comme des exceptions, qu’il s’agisse d’une erreur 404 Not Found ou d’une erreur fatale déclenchée par une exception dans votre code.

Dans l’environnement de développement, Symfony attrape toutes les exceptions et affiche une page d’exception spéciale avec beaucoup d’informations de débogage pour vous aider à découvrir le problème de base :

Comme ces pages contiennent beaucoup d’informations internes sensibles, Symfony ne les affichera pas dans l’environnement de production. A la place, il affichera une page d’erreur minimale et générique :

Les pages d’erreur pour l’environnement de production peuvent être personnalisées de différentes manières en fonction de vos besoins :

• Si vous souhaitez uniquement modifier le contenu et les styles des pages d’erreur pour qu’ils correspondent au reste de votre application, remplacez les modèles d’erreur par défaut ;
• Si vous voulez modifier le contenu de la sortie d’erreur non-HTML, créez un nouveau normalisateur ;
• Si vous souhaitez également modifier la logique utilisée par Symfony pour générer les pages d’erreur, remplacez le contrôleur d’erreur par défaut ;
• Si vous avez besoin d’un contrôle total de la gestion des exceptions pour exécuter votre propre logique, utilisez l’événement kernel.exception.

Overrider ( Remplacer ) les modèles d’erreur par défaut

composer require symfony/twig-pack

Vous pouvez utiliser le moteur de rendu d’erreurs intégré de Twig pour remplacer les modèles d’erreurs par défaut. Pour cela, TwigBundle et TwigBridge doivent être installés. Exécutez cette commande pour vous assurer que les deux sont installés :

Lorsque la page d’erreur se charge, TwigErrorRenderer est utilisé pour rendre un modèle Twig à montrer à l’utilisateur.

Ce moteur de rendu utilise le code d’état HTTP et la logique suivante pour déterminer le nom de fichier du modèle :

• Rechercher un modèle pour le code d’état donné (comme error500.html.twig) ;
• Si le modèle précédent n’existe pas, il ne tient pas compte du code d’état et recherche un modèle d’erreur générique (error.html.twig).

Pour remplacer ces modèles, utilisez la méthode Symfony standard pour remplacer les modèles qui se trouvent dans un bundle et placez-les dans le répertoire templates/bundles/TwigBundle/Exception/.

Un projet typique qui renvoie des pages HTML peut ressembler à ceci :

templates/
└─ bundles/
   └─ TwigBundle/
      └─ Exception/
         ├─ error404.html.twig
         ├─ error403.html.twig
         └─ error.html.twig      # All other HTML errors (including 500)

Exemple de modèle d’erreur 404

Pour remplacer le modèle d’erreur 404 pour les pages HTML, créez un nouveau modèle error404.html.twig situé dans templates/bundles/TwigBundle/Exception/ :

{# templates/bundles/TwigBundle/Exception/error404.html.twig #}
{% extends 'base.html.twig' %}

{% block body %}
    <h1>Page not found</h1>

    <p>
        The requested page couldn't be located. Checkout for any URL
        misspelling or <a href="{{ path('homepage') }}">return to the homepage</a>.
    </p>
{% endblock %}

Au cas où vous en auriez besoin, le TwigErrorRenderer transmet certaines informations au modèle d’erreur via les variables status_code et status_text qui stockent respectivement le code d’état HTTP et le message.

Note : Vous pouvez personnaliser le code d’état d’une exception en implémentant l’interface HttpExceptionInterface et sa méthode getStatusCode(). Dans le cas contraire, le code d’état prendra la valeur 500 par défaut.

En outre, vous avez accès à l’exception avec exception, qui vous permet par exemple d’afficher la trace de la pile en utilisant {{ exception.traceAsString }} ou d’accéder à toute autre méthode sur l’objet. Vous devez cependant être prudent, car vous risquez d’exposer des données sensibles.

Note : Les erreurs PHP sont également transformées en exceptions par défaut, de sorte que vous pouvez également accéder aux détails de ces erreurs en utilisant exception.

Sécurité et pages 404

En raison de l’ordre dans lequel le routage et la sécurité sont chargés, les informations de sécurité ne seront pas disponibles sur vos pages 404. Cela signifie qu’il apparaîtra comme si votre utilisateur était déconnecté sur la page 404 (cela fonctionnera lors des tests, mais pas en production).