Wenn du viele WordPress-Seiten verwaltest, bist du wahrscheinlich immer auf der Suche nach Möglichkeiten, deine Arbeitsabläufe zu vereinfachen und zu beschleunigen.
Stell dir Folgendes vor: Mit einem einzigen Befehl in deinem Terminal kannst du manuelle Backups für alle deine Websites durchführen, selbst wenn du Dutzende davon verwaltest. Das ist die Stärke der Kombination von Shell-Skripten und der Kinsta-API.
In diesem Leitfaden lernst du, wie du mit Shell-Skripten benutzerdefinierte Befehle einrichten kannst, die die Verwaltung deiner Websites effizienter machen.
Voraussetzungen
Bevor wir beginnen, brauchst du Folgendes:
- Ein Terminal: Alle modernen Betriebssysteme werden mit einer Terminal-Software ausgeliefert, so dass du sofort mit der Skripterstellung beginnen kannst.
- Eine IDE oder einen Texteditor: Verwende ein Tool, mit dem du gut zurechtkommst, z. B. VS Code, Sublime Text oder sogar einen leichtgewichtigen Editor wie Nano für schnelle Terminal-Editierungen.
- Ein Kinsta-API-Schlüssel: Er ist wichtig, um mit der Kinsta-API zu interagieren. So generierst du ihn:
- Logge dich in dein MyKinsta-Dashboard ein.
- Gehe zu Dein Name > Unternehmenseinstellungen > API-Schlüssel.
- Klicke auf API-Schlüssel erstellen und speichere ihn sicher.
curlundjq: Unverzichtbar für API-Anfragen und den Umgang mit JSON-Daten. Überprüfe, ob sie installiert sind, oder installiere sie.- Grundlegende Programmierkenntnisse: Du musst kein Experte sein, aber ein Verständnis für die Grundlagen der Programmierung und die Syntax von Shell-Skripten ist hilfreich.
Dein erstes Skript schreiben
Dein erstes Shell-Skript zu erstellen, um mit der Kinsta-API zu interagieren, ist einfacher, als du vielleicht denkst. Beginnen wir mit einem einfachen Skript, das alle WordPress-Seiten auflistet, die unter deinem Kinsta-Konto verwaltet werden.
Schritt 1: Richte deine Umgebung ein
Beginne damit, einen Ordner für dein Projekt und eine neue Skriptdatei zu erstellen. Die Erweiterung .sh wird für Shell-Skripte verwendet. Du kannst zum Beispiel einen Ordner erstellen, zu ihm navigieren und mit diesen Befehlen eine Skriptdatei in VS Code erstellen und öffnen:
mkdir my-first-shell-scripts
cd my-first-shell-scripts
touch script.sh
code script.shSchritt 2: Definiere deine Umgebungsvariablen
Um deinen API-Schlüssel sicher zu halten, speichere ihn in einer .env Datei, anstatt ihn fest in das Skript zu kodieren. So kannst du die Datei .env zu .gitignore hinzufügen und verhindern, dass sie in die Versionskontrolle gelangt.
Füge in deiner .env Datei Folgendes hinzu:
API_KEY=your_kinsta_api_keyAls Nächstes ziehst du den API-Schlüssel aus der Datei .env in dein Skript, indem du oben in deinem Skript Folgendes hinzufügst:
#!/bin/bash
source .envDer Shebang #!/bin/bash sorgt dafür, dass das Skript mit der Bash ausgeführt wird, während source .env die Umgebungsvariablen importiert.
Schritt 3: Schreibe die API-Anfrage
Speichere zunächst deine Unternehmens-ID (zu finden in MyKinsta unter Unternehmenseinstellungen > Rechnungsdetails) in einer Variablen:
COMPANY_ID="<your_company_id>"Dann fügst du den Befehl curl hinzu, um eine GET-Anfrage an den Endpunkt /sites zu stellen und übergibst die Unternehmens-ID als Abfrageparameter. Verwende jq, um die Ausgabe für die Lesbarkeit zu formatieren:
curl -s -X GET
"https://api.kinsta.com/v2/sites?company=$COMPANY_ID"
-H "Authorization: Bearer $API_KEY"
-H "Content-Type: application/json" | jqMit dieser Anfrage werden Details zu allen Websites abgefragt, die mit deinem Unternehmen verbunden sind, einschließlich ihrer IDs, Namen und Status.
Schritt 4: Mache das Skript ausführbar
Speichere das Skript und mache es ausführbar, indem du es ausführst:
chmod +x script.shSchritt 5: Führe das Skript aus
Führe das Skript aus, um eine formatierte Liste deiner Websites zu sehen:
./list_sites.shWenn du das Skript ausführst, erhältst du eine ähnliche Antwort wie diese:
{
"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": []
}
]
}
}Das funktioniert zwar, aber wir können es noch verbessern, indem wir eine Funktion einrichten, die die Website-Details abruft und für eine bessere Lesbarkeit formatiert.
Schritt 6: Refactor mit einer Funktion
Ersetze die Anfrage curl durch eine wiederverwendbare Funktion, die die Seitenliste abruft und formatiert:
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_sitesWenn du das Skript erneut ausführst, erhältst du eine sauber formatierte Ausgabe:
Fetching all sites for company ID: b383b4c-****-****-a47f-83999c5d2...
Company Sites:
--------------
bitbucket-test (bitbuckettest) - Status: live
zivas Signature (duketest) - Status: liveMit diesem Skript hast du den ersten Schritt getan, um Shell-Skripte und die Kinsta-API für die Automatisierung der WordPress-Site-Verwaltung zu nutzen. In den nächsten Abschnitten werden wir uns mit der Erstellung fortgeschrittener Skripte befassen, die auf leistungsstarke Weise mit der API interagieren.
Fortgeschrittener Anwendungsfall 1: Backups erstellen
Das Erstellen von Backups ist ein wichtiger Aspekt der Website-Verwaltung. Sie ermöglichen es dir, deine Website im Falle unvorhergesehener Probleme wiederherzustellen. Mit der Kinsta-API und Shell-Skripten kann dieser Prozess automatisiert werden, was Zeit und Mühe spart.
In diesem Abschnitt erstellen wir Backups und gehen auf die von Kinsta vorgegebene Grenze von fünf manuellen Backups pro Umgebung ein. Dazu werden wir einen Prozess implementieren, um:
- Die aktuelle Anzahl der manuellen Backups überprüfen.
- das älteste Backup zu identifizieren und zu löschen (mit Bestätigung des Benutzers), wenn die Grenze erreicht ist.
- Ein neues Backup zu erstellen.
Kommen wir nun zu den Details.
Der Backup-Workflow
Um Backups über die Kinsta-API zu erstellen, verwendest du den folgenden Endpunkt:
POST /sites/environments/{env_id}/manual-backupsDies erfordert:
- Umgebungs-ID: Identifiziert die Umgebung (wie Staging oder Produktion), in der das Backup erstellt wird.
- Backup-Tag: Ein Etikett zur Identifizierung des Backups (optional).
Das manuelle Abrufen der Umgebungs-ID und das Ausführen eines Befehls wie backup <environment ID> kann mühsam sein. Stattdessen erstellen wir ein benutzerfreundliches Skript, bei dem du einfach den Namen der Website angibst und das Skript wird:
- Die Liste der Umgebungen für die Seite abrufen.
- Dich auffordern, die zu sichernde Umgebung auszuwählen.
- den Prozess der Backup-Erstellung abwickeln.
Wiederverwendbare Funktionen für sauberen Code
Um unser Skript modular und wiederverwendbar zu halten, werden wir Funktionen für bestimmte Aufgaben definieren. Gehen wir die Einrichtung Schritt für Schritt durch.
1. Basisvariablen einrichten
Du kannst das erste Skript, das du erstellt hast, weglassen oder eine neue Skriptdatei dafür erstellen. Beginne damit, die Basis-URL der Kinsta-API und deine Unternehmens-ID im Skript zu deklarieren:
BASE_URL="https://api.kinsta.com/v2"
COMPANY_ID="<your_company_id>"Diese Variablen ermöglichen es dir, die API-Endpunkte dynamisch im Skript zu erstellen.
2. Alle Seiten abrufen
Definiere eine Funktion, um die Liste aller Unternehmensseiten abzurufen. So kannst du später Details zu jeder Seite abrufen.
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"
}Du wirst feststellen, dass diese Funktion eine unformatierte Antwort von der API zurückgibt. Um eine formatierte Antwort zu erhalten. Du kannst eine weitere Funktion hinzufügen, die das erledigt (aber das ist nicht unser Thema in diesem Abschnitt):
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)"'
}Wenn du die Funktion list_sites aufrufst, werden deine Seiten wie oben gezeigt angezeigt. Das Hauptziel ist jedoch der Zugriff auf jede Seite und ihre ID, damit du detaillierte Informationen über jede Seite abrufen kannst.
3. Seiten-Details abrufen
Um Details zu einer bestimmten Seite abzurufen, verwendest du die folgende Funktion, die die Seiten-ID auf der Grundlage des Seitennamens abruft und zusätzliche Details wie z. B. Umgebungen abruft:
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"
}Die obige Funktion filtert die Site anhand des Seitennamens und ruft dann weitere Details zur Seite über den /sites/<site-id> Endpunkt ab. Zu diesen Details gehören auch die Umgebungen der Website, die wir benötigen, um Backups auszulösen.
Backups erstellen
Nachdem du nun wiederverwendbare Funktionen zum Abrufen von Website-Details und zum Auflisten von Umgebungen eingerichtet hast, kannst du dich darauf konzentrieren, die Erstellung von Backups zu automatisieren. Das Ziel ist es, einen einfachen Befehl mit dem Namen der Website auszuführen und dann interaktiv die Umgebung auszuwählen, die gesichert werden soll.
Beginne damit, eine Funktion zu erstellen (wir nennen sie trigger_manual_backup). Innerhalb der Funktion definierst du zwei Variablen: Die erste akzeptiert den Seitennamen als Eingabe und die zweite setzt ein Standard-Tag (default-backup) für die Sicherung. Dieses Standard-Tag wird verwendet, es sei denn, du legst später ein eigenes Tag fest.
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
}SITE_NAME ist der Bezeichner für die Website, die du verwalten willst. Du legst auch eine Bedingung fest, damit das Skript mit einer Fehlermeldung beendet wird, wenn die Kennung nicht angegeben wird. So wird sichergestellt, dass das Skript nicht ohne die erforderliche Eingabe fortfährt und mögliche API-Fehler vermieden werden.
Als Nächstes verwendest du die wiederverwendbare Funktion get_site_details_by_name, um detaillierte Informationen über die Website, einschließlich ihrer Umgebungen, abzurufen. Die Antwort wird dann bereinigt, um unerwartete Formatierungsprobleme zu beseitigen, die bei der Verarbeitung auftreten könnten.
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/^[^{]*//')Sobald wir die Seitendetails haben, extrahiert das folgende Skript alle verfügbaren Umgebungen und zeigt sie in einem lesbaren Format an. So kannst du sehen, welche Umgebungen mit der Seite verknüpft sind.
Das Skript fordert dich dann auf, eine Umgebung anhand ihres Namens auszuwählen. Dieser interaktive Schritt macht den Prozess benutzerfreundlich, da du dir die Umgebungs-IDs nicht merken oder eingeben musst.
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_NAMEDer gewählte Umgebungsname wird dann verwendet, um die entsprechende Umgebungs-ID in den Seitendetails nachzuschlagen. Diese ID wird für API-Anfragen benötigt, um ein Backup zu erstellen.
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"Im obigen Code wird eine Bedingung erstellt, damit das Skript mit einer Fehlermeldung beendet wird, wenn der angegebene Umgebungsname nicht übereinstimmt.
Da du nun die Umgebungs-ID hast, kannst du die aktuelle Anzahl der manuellen Backups für die ausgewählte Umgebung überprüfen. Da Kinsta die Anzahl der manuellen Backups auf fünf pro Umgebung begrenzt, ist dieser Schritt wichtig, um Fehler zu vermeiden.
Wir beginnen damit, die Liste der Backups über den /backups API-Endpunkt.
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')Das obige Skript filtert dann nach manuellen Backups und zählt sie. Wenn die Anzahl der Backups das Limit erreicht, müssen wir die vorhandenen Backups verwalten:
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")'
fiDie obige Bedingung identifiziert das älteste Backup, indem sie die Liste nach dem created_at Zeitstempel sortiert. Anschließend wirst du aufgefordert, zu bestätigen, dass du es löschen möchtest.
Wenn du zustimmst, löscht das Skript das älteste Backup mit seiner ID und gibt so Platz für das neue Backup frei. Auf diese Weise wird sichergestellt, dass immer Backups erstellt werden können, ohne dass die Grenzen manuell verwaltet werden müssen.
Da nun Platz vorhanden ist, können wir mit dem Code fortfahren, der das Backup für die Umgebung auslöst. Du kannst diesen Code gerne überspringen, aber für eine bessere Erfahrung wirst du aufgefordert, ein benutzerdefiniertes Tag anzugeben.
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"In dem folgenden Skript wird die Sicherung durchgeführt. Es sendet eine POST Anfrage an den /manual-backups Endpunkt mit der ausgewählten Umgebungs-ID und dem Backup-Tag. Wenn die Anfrage erfolgreich ist, gibt die API eine Antwort zurück, die die Erstellung des Backups bestätigt.
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")'Das war’s! Die Antwort auf die obige Anfrage ist so formatiert, dass die ID des Vorgangs, die Meldung und der Status angezeigt werden. Wenn du die Funktion aufrufst und das Skript ausführst, erhältst du eine ähnliche Ausgabe wie diese:
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: 202Befehle für dein Skript erstellen
Befehle vereinfachen die Verwendung deines Skripts. Anstatt das Skript zu bearbeiten oder den Code manuell auszukommentieren, können die Nutzer es mit einem bestimmten Befehl wie diesem ausführen:
./script.sh list-sites
./script.sh backup Füge am Ende deines Skripts (außerhalb aller Funktionen) einen bedingten Block ein, der die an das Skript übergebenen Argumente überprüft:
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
fiDie Variable $1 steht für das erste Argument, das an das Skript übergeben wird (z. B. in ./script.sh list-sites, $1 ist list-sites). Das Skript verwendet bedingte Überprüfungen, um $1 mit bestimmten Befehlen wie list-sites oder backup abzugleichen. Wenn der Befehl backup lautet, erwartet es auch ein zweites Argument ($2), das der Name der Website ist. Wenn kein gültiger Befehl angegeben wird, zeigt das Skript standardmäßig die Nutzungshinweise an.
Du kannst nun ein manuelles Backup für eine bestimmte Website auslösen, indem du den Befehl ausführst:
./script.sh backupErweiterter Anwendungsfall 2: Aktualisieren von Plugins über mehrere Websites hinweg
Die Verwaltung von WordPress-Plugins für mehrere Websites kann mühsam sein, vor allem, wenn Updates verfügbar sind. Kinsta macht das über das MyKinsta-Dashboard mit der im letzten Jahr eingeführten Funktion für Massenaktionen sehr gut.
Wenn du aber nicht gerne mit Benutzeroberflächen arbeitest, bietet die Kinsta-API eine weitere Möglichkeit, ein Shell-Skript zu erstellen, das den Prozess der Identifizierung veralteter Plugins und deren Aktualisierung für mehrere Websites oder bestimmte Umgebungen automatisiert.
Aufschlüsselung des Arbeitsablaufs
1. Identifiziere Websites mit veralteten Plugins: Das Skript durchläuft alle Websites und Umgebungen und sucht nach dem angegebenen Plugin, für das ein Update verfügbar ist. Der folgende Endpunkt wird verwendet, um die Liste der Plugins für eine bestimmte Site-Umgebung abzurufen:
GET /sites/environments/{env_id}/pluginsIn der Antwort wird nach Plugins gefiltert, für die "update": "available".
2. Aufforderung an den Nutzer, Optionen zur Aktualisierung anzugeben: Es werden die Websites und Umgebungen mit dem veralteten Plugin angezeigt, so dass der Nutzer bestimmte Instanzen auswählen oder alle aktualisieren kann.
3. Plugin-Updates auslösen: Um das Plugin in einer bestimmten Umgebung zu aktualisieren, verwendet das Skript diesen Endpunkt:
PUT /sites/environments/{env_id}/pluginsDer Name des Plugins und seine aktualisierte Version werden im Request Body übergeben.
Das Skript
Da das Skript sehr umfangreich ist, wird die vollständige Funktion auf GitHub gehostet, um den Zugang zu erleichtern. Hier erklären wir die Kernlogik, die verwendet wird, um veraltete Plugins über mehrere Websites und Umgebungen hinweg zu identifizieren.
Das Skript beginnt damit, dass es den Plugin-Namen vom Befehl annimmt. Dieser Name gibt das Plugin an, das du aktualisieren möchtest.
PLUGIN_NAME=$1
if [ -z "$PLUGIN_NAME" ]; then
echo "Error: Plugin name is required."
echo "Usage: $0 update-plugin "
return 1
fiDas Skript verwendet dann die wiederverwendbare Funktion get_sites_list (wurde bereits erklärt), um alle Websites des Unternehmens abzurufen:
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/^[^{]*//')Als Nächstes kommt das Herzstück des Skripts: Es durchläuft die Liste der Websites, um nach veralteten Plugins zu suchen. Das CLEAN_SITES_RESPONSE, ein JSON-Objekt, das alle Seiten enthält, wird an eine while-Schleife übergeben, um die Operationen für jede Seite einzeln durchzuführen.
Zunächst werden einige wichtige Daten wie die Site-ID, der Name und der Anzeigename in Variablen extrahiert:
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"..."Der Seitenname wird dann zusammen mit der zuvor definierten Funktion get_site_details_by_name verwendet, um detaillierte Informationen über die Seite, einschließlich aller Umgebungen, abzurufen.
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)"')Die Umgebungen werden dann in einer Schleife abgefragt, um Details zu jeder Umgebung zu erhalten, wie z. B. die ID, den Namen und den Anzeigenamen:
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"..."Für jede Umgebung holt sich das Skript nun die Liste der Plugins über die 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/^[^{]*//')Als Nächstes prüft das Skript, ob das angegebene Plugin in der Umgebung existiert und ein Update verfügbar ist:
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")')Wenn ein veraltetes Plugin gefunden wird, protokolliert das Skript seine Details und fügt sie dem Array SITES_WITH_OUTDATED_PLUGIN hinzu:
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")
fiSo würden die protokollierten Details veralteter Plugins aussehen:
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.0Von hier aus führen wir Plugin-Updates für jedes Plugin über seinen Endpunkt durch. Das vollständige Skript findest du in diesem GitHub-Repository.
Zusammenfassung
Dieser Artikel hat dich durch die Erstellung eines Shell-Skripts zur Interaktion mit der Kinsta-API geführt.
Nimm dir etwas Zeit, um die Kinsta-API weiter zu erkunden – du wirst zusätzliche Funktionen entdecken, die du automatisieren kannst, um Aufgaben zu erledigen, die auf deine speziellen Bedürfnisse zugeschnitten sind. Du könntest die API auch mit anderen APIs integrieren, um die Entscheidungsfindung und Effizienz zu verbessern.
Und schließlich solltest du das MyKinsta-Dashboard regelmäßig auf neue Funktionen überprüfen, die die Verwaltung der Website dank der intuitiven Oberfläche noch benutzerfreundlicher machen.
Joel ist Frontend-Entwickler und arbeitet bei Kinsta als Technical Editor. Er ist ein leidenschaftlicher Lehrer mit einer Vorliebe für Open Source und hat über 200 technische Artikel geschrieben, die sich hauptsächlich um JavaScript und seine Frameworks drehen.
