La gestione di un singolo sito WordPress richiede tempo. Per le agenzie che gestiscono decine o addirittura centinaia di siti, attività come la creazione di ambienti, la cancellazione delle cache, l’aggiunta di domini o il ripristino dei backup possono sommarsi l’un l’altro rapidamente. Il lavoro del team rallenta a causa della ripetizione del ciclo per ogni sito.
E questo è lo schema tipico di molti:
- Un nuovo cliente è stato preso in carico → uno sviluppatore configura WordPress manualmente, aggiunge domini e configura i plugin.
- Qualcuno invia un deploy → il team deve accedere e cancellare le cache a mano
- Un cliente segnala un bug → il team addetto al malware controlla i log manualmente e forse il sito viene ripristinato tramite backup
Nessuno di questi compiti è difficile, ma il fatto di svolgerli ripetutamente fa perdere del tempo che dovrebbe essere investito in attività più importanti.
Ecco perché Kinsta non offre solo una dashboard pulita e intuitiva. Le agenzie possono automatizzare le attività di routine anche grazie all’API di Kinsta.
Scopriamo alcune attività di gestione di WordPress che possono essere automatizzate con l’API di Kinsta.
Creare e clonare siti WordPress
L’installazione di un nuovo sito WordPress è probabilmente il task più frequente di un team. All’inizio della gestione dell’agenzia, probabilmente non sembrerà un grosso problema, dato che si potrebbero creare solo 5-10 siti a settimana. Ma man mano che l’agenzia cresce, le cose cambiano. Si presentano occasioni come il Black Friday o il lancio di un cliente importante che richiede il rilascio di decine di siti in pochi giorni.
A quel punto, farlo manualmente non è più possibile. O si rallenta l’attività, si assumono e formano altre persone (il che costa tempo e denaro) o si decide di automatizzare.
L’API di Kinsta puù essere collegata ai tool interni dell’agenzia o alla sua dashboard in modo che, per creare un sito WordPress, possa bastare il clic su un pulsante.
Supponiamo che qualcuno si iscriva al sito dell’agenzia e paghi. Si potrebbe avere uno script che prende i risultati del modulo di iscrizione e chiama l’API per creare un nuovo sito WordPress con il tema predefinito.
Questa non è teoria. L’API ha già tutto ciò che serve:
POST /sites– Crea un nuovo sito WordPressPOST /sites/clone– Clona un ambiente esistenteGET /operations/{operation_id}– Traccia lo stato di creazione di un sitoGET /sites– Elenca tutti i siti (utile per le dashboard)
Se si gestiscono molti siti, questo permetterà di risparmiare ore di lavoro ogni settimana.
Gestire i domini in modo programmatico
Questo non è un problema se si gestiscono siti di clienti su larga scala.
Le agenzie aggiungono o cambiano regolarmente i domini, magari durante l’onboarding o un rebrand completo. Le agenzie di grandi dimensioni potrebbero ridurre il tempo necessario a cliccare su MyKinsta per aggiungere domini, verificare i DNS e impostare l’SSL.
Con l’API di Kinsta, possiamo spostare tutto questo in un workflow automatizzato.
Ecco uno scenario frequente nel mondo reale: Un nuovo cliente si iscrive. Il nome del dominio e il DNS sono già impostati nel CRM. Il sistema interno verifica che i record DNS puntino a Kinsta (magari utilizzando una ricerca DNS dietro le quinte) e, nel momento in cui questo viene confermato, chiama l’API per:
- Collegare il dominio
- Impostare il dominio come dominio primario
- Caricare un SSL personalizzato, se necessario
Si potrebbe anche creare una notifica su Slack che dice “✅ il dominio client.com è stato collegato e l’SSL è attivo”.
Un altro scenario: Supponiamo di essere impegnati nel rebranding di 20 siti di clienti in blocco. Per aggiornare ogni ambiente con i nuovi domini, passarli e applicare automaticamente l’SSL, invece di aggiornare ogni sito a mano, è possibile mettere in coda tutte le modifiche ai domini e fare un loop attraverso l’API.
Alcuni degli endpoint utili per questa operazione sono i seguenti:
POST /sites/environments/{environment_id}/domains– Aggiungi un dominioPUT /sites/environments/{environment_id}/change-primary-domain– Cambia il dominio primarioDELETE /sites/environments/{environment_id}/domains– Rimuovi domini
Non si tratta solo di una cosa carina da fare. Questo tipo di automazione fa risparmiare ore di lavoro ed elimina l’errore umano per le agenzie che svolgono questa attività da cinque a dieci volte a settimana.
Se vogliamo andare oltre, possiamo anche esporre questo controllo nella dashboard interna. Si fa clic su “Assegna dominio”, si sceglie il sito e il dominio e l’applicazione invocherà l’API di Kinsta.
Gestire i backup: elenco, ripristino o download
A volte può succedere che una distribuzione fallisca, i plugin si comportano male o un cliente può segnalare un problema sul sito in produzione. In MyKinsta sono già disponibili dei backup affidabili. Ma quando si gestiscono più siti e si ha bisogno di muoversi velocemente, è utile avere il controllo dei backup direttamente nel proprio workflow.
È qui che entra in gioco l’API. Le agenzie stanno inserendo questo sistema nelle loro pipeline di distribuzione in modo da…:
- creare un backup manuale appena prima della distribuzione,
- ripristinare automaticamente il sito se qualcosa va storto,
- non bisogna lasciare Slack o la dashboard dell’agenzia per eseguire il ripristino di un sito.
Ad esempio, è possibile impostare un comando Slack come:
/restore site-name to yesterdayQuesto richiama il servizio interno che attiva l’endpoint del ripristino. Oppure si immagini un pulsante “Ripristino rapido” con un solo clic nel proprio tool interno e l’API riporta il sito a uno stato stabile senza dover accedere a MyKinsta.
Ecco cosa è possibile fare con gli endpoint disponibili:
GET /sites/environments/{environment_id}/backups– Elenca i backup disponibili (giornalieri, manuali e di sistema)POST /sites/environments/{targetEnvId}/backups/restore– Ripristina un backupPOST /sites/environments/{environment_id}/manual-backups– Crea un backup manualeGET /sites/environments/{environment_id}/downloadable-backups– Scarica un backupDELETE /sites/environments/backups/{backup_id}– Elimina un backup
L’API offre al team dell’agenzia la possibilità di agire rapidamente, soprattutto nei momenti di alta pressione.
Aggiornamento in blocco di plugin e temi
Abbiamo scritto una guida che spiega come costruire un semplice strumento utilizzando l’API di Kinsta per controllare e aggiornare in blocco i plugin obsoleti su più siti WordPress da un’unica dashboard.
L’idea funziona ancora, anche se ora Kinsta offre aggiornamenti automatici di plugin e temi come add-on premium (che, tra l’altro, esegue anche test visivi e ripristino automatico).
Ma l’API offre al team dell’agenzia anche un altro tipo di controllo. È possibile mostrare tutti i plugin dei siti dei clienti in un’unica vista, evidenziare quelli obsoleti e lasciare che siano gli sviluppatori a scegliere quali aggiornare.
Magari si può lasciare che il team QA ne contrassegni alcuni da testare prima di inviare gli aggiornamenti alla produzione. È anche possibile ripulire il sito filtrando i plugin inattivi e rimuovendoli direttamente.
L’endpoint dei plugin restituisce dati come:
{
"name": "akismet",
"title": "Akismet Anti-Spam",
"status": "active",
"version": "1.0.0",
"update": "available",
"update_version": "1.0.1"
}Con queste informazioni, è possibile generare qualsiasi logica:
- Mostrare il numero di plugin per sito
- Rilevare la versione
- Attivare aggiornamenti su più ambienti
- O anche creare un bot Slack che risponda con “questo sito ha 4 plugin obsoleti” e un pulsante per risolvere il problema.
Quindi, anche se il nuovo componente aggiuntivo risolve la gestione dei plugin per la maggior parte dei team, l’API offre un più alto livello di visibilità e di automazione personalizzata adatto ad ogni stile di lavoro.
Cancellare la cache, riavviare PHP, inviare alla versione live
Gli endpoint clear cache e restart PHP sono tra i più utilizzati dell’API di Kinsta ed è facile capire perché.
Subito dopo il deploy, la cancellazione delle cache è l’operazione più comune. Lo stesso vale per il riavvio di PHP quando le cose non vanno bene. Non si tratta di operazioni “fantasiose”. Sono solo il tipo di operazioni che il team svolge più spesso. Quindi sono anche il tipo di operazioni che dovrebbero essere automatizzate.
Se il team utilizza già Git su SSH per effettuare il deploy su Kinsta, è possibile integrare queste chiamate API direttamente nella pipeline CI, magari attraverso GitHub Actions. Senza che un utente acceda a MyKinsta, tutto si ripristina con un singolo push pulito.
Ecco un esempio di pipeline:
name: Deploy to Kinsta and clear cache
on:
push:
branches:
- main
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Deploy through SSH
uses: appleboy/[email protected]
with:
host: ${{ secrets.KINSTA_SERVER_IP }}
username: ${{ secrets.KINSTA_USERNAME }}
password: ${{ secrets.KINSTA_PASSWORD }}
port: ${{ secrets.KINSTA_PORT }}
script: |
cd /www/your-site/public
git fetch origin main
git reset --hard origin/main
- name: Clear Kinsta cache
run: |
curl -X POST https://api.kinsta.com/v2/environments/${{ secrets.KINSTA_ENV_ID }}/tools/clear-cache \
-H "Authorization: Bearer ${{ secrets.KINSTA_API_KEY }}" \
-H "Content-Type: application/json"
- name: Restart PHP
run: |
curl -X POST https://api.kinsta.com/v2/environments/${{ secrets.KINSTA_ENV_ID }}/tools/restart-php \
-H "Authorization: Bearer ${{ secrets.KINSTA_API_KEY }}" \
-H "Content-Type: application/json"È semplice, ma potente. E si può andare anche oltre. Possiamo:
- Aggiungere un pulsante “Cancella cache” al pannello di amministrazione interno.
- Attivare la cancellazione della cache tramite Slack, utilizzando un comando bot del tipo
/cache-clear client-name - Includere la cancellazione della cache e il riavvio di PHP nel flusso di distribuzione staging-to-live.
Se si usa l’endpoint Push to Live, le cose si fanno ancora più interessanti. Non è necessario inviare tutto, perché l’API supporta l’invio selettivo di file tramite push_files_option: 'SPECIFIC_FILES'.
In questo modo è possibile personalizzare i deploy per inviare solo le modifiche ai plugin o ai temi:
{
"source_env_id": "54fb80af-576c-4fdc-ba4f-b596c83f15a1",
"target_env_id": "54fb80af-576c-4fdc-ba4f-b596c83f15a1",
"push_db": true,
"push_files": true,
"run_search_and_replace": true,
"push_files_option": "SPECIFIC_FILES",
"file_list": [
"wp-content/plugins",
"wp-content/themes",
"wp-content/uploads"
]
}Questo è il genere di cose che fa respirare meglio gli sviluppatori dell’agenzia e rende le cose più veloci per i clienti.
Accedere ai log per il monitoraggio o il debug
Il team di un’agenzia gestisce molti siti di clienti. Si sa già che quando un cliente dice: “Il sito non funziona”, di solito è già guasto da un po’.
È qui che entra in gioco l’endpoint dei log. Invece di aspettare i reclami dei clienti, si possono prelevare i log direttamente tramite l’API e visualizzarli nella dashboard interna. Ancora meglio, è possibile impostare un semplice sistema di alert che avvisi il team su Slack o via e-mail quando qualcosa non funziona.
Non c’è bisogno di aprire MyKinsta ogni volta che qualcuno segnala un errore 500. Basta recuperare gli ultimi log di errore o di accesso, analizzare l’output e visualizzare i risultati dove il team già lavora.
Si ha solo bisogno dell’ID dell’ambiente e del tipo di log che si desidera, ad esempio error, access o kinsta-cache-perf. Si può anche limitare il numero di righe restituite:
curl -i -X GET \
'https://api.kinsta.com/v2/sites/environments/{env_id}/logs?file_name=error&lines=1000' \
-H 'Authorization: Bearer 'In questo modo si ottiene una semplice stringa del contenuto del registro. Da qui, è possibile costruire ciò che più si adatta al proprio flusso di lavoro:
- Mostrare i log degli errori più recenti per ogni sito cliente nella dashboard dell’agenzia.
- Evidenziare gli errori 500, le query lente o i cron job falliti.
- Attivare avvisi quando si verificano picchi di errori.
- Permettere agli sviluppatori di digitare
/show-logs client-xin Slack e di visualizzare immediatamente i risultati in tempo reale.
Questo è il tipo di visibilità che evita i momenti “uh oh” durante le telefonate con i clienti.
Esempio reale: Sod utilizza l’API per gestire oltre 400 siti
Se le agenzie reali utilizzano l’API di Kinsta in questo modo? Sì, è così.
Prendiamo ad esempio Straight Out Digital (Sod), un’agenzia di Melbourne, Australia, che gestisce più di 400 siti WordPress. Quando la lista dei loro clienti è esplosa, non era più possibile fare le cose manualmente. Così hanno creato degli strumenti interni basati sull’API di Kinsta per automatizzare tutto, dal provisioning del sito agli aggiornamenti dei plugin.
Lo usano per:
- Creare nuovi siti in modo automatico in fase di inserimento dei clienti
- Clonare le configurazioni esistenti senza accedere alla dashboard
- Eseguire controlli e aggiornamenti in blocco dei plugin su tutto il loro portfolio
- Attivare avvisi quando vengono visualizzati errori nei registri
- Rimanere al passo con i problemi senza aspettare i ticket dei clienti
Utilizzano ancora MyKinsta quotidianamente, ma l’API li aiuta a evitare il lavoro ripetitivo. Nelle loro parole:
L’API di Kinsta ci ha permesso di sviluppare strumenti interni che automatizzano processi cruciali come il provisioning dei siti ed eseguono operazioni in blocco sui nostri siti web, facendoci risparmiare tempo e fatica”, afferma Pete Brundle, responsabile dello sviluppo di Sod.
Questa è la prova che questi workflow non sono teorici. Agenzie come Sod li stanno già utilizzando e l’azienda ha superato i 400 siti.
Riepilogo
Se si gestisce un’agenzia con più siti WordPress, l’API di Kinsta non è solo una cosa utile. È un modo per risparmiare tempo.
La si può inserire nella propria pipeline CI, utilizzarla per attivare azioni dai tool interni o semplicemente rendere la vita più facile agli sviluppatori dell’agenzia. È tutto pronto. Non bisogna ricostruire il processo da zero. Basta collegare le parti che rallentano maggiormente il team.
E come abbiamo visto con agenzie come Sod, i vantaggi aumentano man mano che si scala.
Dai un’occhiata alla documentazione dell’API di Kinsta per vedere cosa è possibile fare, genera la tua chiave API in MyKinsta e immergiti in tutorial passo-passo sulla creazione di bot Slack, sul deploy via Git e molto altro!
