# Funzionalità del sito: Horizon, Reverb, Pulse e WordPress > Attiva Laravel Horizon, Reverb, Pulse, Inertia SSR, Nightwatch, Symfony Messenger, cron e Redis per WordPress, modalità manutenzione o protezione con password. Le **funzionalità del sito** sono configurazioni pronte per gli strumenti che usa il tuo framework, come Laravel Horizon, Reverb o il cron di WordPress. Le attivi dal menu del framework nell'intestazione del sito, e Vimonto Deploy configura sul server tutto ciò di cui lo strumento ha bisogno: processi Supervisor, cron job, direttive Nginx e valori nel `.env`. Il menu, e il pulsante **Apri** accanto, compaiono quando la prima configurazione del sito è finita e la sua prima versione è online. La finestra di ogni funzionalità mostra esattamente cosa verrà configurato prima che tu la attivi, e le funzionalità vengono riavviate dopo ogni deploy quando serve. ![Il menu delle funzionalità Laravel nell'intestazione del sito con Horizon e lo scheduler attivi](https://ops.vimonto.com/docs-media/it/site-features-menu.webp?v=161e760d "Il menu del framework di un sito Laravel") ![Apertura del menu delle funzionalità e della finestra di una funzionalità](https://ops.vimonto.com/docs-media/it/site-features.mp4?v=161e760d) ## Aprire il menu delle funzionalità Il menu si trova nell'intestazione del sito e porta il nome del framework del sito, per esempio **Laravel** o **WordPress**. Si apre con le funzionalità del framework, come **Funzionalità Laravel**, con un punto verde per quelle attive e un conteggio come **2 di 7 attive**. A ogni deploy Vimonto Deploy legge i pacchetti nei tuoi `composer.json` e `package.json`. Le funzionalità il cui pacchetto è usato dalla tua app sono contrassegnate con **Nel tuo codice** ed elencate per prime, insieme alle funzionalità già attive; le altre sono sotto **Mostra tutto (altre … non trovate nel tuo codice)**. Fino al primo deploy vengono elencate tutte le funzionalità. ## Attivare o disattivare una funzionalità 1. Fai clic sulla funzionalità nel menu per aprirne la finestra. 2. Compila le sue impostazioni, se ne ha. 3. Controlla **Cosa configuriamo** e **Impostiamo nel tuo .env**. Le chiavi il cui valore cambia sono contrassegnate con **cambia**. 4. Fai clic su **Attiva**. L'attivazione avviene come task in background che puoi seguire nell'intestazione del sito. Se non riesce, la funzionalità mostra **Non riuscito** nel menu e ricevi una [notifica](https://ops.vimonto.com/docs/it/more/notifications); aprila e fai clic su **Salva** per riprovare, oppure su **Riprova** per una funzionalità senza impostazioni, come lo Scheduler o Pulse. Entrambi applicano di nuovo le stesse impostazioni. Per modificare le impostazioni di una funzionalità attiva, aprila, modificale e fai clic su **Salva**. Per disattivarla, aprila e fai clic su **Disattiva**: i suoi processi, cron job e direttive Nginx vengono rimossi. I valori che ha impostato nel `.env` restano. Le funzionalità richiedono un sito configurato e, per la maggior parte, già con un deploy: i loro comandi girano nella release attiva. Le funzionalità con direttive Nginx richiedono la configurazione Nginx generata del sito, oppure una [configurazione personalizzata](https://ops.vimonto.com/docs/it/sites/nginx) che mantenga la riga include per le direttive aggiuntive. ## Quali funzionalità ci sono? | Funzionalità | Framework | Cosa configura | |---|---|---| | [Scheduler](#scheduler) | Laravel, Statamic | Cron: `schedule:run` ogni minuto | | [Horizon](#horizon) | Laravel, Statamic | Processo: `artisan horizon` | | [Reverb](#reverb) | Laravel, Statamic | Processo, Nginx, DNS, `.env` | | [Pulse](#pulse) | Laravel, Statamic | Processo: `artisan pulse:check` | | [Inertia SSR](#inertia-ssr) | Laravel, Statamic | Processo: `artisan inertia:start-ssr` | | [Nightwatch](#nightwatch) | Laravel, Statamic | Processo: `artisan nightwatch:agent`, `.env` | | [Worker di Messenger](#worker-di-messenger) | Symfony | Processi: `messenger:consume` | | [Cron reale](#cron-reale-per-wordpress) | WordPress | Cron: WP-CLI ogni minuto | | [Cache degli oggetti Redis](#cache-degli-oggetti-redis-per-wordpress) | WordPress | Plugin WordPress | | [Hardening](#hardening-per-wordpress) | WordPress | Regole Nginx, costante in `wp-config.php` | | [Modalità manutenzione](#modalità-manutenzione) | Laravel, Statamic, WordPress | `artisan down` o WP-CLI | | [Protezione con password](#protezione-con-password) | Tutti, compresi i siti con bilanciamento del carico | Autenticazione basic di Nginx | I processi girano sotto Supervisor con l'utente del sito e compaiono nella pagina [queue e scheduler](https://ops.vimonto.com/docs/it/sites/queues-and-scheduler) con un badge **Tramite …**. I cron job girano con l'utente del sito. ## Funzionalità Laravel ### Scheduler Esegue i tuoi comandi pianificati: una voce cron esegue `php artisan schedule:run` ogni minuto nella release attiva. È lo stesso interruttore di **Attiva** nella pagina [queue e scheduler](https://ops.vimonto.com/docs/it/sites/queues-and-scheduler#attivare-lo-scheduler-di-laravel). ### Horizon Esegue le tue queue Redis con [Laravel Horizon](https://laravel.com/docs/horizon): un programma Supervisor esegue `php artisan horizon`, che avvia tutti i worker descritti nel tuo `config/horizon.php`. - **Impostazione**: **Job più lungo (secondi)**, 3600 di default. A un deploy, i job in corso hanno questo tempo per terminare prima che il processo venga fermato. - **Dopo ogni deploy**: `php artisan horizon:terminate`, così Horizon completa i suoi job e Supervisor lo riavvia sul nuovo codice. - **.env**: `QUEUE_CONNECTION=redis`. - **Link**: la **Dashboard di Horizon** su `/horizon`. La finestra ti avvisa quando il sito ha anche queue worker propri (rimuovili, così i job non vengono presi in carico due volte) e quando il server non ha Redis (punta `REDIS_HOST` a un [server di cache](https://ops.vimonto.com/docs/it/servers/server-types)). ### Reverb Esegue [Laravel Reverb](https://laravel.com/docs/reverb), il server WebSocket per il broadcasting, su un proprio indirizzo WebSocket. - **Indirizzo WebSocket**: di default `ws.` più il dominio del sito, per esempio `ws.shop.example.com`. - **Porta locale**: la porta su cui Reverb è in ascolto, solo sul server stesso, da 8080 in su. Ogni app sul server ne ha bisogno di una propria. Quando la attivi, Vimonto Deploy: - esegue `php artisan reverb:start --host=127.0.0.1 --port=…` sotto Supervisor; - aggiunge l'indirizzo WebSocket ai nomi del sito e aggiunge regole Nginx che passano a Reverb `/app/` (connessioni WebSocket) e `/apps/` (l'API HTTP di Reverb); - crea il record DNS quando l'indirizzo è su `on-deploy.link`, oppure quando il dominio del sito è gestito da un'[integrazione DNS](https://ops.vimonto.com/docs/it/connections/integrations) collegata; un record lì che punta altrove e che Vimonto Deploy non ha creato non viene toccato, e il task lo dice. Altrimenti la finestra indica il record A da creare, che punta all'indirizzo IP del server; - richiede un nuovo certificato Let's Encrypt che include l'indirizzo WebSocket quando il sito ne ha già uno e il nome punta al server. Altrimenti richiedi un nuovo certificato in [domini e SSL](https://ops.vimonto.com/docs/it/sites/domains-and-ssl) quando il record DNS è pronto; - esegue `php artisan reverb:restart` dopo ogni deploy. Imposta queste chiavi nel `.env`, riutilizzando l'app ID, la key e il secret di Reverb se il tuo `.env` li contiene già, e generandoli altrimenti: ```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}" ``` Senza HTTPS sul sito, `REVERB_PORT` è `80` e `REVERB_SCHEME` è `http`. Dopo, fai di nuovo il deploy, così la build del frontend recepisce i valori `VITE_`. Quando Reverb è attivo, la finestra mostra l'**Indirizzo WebSocket** completo a cui si collegano i tuoi client. ### Pulse Mantiene in esecuzione `php artisan pulse:check`, così la dashboard di [Laravel Pulse](https://laravel.com/docs/pulse) mostra CPU, memoria e disco del server. Esegue `pulse:restart` dopo ogni deploy e rimanda alla **Dashboard di Pulse** su `/pulse`. ### Inertia SSR Esegue il rendering delle pagine Inertia sul server, per un primo caricamento più veloce e risultati migliori nei motori di ricerca. Esegue `php artisan inertia:start-ssr` sotto Supervisor e `inertia:stop-ssr` dopo ogni deploy, così il renderer lato server si riavvia sul nuovo bundle. - Genera il bundle SSR anche nel tuo [script di deploy](https://ops.vimonto.com/docs/it/sites/deployments#modifica-lo-script-di-deploy), per esempio `npm run build && npx vite build --ssr`. La finestra ti avvisa quando non vi trova `--ssr`. - Il server ha bisogno di Node.js (gli app server e i web server lo hanno). - Il server SSR è in ascolto sulla porta di Inertia, 13714, quindi può usarlo un solo sito per server. ### Nightwatch Mantiene in esecuzione l'agent di [Laravel Nightwatch](https://nightwatch.laravel.com) (`php artisan nightwatch:agent`), così la tua app invia i dati a Nightwatch. - **Impostazione**: **Token di Nightwatch**, dalla tua applicazione su nightwatch.laravel.com. In seguito lascialo vuoto per mantenere il token attuale. - **.env**: `NIGHTWATCH_TOKEN`, mostrato mascherato nella finestra. ## Funzionalità Symfony ### Worker di Messenger Esegue `bin/console messenger:consume` per i tuoi transport di [Symfony Messenger](https://symfony.com/doc/current/messenger.html), con `--time-limit=3600 --env=prod`. - **Transport**: separati da spazi, in ordine di priorità, per esempio `async scheduler_default`. Default: `async`. - **Processi**: quanti worker girano in parallelo (da 1 a 20). - **Dopo ogni deploy**: `messenger:stop-workers`, così Supervisor li riavvia sul nuovo codice. ## Funzionalità WordPress Le funzionalità WordPress usano [WP-CLI](https://wp-cli.org), che Vimonto Deploy installa sul server (come `/usr/local/bin/wp`) la prima volta che una funzionalità ne ha bisogno. ### Cron reale per WordPress Normalmente WordPress esegue i suoi task pianificati quando qualcuno visita una pagina, il che li salta sui siti poco visitati e rallenta quelli molto trafficati. **Cron reale** imposta `DISABLE_WP_CRON` in `wp-config.php` ed esegue invece `wp cron event run --due-now` ogni minuto da un vero cron job. Disattivandolo, la costante viene rimossa. ### Cache degli oggetti Redis per WordPress Installa e attiva il plugin [Redis Object Cache](https://wordpress.org/plugins/redis-cache/) e abilita la cache, così WordPress smette di porre al database le stesse domande a ogni richiesta. Richiede Redis sul server; la funzionalità non è disponibile sui server che non lo hanno. Disattivandola, la cache viene disabilitata e il plugin disattivato. ### Hardening per WordPress Chiude le porte da cui di solito arrivano gli attacchi a WordPress: - Nginx blocca `xmlrpc.php`; - Nginx si rifiuta di eseguire file PHP in `wp-content/uploads`; - `DISALLOW_FILE_EDIT` disattiva l'editor dei file di temi e plugin nella dashboard. ## Manutenzione e accesso ### Modalità manutenzione Mostra ai visitatori una pagina di manutenzione finché non la disattivi. Mentre è attiva, l'intestazione del sito mostra **Modalità manutenzione**; fai clic per aprire la finestra. - **Laravel e Statamic**: esegue `php artisan down` con un secret e `--retry=60`. La finestra mostra un **Link di bypass (imposta un cookie)** che ti permette di vedere il sito come al solito. Ogni volta che la attivi il secret è nuovo, quindi un vecchio link smette di funzionare. Lo stato è conservato in `storage/`, condiviso tra le release, quindi sopravvive ai deploy. - **WordPress**: esegue `wp maintenance-mode activate`. ### Protezione con password Chiede un nome utente e una password (autenticazione HTTP basic) prima che chiunque veda il sito: utile per i siti di staging e le anteprime sull'indirizzo `on-deploy.link`. - **Nome utente**: `preview` di default; lettere, numeri, `.`, `_` e `-`. - **Password**: almeno 8 caratteri. Viene salvato solo un hash bcrypt. In seguito lasciala vuota per mantenere la password attuale. Let's Encrypt può comunque raggiungere il sito per emettere e rinnovare i certificati mentre è protetto. Su un [sito con bilanciamento del carico](https://ops.vimonto.com/docs/it/sites/load-balancing), la protezione con password è l'unica funzionalità, e protegge in un colpo solo tutti gli app server dietro il load balancer. Per proteggere solo un percorso, come `/admin`, o dare a più persone un proprio accesso, usa invece le [regole di sicurezza](https://ops.vimonto.com/docs/it/sites/security-rules). Una regola di sicurezza per tutto il sito e la protezione con password non possono essere attive insieme. ## Domande frequenti ### Cosa significa "Nel tuo codice"? Il pacchetto della funzionalità è presente nel tuo `composer.json` o `package.json` all'ultimo deploy, per esempio `laravel/horizon` per Horizon. Puoi comunque attivare funzionalità non trovate; apri **Mostra tutto** per vederle. ### Disattivare una funzionalità rimuove i suoi valori dal .env? No. Processi, cron job e direttive Nginx vengono rimossi, ma i valori che la funzionalità ha impostato nel `.env` restano. Modificali nella pagina [ambiente](https://ops.vimonto.com/docs/it/sites/environment) se non ti servono più. ### Perché una funzionalità non è disponibile? La finestra spiega il motivo, per esempio **Su questo server non c'è Redis.**, **Questo server non ha Node.js.**, oppure che il sito ha una configurazione Nginx propria senza l'include per le direttive aggiuntive. ### Posso modificare io il processo di una funzionalità? Non direttamente. I processi e i cron job creati da una funzionalità si modificano e si rimuovono solo tramite la funzionalità, così corrispondono sempre alle sue impostazioni. Per tutto il resto aggiungi i tuoi [queue worker](https://ops.vimonto.com/docs/it/sites/queues-and-scheduler) o i tuoi [processi del server](https://ops.vimonto.com/docs/it/servers/processes).