Quando arriva un ticket di assistenza urgente, l’istinto è quello di intervenire e risolvere il problema il più velocemente possibile. Su un sito WordPress attivo, però, una reazione immediata di questo tipo può ritorcertisi contro.
Un aggiornamento fallito del plugin, una rapida modifica della configurazione o un cambiamento affrettato del database possono portare un sito da “parzialmente rotto” a completamente offline. Senza un backup recente, non c’è modo di tornare indietro.
In questa guida scoprirai come automatizzare questo passaggio. Collegando Zendesk all’API di Kinsta, ogni ticket urgente su WordPress può attivare automaticamente un backup, prima ancora che un tecnico lo apra. Il risultato è un processo di risposta agli incidenti più sicuro e coerente, con un punto di ripristino già pronto.
Perché le agenzie dovrebbero fare un backup prima di riparare qualsiasi cosa
Un conflitto di plugin, una query di database fallita o un aggiornamento incompleto su un sito WordPress live senza un backup è difficile da recuperare. Qualsiasi modifica apportata prima della creazione di un backup comporta l’impossibilità di avere un punto di ritorno pulito se qualcosa va storto.
Gestire più siti di clienti significa affidarsi a chi prende in carico il ticket per creare un backup prima di iniziare. È proprio quando ci si affida a questa procedura manuale che le cose vanno a rotoli.
Per Pixeled Eggs la posta in gioco è molto alta perché i suoi clienti servono persone in crisi. Chi cerca un supporto per la salute mentale o un’assistenza di emergenza si aspetta che il sito venga caricato, quindi un tentativo di ripristino fallito è una catastrofe.
La soluzione semplice e il tempo che abbiamo risparmiato nel nostro team di sviluppo hanno rappresentato un notevole ritorno sull’investimento. Questo ci permette di concentrarci su ciò che sappiamo fare meglio, ovvero progettare e sviluppare siti WordPress altamente performanti per clienti con obiettivi ben definiti.
Cosa serve prima di iniziare
Questo tutorial richiede:
- Un account Kinsta con almeno un sito WordPress in un ambiente live.
- Un account Zendesk con un piano Suite Team o superiore (o un piano Support Team, Professional o Enterprise). I Webhook e i Trigger sono disponibili in tutti questi livelli.
- Accesso amministratore a Zendesk per creare webhook e Trigger.
- Node.js installato localmente.
Per autenticarti con l’API di Kinsta, vai su [La tua azienda] > Impostazioni azienda > Chiavi API in MyKinsta e clicca su Crea chiave API.
A questo punto, dai un nome alla chiave, imposta una scadenza e clicca su Genera. A questo punto la chiave viene visualizzata solo una volta, quindi copiala prima di chiudere il pannello. Ti serve anche un ID del sito. Questo viene visualizzato nell’URL di MyKinsta quando apri un sito, oppure puoi eseguire un poll GET /sites una volta inserita la chiave.
In ogni caso, aggiungi la chiave API a un file .env nella root del progetto:
KINSTA_API_KEY=your_api_key_hereNota che l’ID del sito e l’ID dell’ambiente sono due cose diverse: l’agente inserisce l’ID del sito e il middleware chiama GET /sites/{siteId}/environments per recuperare l’ID dell’ambiente. Inoltre, il livello di accesso di una chiave API corrisponde al ruolo che l’ha creata: le chiavi degli sviluppatori hanno permessi più ristretti rispetto a quelle dei proprietari o degli amministratori. Se una richiesta restituisce un errore di autorizzazione, questa è la prima cosa da verificare.
Altri prerequisiti per lo sviluppo
Per lo sviluppo locale, il middleware viene eseguito su localhost, che Zendesk non può raggiungere direttamente. L’utilizzo di uno strumento di tunneling come ngrok espone una porta locale a internet con un URL pubblico temporaneo, che puoi utilizzare come endpoint del webhook durante lo sviluppo. Una volta che l’integrazione funziona end-to-end a livello locale, sostituisci l’URL con l’indirizzo del middleware distribuito.
Hai anche bisogno di un campo ticket personalizzato in Zendesk per trasferire l’ID del sito Kinsta da un ticket al payload del webhook. Nel menu delle opzioni di Zendesk sul lato destro dello schermo, vai su Objects and rules > Tickets > Fields e crea un nuovo campo di testo.
Quindi, dagli un nome riconoscibile e prendi nota dell’ID numerico del campo che Zendesk gli assegna. Quando un agente apre un ticket per un problema con WordPress, popola questo campo con l’ID del sito interessato.
Come integrare Zendesk con Kinsta utilizzando l’API di Kinsta
Per avviare un backup basato sulla ricezione di un ticket di assistenza pertinente, il middleware Node.js riceve le chiamate webhook di Zendesk. Da lì, risolve l’ID di un sito Kinsta in un ID ambiente, quindi attiva un backup manuale con tag.
Il lato Zendesk è composto da due oggetti: un webhook che punta all’endpoint del middleware e un Trigger che si attiva quando arriva un ticket adatto.
1. Creare il webhook di Zendesk
In Zendesk, un webhook e un Trigger sono due oggetti separati. Prima crei il webhook, poi lo colleghi al Trigger come azione e non viceversa. Inoltre, non puoi cambiare il metodo di connessione di un webhook dopo la sua creazione, quindi l’ordine è importante.
Per creare il webhook, apri le opzioni di Zendesk e vai su Apps and integrations > Webhooks > Webhooks, quindi clicca su Create webhook.
Per il metodo di connessione, scegli Trigger or automation. Clicca su Next e inserisci un nome. Per l’URL dell’endpoint, inserisci un segnaposto per il momento, in quanto lo aggiornerai una volta che il middleware sarà distribuito. Devi aggiungere /backup a questo URL, impostare il metodo di richiesta su POST e il formato della richiesta su JSON.
Per quanto riguarda il metodo di autenticazione, Bearer token è una scelta pratica in quanto aggiungi un controllo che convalida la richiesta in arrivo quando configuri il middleware. Zendesk include anche un signature header (x-zendesk-webhook-signature) che puoi utilizzare per verificare le richieste. Una volta creato il webhook, Zendesk lo elenca nel pannello webhooks finché non lo colleghi a un Trigger.
2. Configurare il Trigger di Zendesk
Una volta creato il webhook, vai su Objects and rules > Business rules > Trigger e clicca su Create trigger.
Dai un nome al trigger, poi nella sezione Conditions imposta che si attivi quando il ticket viene creato, la priorità è Urgent, il campo personalizzato è presente e i tag contengono wordpress-emergency. Questa combinazione fa sì che l’attivazione avvenga solo sui nuovi ticket che un agente di assistenza ha esplicitamente contrassegnato come incidente attivo su WordPress.
Successivamente, clicca su Actions > Add action, seleziona Notify by > Active webhook e scegli il tuo webhook. In questo modo si apre l’editor del payload della richiesta, in cui si definisce ciò che Zendesk invia al middleware. Il payload è JSON standard e Zendesk supporta la sintassi dei segnaposto per iniettare i dati del ticket quando il webhook viene attivato.
Il formato del campo personalizzato è {{ticket.custom_fields.FIELD_ID}}, dove FIELD_ID è l’ID numerico del campo personalizzato creato nei prerequisiti:
{
"ticket_id": "{{ticket.id}}",
"site_id": "{{ticket.custom_fields.12345678}}" // Replace the numeric placeholder with the Zendesk field ID value.
}Definendo questo valore, Zendesk passa automaticamente l’ID del sito Kinsta dal ticket al middleware.
3. Creare l’endpoint del middleware
Il middleware è ciò che permette a Zendesk e all’API di Kinsta di parlare tra loro. Express.js è un framework web Node.js minimale che gestisce il routing, analizza i corpi delle richieste e permette di definire l’endpoint POST /backup che Zendesk chiama. Una volta inizializzata una nuova cartella di progetto, installa entrambe le dipendenze:
npm init -y
npm install express dotenvIn questo caso, express fornisce il server e il livello di routing; dotenv carica il file .env in modo che la chiave API sia disponibile in fase di esecuzione senza apparire nel codice sorgente.
Creare un file app.js significa che il server avvia Express, analizza il JSON in arrivo e definisce un percorso POST /backup che riceve il payload di Zendesk:
// app.js
const express = require('express');
require('dotenv').config();
const app = express();
app.use(express.json());
const KinstaAPIUrl = 'https://api.kinsta.com/v2';
const headers = {
'Content-Type': 'application/json',
Authorization: `Bearer ${process.env.KINSTA_API_KEY}`
};
app.post('/backup', async (req, res) => {
const { ticket_id, site_id } = req.body;
if (!site_id) {
return res.status(400).json({ message: 'Missing site ID' });
}
// Kinsta API calls placeholder
res.status(200).json({ message: 'Received' });
});
app.listen(3000, () => console.log('Server running on port 3000'));Per l’uso in produzione, verifica anche che la richiesta provenga da Zendesk. Include gli header x-zendesk-webhook-signature e x-zendesk-webhook-signature-timestamp ad ogni invocazione, che puoi utilizzare per convalidare il payload rispetto al tuo webhook.
4. Autenticazione con l’API di Kinsta
Tutte le richieste all’API di Kinsta utilizzano l’autenticazione con token Bearer: L’headerAuthorization contiene la tua chiave API e la costante headers definita in app.js la gestisce per ogni richiesta nell’applicazione.
La riga require('dotenv').config() all’inizio del file carica .env prima che qualsiasi altra cosa venga eseguita, quindi process.env.KINSTA_API_KEY si risolve nella tua chiave effettiva in fase di esecuzione. La chiave non appare mai nel codice sorgente.
Il prossimo elemento di cui il middleware ha bisogno è l’ID dell’ambiente per il sito, che coinvolge l’endpoint backup di Kinsta. Per farlo, aggiungi una funzione sotto la costante headers:
const getEnvironmentId = async (siteId) => {
const resp = await fetch(
`${KinstaAPIUrl}/sites/${siteId}/environments`,
{ method: 'GET', headers }
);
const data = await resp.json();
return data.site.environments[0].id;
};Questa funzione chiama GET /sites/{siteId}/environments e restituisce l’ID del primo ambiente nella risposta, che corrisponde all’ambiente live. Se i tuoi siti utilizzano più ambienti e hai bisogno di selezionarne uno specifico, puoi effettuare una corrispondenza con il nome dell’ambiente anziché prendere il primo risultato.
5. Attivare il backup attraverso l’API di Kinsta
Per creare il backup, il middleware chiama POST /sites/environments/{envId}/manual-backups, utilizzando un’altra funzione extra sotto getEnvironmentId:
const triggerBackup = async (envId, tag) => {
const resp = await fetch(
`${KinstaAPIUrl}/sites/environments/${envId}/manual-backups`,
{
method: 'POST',
headers,
body: JSON.stringify({ tag })
}
);
const data = await resp.json();
return data;
};Il parametro tag etichetta il backup, rendendolo facilmente identificabile in MyKinsta. L’utilizzo dell’ID del ticket Zendesk nel tag significa che chiunque esamini l’elenco dei backup può risalire all’incidente che li ha generati.
Infine, aggiorna il percorso POST /backup per chiamare entrambe le funzioni in sequenza:
app.post('/backup', async (req, res) => {
const { ticket_id, site_id } = req.body;
if (!site_id) {
return res.status(400).json({ message: 'Missing site ID' });
}
try {
const envId = await getEnvironmentId(site_id);
const tag = `pre-remediation-${ticket_id || 'manual'}`;
const result = await triggerBackup(envId, tag);
res.status(200).json(result);
} catch (err) {
console.error(err);
res.status(500).json({ message: 'Backup failed' });
}
});Una richiesta andata a buon fine all’endpoint di backup restituisce uno stato 202 con un corpo di risposta che conferma che l’operazione è in corso:
{
"operation_id": "backups:add-manual-abc123",
"message": "Adding a manual backup to environment in progress.",
"status": 202
}Tuttavia, la risposta 202 non è una conferma del completamento del backup. I backup manuali sono asincroni, quindi devi interrogare l’endpoint GET /operations/{operation_id} fino a quando lo stato non viene restituito come completato. Per la maggior parte dei flussi di lavoro, la risposta 202 è sufficiente per aprire un ticket.
Una volta eseguito node app.js e inviata una richiesta di prova con un ID sito e un ID ticket validi nel corpo, verifica che il backup venga visualizzato in MyKinsta con il tag corretto.
Kinsta può aiutarti a proteggere i siti dei clienti nel momento in cui qualcosa va storto
Grazie a questa integrazione, i ticket di assistenza WordPress urgenti in Zendesk attivano un backup immediato. Il middleware chiama l’API di Kinsta per creare un’istantanea con tag prima che un tecnico apra il ticket.
Per lo sviluppo locale, ngrok gestisce la connessione tra Zendesk e localhost. Quando sarà il momento di spostare il middleware su un endpoint permanente, Sevalla può rivelarsi la soluzione perfetta. Devi eseguire il push del progetto su un provider Git, collegare il repo, aggiungere la tua variabile d’ambiente nelle impostazioni di distribuzione e aggiornare l’URL dell’endpoint webhook in Zendesk per puntare all’indirizzo live.
Se gestisci siti di clienti in scala, l’add-on per gli aggiornamenti automatici di Kinsta si abbina naturalmente a questo flusso di lavoro. In questo modo si mantengono aggiornati i plugin e i temi, si eseguono test visivi automatizzati dopo ogni aggiornamento e si annulla la modifica se qualcosa si rompe. Inoltre, puoi impostare un calendario personalizzato per ogni sito.
Se hai domande, contatta il team di supporto in qualsiasi momento.
