# Fonctionnalités de site : Horizon, Reverb, Pulse, WordPress > Activez Laravel Horizon, Reverb, Pulse, Inertia SSR, Nightwatch, Symfony Messenger, le cron et Redis de WordPress, le mode maintenance ou un mot de passe. Les **fonctionnalités de site** sont des configurations toutes prêtes pour les outils qu'utilise votre framework, comme Laravel Horizon, Reverb ou le cron de WordPress. Vous les activez depuis le menu du framework dans l'en-tête du site, et Vimonto Deploy configure sur le serveur tout ce dont l'outil a besoin : processus Supervisor, tâches cron, directives Nginx et valeurs du `.env`. Le menu, et le bouton **Ouvrir** à côté, apparaissent une fois la première installation du site terminée et sa première version en ligne. La fenêtre de chaque fonctionnalité montre exactement ce qu'elle va configurer avant que vous ne l'activiez, et les fonctionnalités sont redémarrées après chaque déploiement si nécessaire. ![Le menu des fonctionnalités Laravel dans l'en-tête du site avec Horizon et le planificateur activés](https://ops.vimonto.com/docs-media/fr/site-features-menu.webp?v=161e760d "Le menu du framework d'un site Laravel") ![Ouverture du menu des fonctionnalités et de la fenêtre d'une fonctionnalité](https://ops.vimonto.com/docs-media/fr/site-features.mp4?v=161e760d) ## Ouvrir le menu des fonctionnalités Le menu se trouve dans l'en-tête du site et porte le nom du framework du site, par exemple **Laravel** ou **WordPress**. Il s'ouvre sur les fonctionnalités du framework, comme **Fonctionnalités Laravel**, avec un point vert pour celles qui sont activées et un compteur comme **2 sur 7 activées**. Vimonto Deploy lit les paquets de votre `composer.json` et de votre `package.json` à chaque déploiement. Les fonctionnalités dont votre application utilise le paquet sont marquées **Dans votre code** et listées en premier, avec les fonctionnalités déjà activées ; les autres se trouvent derrière **Tout afficher (… de plus, absentes de votre code)**. Jusqu'au premier déploiement, toutes les fonctionnalités sont listées. ## Activer ou désactiver une fonctionnalité 1. Cliquez sur la fonctionnalité dans le menu pour ouvrir sa fenêtre. 2. Renseignez ses réglages, s'il y en a. 3. Vérifiez **Ce que nous configurons** et **Nous définissons dans votre .env**. Les clés dont la valeur change sont marquées **change**. 4. Cliquez sur **Activer**. L'activation s'exécute sous forme de tâche en arrière-plan que vous pouvez suivre dans l'en-tête du site. En cas d'échec, la fonctionnalité affiche **Échoué** dans le menu et vous recevez une [notification](https://ops.vimonto.com/docs/fr/more/notifications) ; ouvrez-la et cliquez sur **Enregistrer** pour réessayer, ou sur **Réessayer** pour une fonctionnalité sans réglages, comme le Planificateur ou Pulse. Les deux appliquent à nouveau les mêmes réglages. Pour modifier les réglages d'une fonctionnalité activée, ouvrez-la, modifiez-les et cliquez sur **Enregistrer**. Pour la désactiver, ouvrez-la et cliquez sur **Désactiver** : ses processus, ses tâches cron et ses directives Nginx sont supprimés. Les valeurs qu'elle a définies dans le `.env` restent. Les fonctionnalités nécessitent un site configuré et, pour la plupart, déployé : leurs commandes s'exécutent dans la release en ligne. Les fonctionnalités avec des directives Nginx nécessitent la configuration Nginx générée du site, ou une [configuration personnalisée](https://ops.vimonto.com/docs/fr/sites/nginx) qui conserve la ligne d'include des directives supplémentaires. ## Quelles fonctionnalités existe-t-il ? | Fonctionnalité | Frameworks | Ce qu'elle configure | |---|---|---| | [Planificateur](#planificateur) | Laravel, Statamic | Cron : `schedule:run` chaque minute | | [Horizon](#horizon) | Laravel, Statamic | Processus : `artisan horizon` | | [Reverb](#reverb) | Laravel, Statamic | Processus, Nginx, DNS, `.env` | | [Pulse](#pulse) | Laravel, Statamic | Processus : `artisan pulse:check` | | [Inertia SSR](#inertia-ssr) | Laravel, Statamic | Processus : `artisan inertia:start-ssr` | | [Nightwatch](#nightwatch) | Laravel, Statamic | Processus : `artisan nightwatch:agent`, `.env` | | [Workers Messenger](#workers-messenger) | Symfony | Processus : `messenger:consume` | | [Vrai cron](#vrai-cron-pour-wordpress) | WordPress | Cron : WP-CLI chaque minute | | [Cache d'objets Redis](#cache-dobjets-redis-pour-wordpress) | WordPress | Plugin WordPress | | [Durcissement](#durcissement-pour-wordpress) | WordPress | Règles Nginx, constante dans `wp-config.php` | | [Mode maintenance](#mode-maintenance) | Laravel, Statamic, WordPress | `artisan down` ou WP-CLI | | [Protection par mot de passe](#protection-par-mot-de-passe) | Tous, y compris les sites à charge répartie | Authentification basique Nginx | Les processus tournent sous Supervisor avec l'utilisateur du site et apparaissent sur la page [files d'attente et planificateur](https://ops.vimonto.com/docs/fr/sites/queues-and-scheduler) avec un badge **Via …**. Les tâches cron s'exécutent sous l'utilisateur du site. ## Fonctionnalités Laravel ### Planificateur Exécute vos commandes planifiées : une entrée cron exécute `php artisan schedule:run` chaque minute dans la release en ligne. C'est le même interrupteur que **Activer** sur la page [files d'attente et planificateur](https://ops.vimonto.com/docs/fr/sites/queues-and-scheduler#activer-le-planificateur-laravel). ### Horizon Fait tourner vos files Redis avec [Laravel Horizon](https://laravel.com/docs/horizon) : un programme Supervisor exécute `php artisan horizon`, qui démarre chaque worker décrit dans votre `config/horizon.php`. - **Réglage** : **Tâche la plus longue (secondes)**, 3600 par défaut. Lors d'un déploiement, les jobs en cours disposent de ce délai pour se terminer avant l'arrêt du processus. - **Après chaque déploiement** : `php artisan horizon:terminate`, pour qu'Horizon termine ses jobs et que Supervisor le relance sur le nouveau code. - **.env** : `QUEUE_CONNECTION=redis`. - **Lien** : le **Tableau de bord Horizon** sur `/horizon`. La fenêtre vous avertit quand le site a aussi ses propres queue workers (supprimez-les, pour que les jobs ne soient pas traités deux fois), et quand le serveur n'a pas Redis (faites pointer `REDIS_HOST` vers un [serveur de cache](https://ops.vimonto.com/docs/fr/servers/server-types)). ### Reverb Fait tourner [Laravel Reverb](https://laravel.com/docs/reverb), le serveur WebSocket pour le broadcasting, sur sa propre adresse WebSocket. - **Adresse WebSocket** : `ws.` suivi du domaine du site par défaut, comme `ws.shop.example.com`. - **Port local** : le port sur lequel Reverb écoute, uniquement sur le serveur lui-même, à partir de 8080. Chaque application du serveur a besoin du sien. Quand vous l'activez, Vimonto Deploy : - exécute `php artisan reverb:start --host=127.0.0.1 --port=…` sous Supervisor ; - ajoute l'adresse WebSocket aux noms du site, ainsi que des règles Nginx qui transmettent `/app/` (connexions WebSocket) et `/apps/` (l'API HTTP de Reverb) à Reverb ; - crée l'enregistrement DNS quand l'adresse est sur `on-deploy.link`, ou quand le domaine du site est géré par une [intégration DNS](https://ops.vimonto.com/docs/fr/connections/integrations) connectée ; un enregistrement qui y pointe ailleurs et que Vimonto Deploy n'a pas créé est laissé tel quel, et la tâche le signale. Sinon, la fenêtre liste l'enregistrement A à créer, pointant vers l'adresse IP du serveur ; - demande un nouveau certificat Let's Encrypt incluant l'adresse WebSocket quand le site en a déjà un et que le nom pointe vers le serveur. Sinon, demandez un nouveau certificat dans [domaines et SSL](https://ops.vimonto.com/docs/fr/sites/domains-and-ssl) une fois l'enregistrement DNS en place ; - exécute `php artisan reverb:restart` après chaque déploiement. Elle définit ces clés dans le `.env`, en réutilisant l'ID, la clé et le secret d'application Reverb si votre `.env` les contient déjà, et en les générant sinon : ```ini BROADCAST_CONNECTION=reverb REVERB_APP_ID=… REVERB_APP_KEY=… REVERB_APP_SECRET=… REVERB_HOST=ws.shop.example.com REVERB_PORT=443 REVERB_SCHEME=https REVERB_SERVER_HOST=127.0.0.1 REVERB_SERVER_PORT=8080 VITE_REVERB_APP_KEY="${REVERB_APP_KEY}" VITE_REVERB_HOST="${REVERB_HOST}" VITE_REVERB_PORT="${REVERB_PORT}" VITE_REVERB_SCHEME="${REVERB_SCHEME}" ``` Sans HTTPS sur le site, `REVERB_PORT` vaut `80` et `REVERB_SCHEME` vaut `http`. Redéployez ensuite, pour que votre build frontend prenne en compte les valeurs `VITE_`. Une fois Reverb activé, la fenêtre affiche l'**Adresse WebSocket** complète à laquelle vos clients se connectent. ### Pulse Maintient `php artisan pulse:check` en marche, pour que le tableau de bord [Laravel Pulse](https://laravel.com/docs/pulse) affiche le CPU, la mémoire et le disque du serveur. Elle exécute `pulse:restart` après chaque déploiement et renvoie au **Tableau de bord Pulse** sur `/pulse`. ### Inertia SSR Génère le rendu des pages Inertia côté serveur, pour des premiers chargements plus rapides et de meilleurs résultats dans les moteurs de recherche. Elle exécute `php artisan inertia:start-ssr` sous Supervisor et `inertia:stop-ssr` après chaque déploiement, pour que le serveur de rendu redémarre sur le nouveau bundle. - Construisez aussi le bundle SSR dans votre [script de déploiement](https://ops.vimonto.com/docs/fr/sites/deployments#modifier-le-script-de-déploiement), par exemple `npm run build && npx vite build --ssr`. La fenêtre vous avertit si elle n'y trouve pas `--ssr`. - Le serveur a besoin de Node.js (les serveurs d'application et web l'ont). - Le serveur SSR écoute sur le port d'Inertia, 13714 : un seul site par serveur peut donc l'utiliser. ### Nightwatch Maintient l'agent [Laravel Nightwatch](https://nightwatch.laravel.com) en marche (`php artisan nightwatch:agent`), pour que votre application envoie ses données à Nightwatch. - **Réglage** : **Jeton Nightwatch**, issu de votre application sur nightwatch.laravel.com. Laissez-le vide par la suite pour garder le token actuel. - **.env** : `NIGHTWATCH_TOKEN`, affiché masqué dans la fenêtre. ## Fonctionnalités Symfony ### Workers Messenger Exécute `bin/console messenger:consume` pour vos transports [Symfony Messenger](https://symfony.com/doc/current/messenger.html), avec `--time-limit=3600 --env=prod`. - **Transports** : séparés par des espaces, par ordre de priorité, comme `async scheduler_default`. Par défaut : `async`. - **Processus** : le nombre de workers qui tournent côte à côte (de 1 à 20). - **Après chaque déploiement** : `messenger:stop-workers`, pour que Supervisor les relance sur le nouveau code. ## Fonctionnalités WordPress Les fonctionnalités WordPress utilisent [WP-CLI](https://wp-cli.org), que Vimonto Deploy installe sur le serveur (dans `/usr/local/bin/wp`) la première fois qu'une fonctionnalité en a besoin. ### Vrai cron pour WordPress WordPress exécute normalement ses tâches planifiées quand quelqu'un visite une page, ce qui les fait sauter sur les sites peu fréquentés et ralentit les sites très fréquentés. **Vrai cron** définit `DISABLE_WP_CRON` dans `wp-config.php` et exécute à la place `wp cron event run --due-now` chaque minute via une vraie tâche cron. La désactiver retire à nouveau la constante. ### Cache d'objets Redis pour WordPress Installe et active le plugin [Redis Object Cache](https://wordpress.org/plugins/redis-cache/) et active le cache, pour que WordPress cesse de poser les mêmes questions à la base de données à chaque requête. Elle nécessite Redis sur le serveur ; la fonctionnalité n'est pas disponible sur les serveurs qui en sont dépourvus. La désactiver désactive le cache et le plugin. ### Durcissement pour WordPress Ferme les portes par lesquelles passent habituellement les attaques contre WordPress : - Nginx refuse `xmlrpc.php` ; - Nginx refuse d'exécuter des fichiers PHP dans `wp-content/uploads` ; - `DISALLOW_FILE_EDIT` désactive l'éditeur de fichiers de thèmes et de plugins dans le tableau de bord. ## Maintenance et accès ### Mode maintenance Affiche aux visiteurs une page de maintenance jusqu'à ce que vous le désactiviez. Tant qu'il est activé, l'en-tête du site affiche **Mode maintenance** ; cliquez dessus pour ouvrir la fenêtre. - **Laravel et Statamic** : exécute `php artisan down` avec un secret et `--retry=60`. La fenêtre affiche un **Lien de contournement (dépose un cookie)** qui vous permet de voir le site normalement. À chaque activation, le secret change : un ancien lien cesse donc de fonctionner. L'état est conservé dans `storage/`, partagé entre les releases : il survit donc aux déploiements. - **WordPress** : exécute `wp maintenance-mode activate`. ### Protection par mot de passe Demande un nom d'utilisateur et un mot de passe (authentification HTTP basique) avant que quiconque ne voie le site : utile pour les sites de staging et les aperçus sur l'adresse `on-deploy.link`. - **Nom d'utilisateur** : `preview` par défaut ; lettres, chiffres, `.`, `_` et `-`. - **Mot de passe** : au moins 8 caractères. Seul un hash bcrypt est stocké. Laissez-le vide par la suite pour garder le mot de passe actuel. Let's Encrypt peut toujours atteindre le site pour délivrer et renouveler les certificats pendant qu'il est protégé. Sur un [site à charge répartie](https://ops.vimonto.com/docs/fr/sites/load-balancing), la protection par mot de passe est la seule fonctionnalité, et elle protège d'un coup tous les serveurs d'application placés derrière le load balancer. Pour ne protéger qu'un chemin, comme `/admin`, ou donner à plusieurs personnes leur propre connexion, utilisez plutôt des [règles de sécurité](https://ops.vimonto.com/docs/fr/sites/security-rules). Une règle de sécurité pour tout le site et la protection par mot de passe ne peuvent pas être actives en même temps. ## Questions fréquentes ### Que signifie « Dans votre code » ? Le paquet de la fonctionnalité figure dans votre `composer.json` ou votre `package.json` lors du dernier déploiement, par exemple `laravel/horizon` pour Horizon. Vous pouvez tout de même activer les fonctionnalités non trouvées ; ouvrez **Tout afficher** pour les voir. ### Désactiver une fonctionnalité supprime-t-il ses valeurs du .env ? Non. Les processus, les tâches cron et les directives Nginx sont supprimés, mais les valeurs définies par la fonctionnalité dans le `.env` restent. Modifiez-les sur la page [environnement](https://ops.vimonto.com/docs/fr/sites/environment) si vous n'en avez plus besoin. ### Pourquoi une fonctionnalité n'est-elle pas disponible ? La fenêtre indique pourquoi, par exemple **Il n'y a pas de Redis sur ce serveur.**, **Ce serveur n'a pas Node.js.**, ou le fait que le site a sa propre configuration Nginx sans l'include des directives supplémentaires. ### Puis-je modifier moi-même le processus d'une fonctionnalité ? Pas directement. Les processus et tâches cron créés par une fonctionnalité ne sont modifiés et supprimés que via la fonctionnalité, pour qu'ils correspondent toujours à ses réglages. Ajoutez vos propres [queue workers](https://ops.vimonto.com/docs/fr/sites/queues-and-scheduler) ou [processus serveur](https://ops.vimonto.com/docs/fr/servers/processes) pour tout le reste.