Als je veel WordPress sites beheert, ben je waarschijnlijk altijd op zoek naar manieren om je werkprocessen te vereenvoudigen en te versnellen.

Stel je dit eens voor: met één commando in je terminal kun je handmatige backups voor al je sites activeren, zelfs als je er tientallen beheert. Dat is de kracht van het combineren van shellscripts met de Kinsta API.

Deze handleiding leert je hoe je shellscripts kunt gebruiken om aangepaste commando’s in te stellen die het beheren van je sites efficiënter maken.

Vereisten

Voordat we beginnen, hier is wat je nodig hebt:

  1. Een terminal: Alle moderne besturingssystemen worden geleverd met terminal software, dus je kunt meteen beginnen met scripts maken.
  2. Een IDE of tekstverwerker: Gebruik een tool waar je vertrouwd mee bent, of het nu VS Code, Sublime Text of zelfs een lichtgewicht editor zoals Nano is voor snelle terminalbewerkingen.
  3. Een Kinsta API-sleutel: Dit is essentieel voor interactie met de Kinsta API. Om de jouwe te genereren:
    • Log in op je MyKinsta dashboard.
    • Ga naar Je naam > Bedrijfsinstellingen > API-sleutels.
    • Klik op API-sleutel aanmaken en sla deze veilig op.
  4. curl en jq: Essentieel voor het maken van API-verzoeken en het verwerken van JSON-gegevens. Controleer of ze geïnstalleerd zijn, of installeer ze.
  5. Basiskennis van programmeren: Je hoeft geen expert te zijn, maar kennis van de basis van programmeren en shell scripting syntaxis kan helpen.

Je eerste script schrijven

Het maken van je eerste shellscript voor interactie met de Kinsta API is eenvoudiger dan je zou denken. Laten we beginnen met een eenvoudig script dat een lijst maakt van alle WordPress sites die worden beheerd onder je Kinsta account.

Stap 1: Stel je omgeving in

Begin met het maken van een map voor je project en een nieuw scriptbestand. De extensie .sh wordt gebruikt voor shellscripts. Je kunt bijvoorbeeld een map maken, ernaar navigeren en een scriptbestand maken en openen in VS Code met deze commando’s:

mkdir my-first-shell-scripts
cd my-first-shell-scripts
touch script.sh
code script.sh

Stap 2: Definieer je omgevingsvariabelen

Om je API-sleutel veilig te houden, sla je hem op in een .env bestand in plaats van hem te hardcoden in het script. Hierdoor kun je het bestand .env toevoegen aan .gitignore en voorkomen dat het naar versiebeheer wordt gepushed.

Voeg in je .env bestand toe:

API_KEY=your_kinsta_api_key

Pull vervolgens de API-sleutel uit het .env bestand naar je script door het volgende toe te voegen bovenaan je script:

#!/bin/bash
source .env

De #!/bin/bash shebang zorgt ervoor dat het script draait met Bash, terwijl source .env de omgevingsvariabelen importeert.

Stap 3: Schrijf het API-verzoek

Sla eerst je bedrijfs-ID (te vinden in MyKinsta onder Bedrijfsinstellingen > Factureringsgegevens) op in een variabele:

COMPANY_ID="<your_company_id>"

Voeg vervolgens het curl commando toe om een GET verzoek te doen naar het /sites endpoint, waarbij je de bedrijfs-ID doorgeeft als een query parameter. Gebruik jq om de uitvoer leesbaar op te maken:

curl -s -X GET 
  "https://api.kinsta.com/v2/sites?company=$COMPANY_ID" 
  -H "Authorization: Bearer $API_KEY" 
  -H "Content-Type: application/json" | jq

Met dit verzoek worden details opgehaald over alle sites die aan je bedrijf zijn gekoppeld, inclusief hun ID’s, namen en statussen.

Stap 4: Maak het script uitvoerbaar

Sla het script op en maak het uitvoerbaar door het volgende uit te voeren:

chmod +x script.sh

Stap 5: Voer het script uit

Voer het script uit om een opgemaakte lijst van je sites te zien:

./list_sites.sh

Als je het script uitvoert, krijg je een antwoord dat hierop lijkt:

{
  "company": {
    "sites": [
      {
        "id": "a8f39e7e-d9cf-4bb4-9006-ddeda7d8b3af",
        "name": "bitbuckettest",
        "display_name": "bitbucket-test",
        "status": "live",
        "site_labels": []
      },
      {
        "id": "277b92f8-4014-45f7-a4d6-caba8f9f153f",
        "name": "duketest",
        "display_name": "zivas Signature",
        "status": "live",
        "site_labels": []
      }
    ]
  }
}

Dit werkt, maar laten we het verbeteren door een functie in te stellen om de sitegegevens op te halen en te formatteren voor een betere leesbaarheid.

Stap 6: Refactor met een functie

Vervang het curl verzoek door een herbruikbare functie voor het ophalen en opmaken van de sitelijst:

list_sites() {
  echo "Fetching all sites for company ID: $COMPANY_ID..."
  
  RESPONSE=$(curl -s -X GET "https://api.kinsta.com/v2/sites?company=$COMPANY_ID" 
    -H "Authorization: Bearer $API_KEY" 
    -H "Content-Type: application/json")

  # Check for errors
  if [ -z "$RESPONSE" ]; then
    echo "Error: No response from the API."
    exit 1
  fi

  echo "Company Sites:"
  echo "--------------"
  echo "$RESPONSE" | jq -r '.company.sites[] | "(.display_name) ((.name)) - Status: (.status)"'
}

# Run the function
list_sites

Als je het script opnieuw uitvoert, krijg je netjes opgemaakte uitvoer:

Fetching all sites for company ID: b383b4c-****-****-a47f-83999c5d2...
Company Sites:
--------------
bitbucket-test (bitbuckettest) - Status: live
zivas Signature (duketest) - Status: live

Met dit script heb je de eerste stap gezet naar het gebruik van shell scripts en de Kinsta API voor het automatiseren van WordPress sitebeheer. In de volgende secties verkennen we het maken van meer geavanceerde scripts om op krachtige manieren te communiceren met de API.

Geavanceerd gebruik 1: Backups maken

Het maken van backups is een cruciaal aspect van websitebeheer. Hiermee kun je je site herstellen in geval van onvoorziene problemen. Met de Kinsta API en shellscripts kan dit proces worden geautomatiseerd, wat tijd en moeite bespaart.

In dit gedeelte maken we backups en gaan we in op Kinsta’s limiet van vijf handmatige backups per omgeving. Om dit aan te pakken, implementeren we een proces om:

  • Het huidige aantal handmatige backups te controleren.
  • De oudste backup identificeren en verwijderen (met bevestiging van de gebruiker) als de limiet is bereikt.
  • Doorgaan met het maken van een nieuwe backup.

Laten we de details bekijken.

De backup workflow

Om backups te maken met de Kinsta API gebruik je het volgende endpoint:

POST /sites/environments/{env_id}/manual-backups

Dit vereist:

  1. Omgeving ID: Identificeert de omgeving (zoals test of productie) waar de backup wordt gemaakt.
  2. Backup label: Een label om de backup te identificeren (optioneel).

Het handmatig achterhalen van de omgevings-ID en het uitvoeren van een commando als backup <environment ID> kan omslachtig zijn. In plaats daarvan maken we een gebruiksvriendelijk script waarbij je gewoon de sitenaam opgeeft en het script zal:

  1. De lijst met omgevingen voor de site ophalen.
  2. Je vragen om de omgeving te kiezen waarvan je een backup wilt maken.
  3. Het aanmaken van de backup afhandelen.

Herbruikbare functies voor schone code

Om ons script modulair en herbruikbaar te houden, definiëren we functies voor specifieke taken. Laten we de instellingen stap voor stap doorlopen.

1. Basisvariabelen instellen

Je kunt het eerste script dat je hebt gemaakt weglaten of hiervoor een nieuw scriptbestand maken. Begin met het declareren van de basis Kinsta API URL en je bedrijfs-ID in het script:

BASE_URL="https://api.kinsta.com/v2"
COMPANY_ID="<your_company_id>"

Met deze variabelen kun je API endpoints dynamisch door het script heen construeren.

2. Alle sites ophalen

Definieer een functie om de lijst van alle bedrijfslocaties op te halen. Zo kun je later details over elke site ophalen.

get_sites_list() {
  API_URL="$BASE_URL/sites?company=$COMPANY_ID"

  echo "Fetching all sites for company ID: $COMPANY_ID..."
  
  RESPONSE=$(curl -s -X GET "$API_URL" 
    -H "Authorization: Bearer $API_KEY" 
    -H "Content-Type: application/json")

  # Check for errors
  if [ -z "$RESPONSE" ]; then
    echo "Error: No response from the API."
    exit 1
  fi

  echo "$RESPONSE"
}

Je zult zien dat deze functie een ongeformatteerd antwoord van de API teruggeeft. Om een geformatteerd antwoord te krijgen. Je kunt een andere functie toevoegen om dat af te handelen (hoewel dat niet onze zorg is in deze sectie):

list_sites() {
  RESPONSE=$(get_sites_list)

  if [ -z "$RESPONSE" ]; then
    echo "Error: No response from the API while fetching sites."
    exit 1
  fi

  echo "Company Sites:"
  echo "--------------"
  # Clean the RESPONSE before passing it to jq
  CLEAN_RESPONSE=$(echo "$RESPONSE" | tr -d 'r' | sed 's/^[^{]*//') # Removes extra characters before the JSON starts

  echo "$CLEAN_RESPONSE" | jq -r '.company.sites[] | "(.display_name) ((.name)) - Status: (.status)"'
}

Als je de functie list_sites callt, worden je sites weergegeven zoals eerder getoond. Het belangrijkste doel is echter om toegang te krijgen tot elke site en zijn ID, zodat je gedetailleerde informatie over elke site kunt ophalen.

3. Sitegegevens ophalen

Om details over een specifieke site op te halen, gebruik je de volgende functie, die het ID van de site ophaalt op basis van de sitenaam en aanvullende details ophaalt, zoals omgevingen:

get_site_details_by_name() {
  SITE_NAME=$1
  if [ -z "$SITE_NAME" ]; then
    echo "Error: No site name provided. Usage: $0 details-name "
    return 1
  fi

  RESPONSE=$(get_sites_list)

  echo "Searching for site with name: $SITE_NAME..."

  # Clean the RESPONSE before parsing
  CLEAN_RESPONSE=$(echo "$RESPONSE" | tr -d 'r' | sed 's/^[^{]*//')

  # Extract the site ID for the given site name
  SITE_ID=$(echo "$CLEAN_RESPONSE" | jq -r --arg SITE_NAME "$SITE_NAME" '.company.sites[] | select(.name == $SITE_NAME) | .id')

  if [ -z "$SITE_ID" ]; then
    echo "Error: Site with name "$SITE_NAME" not found."
    return 1
  fi

  echo "Found site ID: $SITE_ID for site name: $SITE_NAME"

  # Fetch site details using the site ID
  API_URL="$BASE_URL/sites/$SITE_ID"

  SITE_RESPONSE=$(curl -s -X GET "$API_URL" 
    -H "Authorization: Bearer $API_KEY" 
    -H "Content-Type: application/json")

  echo "$SITE_RESPONSE"
}

De bovenstaande functie filtert de site op basis van de sitenaam en haalt vervolgens aanvullende details over de site op met behulp van het /sites/<site-id> endpoint. Deze details omvatten de omgevingen van de site, die we nodig hebben om backups te maken.

Backups maken

Nu je herbruikbare functies hebt ingesteld om sitegegevens op te halen en omgevingen op te sommen, kun je je richten op het automatiseren van het maken van backups. Het doel is om een eenvoudig commando uit te voeren met alleen de sitenaam en dan interactief de omgeving te kiezen waarvan je een backup wilt maken.

Begin met het maken van een functie (we noemen hem trigger_manual_backup). Binnen de functie definieer je twee variabelen: de eerste om de sitenaam als invoer te accepteren en de tweede om een standaard tag (default-backup) in te stellen voor de backup. Deze standaard tag wordt toegepast tenzij je later een aangepaste tag opgeeft.

trigger_manual_backup() {
  SITE_NAME=$1
  DEFAULT_TAG="default-backup"

  # Ensure a site name is provided
  if [ -z "$SITE_NAME" ]; then
    echo "Error: Site name is required."
    echo "Usage: $0 trigger-backup "
    return 1
  fi

  # Add the code here

}

Deze SITE_NAME is de identificatie voor de site die je wilt beheren. Je stelt ook een voorwaarde in zodat het script wordt afgesloten met een foutmelding als de identifier niet wordt opgegeven. Dit zorgt ervoor dat het script niet verder gaat zonder de benodigde invoer en voorkomt mogelijke API fouten.

Vervolgens gebruik je de herbruikbare get_site_details_by_name functie om gedetailleerde informatie over de site op te halen, inclusief de omgevingen. Het antwoord wordt vervolgens opgeschoond om onverwachte opmaakproblemen te verwijderen die zich tijdens het verwerken kunnen voordoen.

SITE_RESPONSE=$(get_site_details_by_name "$SITE_NAME")

if [ $? -ne 0 ]; then
  echo "Error: Failed to fetch site details for site "$SITE_NAME"."
  return 1
fi

CLEAN_RESPONSE=$(echo "$SITE_RESPONSE" | tr -d 'r' | sed 's/^[^{]*//')

Zodra we de gegevens van de site hebben, haalt het onderstaande script alle beschikbare omgevingen eruit en geeft ze weer in een leesbaar formaat. Dit helpt je te visualiseren welke omgevingen zijn gekoppeld aan de site.

Het script vraagt je vervolgens om een omgeving te selecteren op naam. Deze interactieve stap maakt het proces gebruiksvriendelijk doordat je geen ID’s van omgevingen hoeft te onthouden of in te voeren.

ENVIRONMENTS=$(echo "$CLEAN_RESPONSE" | jq -r '.site.environments[] | "(.name): (.id)"')

echo "Available Environments for "$SITE_NAME":"
echo "$ENVIRONMENTS"

read -p "Enter the environment name to back up (e.g., staging, live): " ENV_NAME

De geselecteerde omgevingsnaam wordt vervolgens gebruikt om de bijbehorende omgevings-ID op te zoeken in de sitegegevens. Deze ID is nodig voor API-verzoeken om een backup te maken.

ENV_ID=$(echo "$CLEAN_RESPONSE" | jq -r --arg ENV_NAME "$ENV_NAME" '.site.environments[] | select(.name == $ENV_NAME) | .id')

if [ -z "$ENV_ID" ]; then
  echo "Error: Environment "$ENV_NAME" not found for site "$SITE_NAME"."
  return 1
fi

echo "Found environment ID: $ENV_ID for environment name: $ENV_NAME"

In de bovenstaande code wordt een voorwaarde gemaakt zodat het script wordt afgesloten met een foutmelding als de opgegeven omgevingsnaam niet overeenkomt.

Nu je de omgevings-ID hebt, kun je doorgaan met het controleren van het huidige aantal handmatige backups voor de geselecteerde omgeving. Kinsta’s limiet van vijf handmatige backups per omgeving betekent dat deze stap cruciaal is om fouten te voorkomen.

Laten we beginnen met het ophalen van de lijst met backups met behulp van het /backups API endpoint.

API_URL="$BASE_URL/sites/environments/$ENV_ID/backups"
BACKUPS_RESPONSE=$(curl -s -X GET "$API_URL" 
  -H "Authorization: Bearer $API_KEY" 
  -H "Content-Type: application/json")

CLEAN_RESPONSE=$(echo "$BACKUPS_RESPONSE" | tr -d 'r' | sed 's/^[^{]*//')
MANUAL_BACKUPS=$(echo "$CLEAN_RESPONSE" | jq '[.environment.backups[] | select(.type == "manual")]')
BACKUP_COUNT=$(echo "$MANUAL_BACKUPS" | jq 'length')

Het script hierboven filtert vervolgens op handmatige backups en telt ze. Als het aantal de limiet bereikt, moeten we de bestaande backups beheren:

  if [ "$BACKUP_COUNT" -ge 5 ]; then
    echo "Manual backup limit reached (5 backups)."
    
    # Find the oldest backup
    OLDEST_BACKUP=$(echo "$MANUAL_BACKUPS" | jq -r 'sort_by(.created_at) | .[0]')
    OLDEST_BACKUP_NAME=$(echo "$OLDEST_BACKUP" | jq -r '.note')
    OLDEST_BACKUP_ID=$(echo "$OLDEST_BACKUP" | jq -r '.id')

    echo "The oldest manual backup is "$OLDEST_BACKUP_NAME"."
    read -p "Do you want to delete this backup to create a new one? (yes/no): " CONFIRM

    if [ "$CONFIRM" != "yes" ]; then
      echo "Aborting backup creation."
      return 1
    fi

    # Delete the oldest backup
    DELETE_URL="$BASE_URL/sites/environments/backups/$OLDEST_BACKUP_ID"
    DELETE_RESPONSE=$(curl -s -X DELETE "$DELETE_URL" 
      -H "Authorization: Bearer $API_KEY" 
      -H "Content-Type: application/json")

    echo "Delete Response:"
    echo "$DELETE_RESPONSE" | jq -r '[
      "Operation ID: (.operation_id)",
      "Message: (.message)",
      "Status: (.status)"
    ] | join("n")'
  fi

De bovenstaande voorwaarde identificeert de oudste backup door de lijst te sorteren op basis van het created_at tijdstempel. Vervolgens wordt gevraagd of je deze wilt verwijderen.

Als je akkoord gaat, verwijdert het script de oudste backup met zijn ID, zodat er ruimte vrijkomt voor de nieuwe. Dit zorgt ervoor dat er altijd backups kunnen worden gemaakt zonder dat de limieten handmatig moeten worden beheerd.

Nu er ruimte is, gaan we verder met de code om de backup voor de omgeving te activeren. Je kunt deze code gerust overslaan, maar voor een betere ervaring wordt je gevraagd om een custom tag op te geven, die standaard op “default-backup” wordt gezet als er geen is opgegeven.

read -p "Enter a backup tag (or press Enter to use "$DEFAULT_TAG"): " BACKUP_TAG

if [ -z "$BACKUP_TAG" ]; then
  BACKUP_TAG="$DEFAULT_TAG"
fi

echo "Using backup tag: $BACKUP_TAG"

Tenslotte is het script hieronder waar de backup actie plaatsvindt. Het stuurt een POST verzoek naar het /manual-backups endpoint met de geselecteerde omgevings-ID en backup tag. Als het verzoek succesvol is, stuurt de API een antwoord terug waarin de aanmaak van de backup wordt bevestigd.

API_URL="$BASE_URL/sites/environments/$ENV_ID/manual-backups"
RESPONSE=$(curl -s -X POST "$API_URL" 
  -H "Authorization: Bearer $API_KEY" 
  -H "Content-Type: application/json" 
  -d "{"tag": "$BACKUP_TAG"}")

if [ -z "$RESPONSE" ]; then
  echo "Error: No response from the API while triggering the manual backup."
  return 1
fi

echo "Backup Trigger Response:"
echo "$RESPONSE" | jq -r '[
  "Operation ID: (.operation_id)",
  "Message: (.message)",
  "Status: (.status)"
] | join("n")'

Dat is het! Het antwoord dat wordt verkregen uit het bovenstaande verzoek is geformatteerd om de ID van de bewerking, het bericht en de status voor de duidelijkheid weer te geven. Als je de functie callt en het script uitvoert, zie je een uitvoer die hierop lijkt:

Available Environments for "example-site":
staging: 12345
live: 67890
Enter the environment name to back up (e.g., staging, live): live
Found environment ID: 67890 for environment name: live
Manual backup limit reached (5 backups).
The oldest manual backup is "staging-backup-2023-12-31".
Do you want to delete this backup to create a new one? (yes/no): yes
Oldest backup deleted.
Enter a backup tag (or press Enter to use "default-backup"): weekly-live-backup
Using backup tag: weekly-live-backup
Triggering manual backup for environment ID: 67890 with tag: weekly-live-backup...
Backup Trigger Response:
Operation ID: backups:add-manual-abc123
Message: Adding a manual backup to environment in progress.
Status: 202

Commando’s maken voor je script

Commando’s vereenvoudigen het gebruik van je script. In plaats van het script te bewerken of handmatig code te verwijderen, kunnen gebruikers het uitvoeren met een specifiek commando zoals:

./script.sh list-sites
./script.sh backup

Neem aan het einde van je script (buiten alle functies) een voorwaardelijk blok op dat de argumenten controleert die aan het script zijn doorgegeven:

if [ "$1" == "list-sites" ]; then
  list_sites
elif [ "$1" == "backup" ]; then
  SITE_NAME="$2"
  if [ -z "$SITE_NAME" ]; then
    echo "Usage: $0 trigger-backup "
    exit 1
  fi
  trigger_manual_backup "$SITE_NAME"
else
  echo "Usage: $0 {list-sites|trigger-backup }"
  exit 1
fi

De variabele $1 vertegenwoordigt het eerste argument dat aan het script wordt doorgegeven (bijvoorbeeld in ./script.sh list-sites, $1 is list-sites). Het script gebruikt voorwaardelijke controles om $1 te matchen met specifieke commando’s zoals list-sites of backup. Als het commando backup is, verwacht het ook een tweede argument ($2), wat de sitenaam is. Als er geen geldig commando wordt gegeven, geeft het script standaard gebruiksinstructies weer.

Je kunt nu een handmatige backup voor een specifieke site starten door het commando uit te voeren:

./script.sh backup

Geavanceerd gebruik 2: Plugins bijwerken voor meerdere sites

Het beheren van WordPress plugins op meerdere sites kan vervelend zijn, vooral als er updates beschikbaar zijn. Kinsta regelt dit heel goed via het MyKinsta dashboard, door middel van de bulkactie-functie die we vorig jaar hebben geïntroduceerd.

Maar als je niet graag met gebruikersinterfaces werkt, biedt de Kinsta API een andere mogelijkheid om een shellscript te maken om het proces van het identificeren van verouderde plugins en het bijwerken ervan op meerdere sites of specifieke omgevingen te automatiseren.

De workflow opsplitsen

1. Identificeer sites met verouderde plugins: Het script doorloopt alle sites en omgevingen en zoekt naar de opgegeven plugin waarvan een update beschikbaar is. Het volgende endpoint wordt gebruikt om de lijst met plugins voor een specifieke siteomgeving op te halen:

GET /sites/environments/{env_id}/plugins

Uit het antwoord filteren we op plugins met "update": "available".

2. De gebruiker wordt gevraagd om updateopties: Het toont de sites en omgevingen met de verouderde plugin, zodat de gebruiker specifieke instanties kan selecteren of ze allemaal kan bijwerken.

3. Trigger plugin updates: Om de plugin in een specifieke omgeving bij te werken, gebruikt het script dit endpoint:

PUT /sites/environments/{env_id}/plugins

De naam van de plugin en de bijgewerkte versie worden doorgegeven in de request body.

Het script

Omdat het script lang is, wordt de volledige functie gehost op GitHub voor gemakkelijke toegang. Hier leggen we de kernlogica uit die wordt gebruikt om verouderde plugins op meerdere sites en omgevingen te identificeren.

Het script begint met het accepteren van de plugin naam van het commando. Deze naam specificeert de plugin die je wilt bijwerken.

PLUGIN_NAME=$1

if [ -z "$PLUGIN_NAME" ]; then
  echo "Error: Plugin name is required."
  echo "Usage: $0 update-plugin "
  return 1
fi

Het script gebruikt dan de herbruikbare get_sites_list functie (eerder uitgelegd) om alle sites in het bedrijf op te halen:

echo "Fetching all sites in the company..."

# Fetch all sites in the company
SITES_RESPONSE=$(get_sites_list)
if [ $? -ne 0 ]; then
  echo "Error: Failed to fetch sites."
  return 1
fi

# Clean the response
CLEAN_SITES_RESPONSE=$(echo "$SITES_RESPONSE" | tr -d 'r' | sed 's/^[^{]*//')

Vervolgens komt het hart van het script: door de lijst met sites lopen om te controleren op verouderde plugins. De CLEAN_SITES_RESPONSE, een JSON-object dat alle sites bevat, wordt doorgegeven aan een while-loop om de bewerkingen voor elke site een voor een uit te voeren.

Het begint met het verzamelen van enkele belangrijke gegevens zoals de site-ID, naam en weergavenaam in variabelen:

while IFS= read -r SITE; do
  SITE_ID=$(echo "$SITE" | jq -r '.id')
  SITE_NAME=$(echo "$SITE" | jq -r '.name')
  SITE_DISPLAY_NAME=$(echo "$SITE" | jq -r '.display_name')

  echo "Checking environments for site "$SITE_DISPLAY_NAME"..."

De sitenaam wordt vervolgens samen met de eerder gedefinieerde functie get_site_details_by_name gebruikt om gedetailleerde informatie over de site op te halen, inclusief alle omgevingen.

SITE_DETAILS=$(get_site_details_by_name "$SITE_NAME")
CLEAN_SITE_DETAILS=$(echo "$SITE_DETAILS" | tr -d 'r' | sed 's/^[^{]*//')

ENVIRONMENTS=$(echo "$CLEAN_SITE_DETAILS" | jq -r '.site.environments[] | "(.id):(.name):(.display_name)"')

De omgevingen worden vervolgens doorlopen om details van elke omgeving op te halen, zoals de ID, naam en weergavenaam:

while IFS= read -r ENV; do
  ENV_ID=$(echo "$ENV" | cut -d: -f1)
  ENV_NAME=$(echo "$ENV" | cut -d: -f2)
  ENV_DISPLAY_NAME=$(echo "$ENV" | cut -d: -f3)

  echo "Checking plugins for environment "$ENV_DISPLAY_NAME"..."

Voor elke omgeving haalt het script nu de lijst met plugins op met behulp van de Kinsta API.

PLUGINS_RESPONSE=$(curl -s -X GET "$BASE_URL/sites/environments/$ENV_ID/plugins" 
  -H "Authorization: Bearer $API_KEY" 
  -H "Content-Type: application/json")

CLEAN_PLUGINS_RESPONSE=$(echo "$PLUGINS_RESPONSE" | tr -d 'r' | sed 's/^[^{]*//')

Vervolgens controleert het script of de opgegeven plugin in de omgeving bestaat en een update beschikbaar heeft:

OUTDATED_PLUGIN=$(echo "$CLEAN_PLUGINS_RESPONSE" | jq -r --arg PLUGIN_NAME "$PLUGIN_NAME" '.environment.container_info.wp_plugins.data[] | select(.name == $PLUGIN_NAME and .update == "available")')

Als er een verouderde plugin wordt gevonden, logt het script de details en voegt deze toe aan de SITES_WITH_OUTDATED_PLUGIN array:

if [ ! -z "$OUTDATED_PLUGIN" ]; then
  CURRENT_VERSION=$(echo "$OUTDATED_PLUGIN" | jq -r '.version')
  UPDATE_VERSION=$(echo "$OUTDATED_PLUGIN" | jq -r '.update_version')

  echo "Outdated plugin "$PLUGIN_NAME" found in "$SITE_DISPLAY_NAME" (Environment: $ENV_DISPLAY_NAME)"
  echo "  Current Version: $CURRENT_VERSION"
  echo "  Update Version: $UPDATE_VERSION"

  SITES_WITH_OUTDATED_PLUGIN+=("$SITE_DISPLAY_NAME:$ENV_DISPLAY_NAME:$ENV_ID:$UPDATE_VERSION")
fi

Zo zien de gelogde details van verouderde plugins eruit:

Outdated plugin "example-plugin" found in "Site ABC" (Environment: Production)
  Current Version: 1.0.0
  Update Version: 1.2.0
Outdated plugin "example-plugin" found in "Site XYZ" (Environment: Staging)
  Current Version: 1.3.0
  Update Version: 1.4.0

Vanaf hier voeren we plugin-updates uit voor elke plugin met behulp van zijn endpoint. Het volledige script staat in deze GitHub repository.

Samenvatting

Dit artikel heeft je begeleid bij het maken van een shellscript voor interactie met de Kinsta API.

Neem de tijd om de Kinsta API verder te verkennen – je zult extra functies ontdekken die je kunt automatiseren om taken uit te voeren die zijn afgestemd op jouw specifieke behoeften. Je zou kunnen overwegen om de API te integreren met andere API’s om de besluitvorming en efficiëntie te verbeteren.

Controleer tot slot regelmatig het MyKinsta dashboard voor nieuwe functies die zijn ontworpen om websitebeheer nog gebruiksvriendelijker te maken via de intuïtieve interface.

Joel Olawanle Kinsta

Joel is een Frontend developer die bij Kinsta werkt als Technical Editor. Hij is een gepassioneerd leraar met liefde voor open source en heeft meer dan 200 technische artikelen geschreven, voornamelijk over JavaScript en zijn frameworks.