Alle WordPress-Tools für Claude und ChatGPT, in einer Liste.

Beiträge/Seiten/beliebige Inhaltstypen auflisten oder durchsuchen, mit Filtern und Seitenblättern.

Einen einzelnen Beitrag/Seite inkl. Rohinhalt, Meta und Begriffen abrufen, dazu, mit welchem Page-Builder er gebaut ist.

Beitrag, Seite oder Custom-Post-Type anlegen (Titel, Inhalt, Status, Begriffe, Meta).

Bestehenden Beitrag/Seite aktualisieren – nur angegebene Felder ändern sich. Wo der Page-Builder seine eigenen Daten zeigt und post_content nur eine Kopie ist (Elementor, Beaver Builder, SiteOrigin Page Builder, Enfold), wird eine Änderung des Inhalts abgelehnt, solange der Builder aktiv ist, mit dem Weg, die Seite stattdessen zu ändern.

Beitrag löschen (standardmässig Papierkorb, mit force=true endgültig).

Revisionen eines Beitrags auflisten.

Beitrag/Seite als neuen Entwurf duplizieren (inkl. Begriffe).

Post-Meta lesen: ein Schlüssel oder alle öffentlichen Meta-Werte.

Beitrag auf eine frühere Revision zurücksetzen.

Einen Post-Meta-Wert setzen (geschützte Schlüssel mit «_» sind blockiert).

Eine mit einem Page-Builder oder einer Block-Bibliothek gebaute Seite als Gliederung lesen: der Builder und jedes Element in Seitenreihenfolge mit Id, Typ und den sichtbaren Text-, Link- und Bildfeldern. Elemente, die sich nicht sicher ändern lassen (Code, HTML, Shortcodes, Formulare, dynamische, globale oder unbekannte Elemente), stehen als gesperrt mit Grund darin, ohne ihren Inhalt. layout_hash ändert sich, sobald sich eine gespeicherte Fassung der Seite ändert.

Text, Link oder Bild eines Elements auf einer Page-Builder- oder Block-Seite ändern, über die Id aus wp_get_builder_layout. Standardmässig Dry-Run; apply=true speichert. Zuerst wird ein Undo-Punkt angelegt; gespeichert wird über den Builder, wo er eine Speicherfunktion hat, danach wird die Seite zurückgelesen und wiederhergestellt, wenn ein Feld den neuen Wert nicht zeigt, und die Caches des Builders werden geleert. Mit layout_hash wird eine Seite abgelehnt, die sich inzwischen geändert hat.

Anhänge der Mediathek mit Seitenblättern auflisten.

Einen Anhang mit URL, Grössen, Alt-Text und Metadaten abrufen.

Datei von einer URL herunterladen und zur Mediathek hinzufügen (mit Schutz vor internen Adressen).

Ein lokales Bild oder PDF aus base64-Inhalt in die Mediathek hochladen.

Titel, Beschriftung und Alt-Text eines Anhangs ändern.

Einen Anhang aus der Mediathek löschen.

Begriffe einer Taxonomie auflisten (Kategorien, Schlagwörter, eigene).

Einen Begriff in einer Taxonomie anlegen.

Einen Begriff aktualisieren.

Einen Begriff aus einer Taxonomie löschen.

Kommentare mit Status- und Beitragsfiltern auflisten.

Kommentarstatus setzen: freigeben, halten, Spam oder Papierkorb.

Auf einen Kommentar antworten (oder einen Beitrag kommentieren) als aktueller Nutzer.

Einen Kommentar löschen (standardmässig Papierkorb, force = endgültig).

Einen einzelnen Begriff per ID und Taxonomie abrufen.

Einen einzelnen Kommentar per ID abrufen.

Benutzer mit Rollen-/Suchfiltern auflisten.

Einen Benutzer per ID, Login oder E-Mail abrufen.

Einen Benutzer mit Rolle anlegen.

Einen Benutzer aktualisieren (Rolle, Name, E-Mail, Passwort).

Einen Benutzer löschen, Inhalte optional neu zuweisen (letzter Admin geschützt).

Navigationsmenüs auflisten.

Ein Menü mit seinen Einträgen abrufen.

Ein Navigationsmenü anlegen.

Einen Eintrag zu einem Menü hinzufügen (eigener Link, Seite oder Beitrag).

Einen Eintrag aus einem Menü entfernen.

Die registrierten Sidebars (Widget-Bereiche) des Themes mit Widget-Anzahl auflisten.

Widgets und ihre Einstellungen auflisten, optional nach Sidebar gefiltert. Eine Einstellung, deren Schlüssel nach einem Zugangsdatum aussieht (API-Schlüssel, Token, Geheimnis oder Passwort), wird weggelassen und in hidden_keys genannt.

Die Einstellungen eines bestehenden Widgets aktualisieren (die angegebenen Felder werden eingefügt). Die zusammengeführten Einstellungen durchlaufen die eigene update()-Bereinigung des Widgets und den Filter widget_update_callback, wie im Widgets-Bildschirm — HTML wird also gefiltert, sofern Sie kein ungefiltertes HTML veröffentlichen dürfen. Ein Wert, den wp_get_widgets als Zugangsdatum weglässt, bleibt gespeichert, wenn Sie ihn weglassen, auch in verschachtelten Einstellungen, und die Antwort lässt ihn ebenfalls weg.

Ein Widget eines bestimmten Typs zu einer Sidebar hinzufügen und die neue id zurückgeben. Die Einstellungen durchlaufen die eigene update()-Bereinigung des Widgets und den Filter widget_update_callback, wie im Widget-Bildschirm.

Ein Widget aus seiner Sidebar entfernen und seine Einstellungen löschen.

Gängige Site-Einstellungen abrufen (Titel, Untertitel, URL, Admin-E-Mail, Zeitzone, Sprache, Beiträge pro Seite).

Einen Optionswert anlegen oder aktualisieren (rechte-relevante Optionen gesperrt).

Eine Option löschen.

Gängige Site-Einstellungen aktualisieren (Titel, Untertitel, Admin-E-Mail, Zeitzone, Wochenstart, Beiträge pro Seite).

Installierte Plugins mit Aktiv-Status und Version auflisten.

Ein Plugin per Dateipfad aktivieren (z.B. akismet/akismet.php).

Ein Plugin per Dateipfad deaktivieren.

Installierte Themes auflisten.

Dateien innerhalb eines Themes auflisten (standardmässig aktives Theme).

Den Inhalt einer Theme-Datei lesen (mit Pfad- und Symlink-Schutz).

Eine Theme-Datei schreiben (überschreiben/anlegen). Blockiert, wenn DISALLOW_FILE_MODS oder DISALLOW_FILE_EDIT gesetzt ist. Bevor eine PHP-Datei geschrieben wird, wird sie auf Syntax geprüft (bis 512 KB; die Antwort sagt, wenn die Prüfung nicht laufen konnte) und, wo der Server eine PHP-Kommandozeile derselben Version hat, mit php -l kompiliert; eine Datei, die durchfällt, wird nicht geschrieben. Nach dem Schreiben einer PHP-Datei eines aktiven Plugins oder Themes prüfen Probeaufrufe die Startseite, diesen Endpunkt und admin-post.php, und ein schwerer Fehler stellt die vorige Datei wieder her. Ab Werk legt jeder Schreibvorgang zuerst einen Undo-Punkt an.

Eine Datei in einem Theme löschen. Blockiert, wenn DISALLOW_FILE_MODS oder DISALLOW_FILE_EDIT gesetzt ist. Legt ab Werk zuerst einen Undo-Punkt an (wp_undo holt die Datei zurück). Löschen wird nicht mit Probeaufrufen geprüft: Stellen Sie vorher sicher, dass nichts die PHP-Datei lädt.

Datenbanktabellen mit Zeilenzahl auflisten.

Die Spalten einer Tabelle beschreiben.

Eine reine Leseabfrage ausführen: ein einzelnes SELECT ohne Kommentare. Läuft erst mit Schreibrechten, wie jedes Datenbank-Werkzeug. Nur SELECT — SHOW/DESCRIBE/EXPLAIN übernehmen wp_db_tables und wp_db_schema. Gesperrt sind unter anderem Prepared Statements, CTEs, UNION, Systemschemas und die Tabellen mit Benutzern, Optionen und Meta-Daten (die lesen die Meta-Werkzeuge, die Geheimnisse schwärzen). Ein äusseres LIMIT und ein Zeitlimit gelten; truncated=true heisst, es gab mehr Treffer.

Eine schreibende SQL-Anweisung ausführen (INSERT/UPDATE/DELETE). Zerstörerisches DDL und Schreibzugriffe auf Benutzer-/Rollen-/Options-Tabellen sind immer blockiert.

Umgebungs-Überblick: WordPress-/PHP-/MySQL-Version, aktives Theme, Plugin-Anzahl, URLs, Multisite, Speicher, HTTPS.

Registrierte Inhaltstypen auflisten.

Registrierte Taxonomien auflisten.

Geplante Cron-Ereignisse auflisten.

Das Ende der WordPress-debug.log zurückgeben, falls aktiviert.

Den WordPress-Objekt-Cache leeren (und OPcache, falls verfügbar).

Permalink-/Rewrite-Regeln neu schreiben (behebt 404 nach Strukturänderungen).

Volltextsuche über Inhalte (Titel + Text) für beliebige Inhaltstypen.

Serialisierungssicheres Suchen und Ersetzen auf der ganzen Site. tables: posts (Inhalt/Titel/Auszug), postmeta, options, terms (Name/Beschreibung/Termmeta); Standard posts+postmeta. Versteht PHP-serialisierte Arrays und JSON und findet den Text in den Formen, in denen WordPress und Page-Builder ihn speichern. scope (Standard «text»): Eine Seite, die ihr Page-Builder in eigenen Daten hält und die ein Schreiber dieser Version schreibt, wird nur über diesen Schreiber geändert — Texte, Links und Bilder, mit einem Undo-Punkt für diese Seiten, höchstens 25 je Aufruf; Treffer an gesperrten Stellen zählt locked_matches. scope «raw» ersetzt die gespeicherten Daten überall als Text. Papierkorb und automatische Entwürfe werden immer übersprungen. Standardmässig Dry-Run mit Vorschau je Tabelle — prüfen, dann apply=true setzen.

Den Status vieler Beiträge auf einmal per ID-Liste ändern.

Verfügbare Updates für Core, Plugins und Themes laut der letzten geplanten Prüfung von WordPress melden (nur lesend, zwischengespeicherte Daten; keine Anfrage nach aussen).

Ein Plugin aus dem WordPress.org-Verzeichnis per Slug installieren, optional aktivieren.

Ein Plugin aus einem hochgeladenen ZIP (base64) oder einer URL installieren, optional aktivieren.

Ein Theme aus einem hochgeladenen ZIP (base64) oder einer URL installieren, optional aktivieren.

Ein installiertes Plugin auf die neueste Version aktualisieren.

Ein installiertes Plugin löschen (deaktiviert es zuvor, falls aktiv).

Ein Theme aus dem WordPress.org-Verzeichnis per Slug installieren.

Ein installiertes Theme auf die neueste Version aktualisieren.

Ein installiertes Theme löschen (aktives Theme nicht möglich).

WordPress-Core auf die neueste Version aktualisieren. Hohe Tragweite – mit Bedacht.

WooCommerce: Bestellungen auflisten, nach Status filterbar. Benötigt WooCommerce.

WooCommerce: Eine Bestellung mit Positionen, Summen und Kunde. Benötigt WooCommerce.

WooCommerce: eine Bestellung auf einen Status setzen, den dieser Shop kennt (z.B. abgeschlossen); unbekannte Status werden abgelehnt. Benötigt WooCommerce.

WooCommerce: Produkte mit Suche/Status-Filter auflisten. Benötigt WooCommerce.

WooCommerce: Ein Produkt (Preis, Lager, SKU, Status). Benötigt WooCommerce.

WooCommerce: Produktpreis, Lagerbestand oder Status ändern. Benötigt WooCommerce.

WooCommerce: Gutscheine auflisten. Benötigt WooCommerce.

WooCommerce: Einen Gutschein erstellen. Benötigt WooCommerce.

WooCommerce: Kunden mit Bestellanzahl auflisten. Benötigt WooCommerce.

Aktives SEO-Plugin erkennen (Yoast, Rank Math, AIOSEO oder keins).

SEO-Titel, Meta-Description und Focus-Keyword eines Beitrags lesen.

SEO-Titel, Meta-Description und/oder Focus-Keyword setzen (Yoast oder Rank Math).

User-Meta lesen: ein Schlüssel oder alle öffentlichen Werte.

Term-Meta lesen: ein Schlüssel oder alle öffentlichen Werte.

Application-Passwörter eines Nutzers auflisten (Namen, Zeiten – nie das Geheimnis).

Einen User-Meta-Wert setzen (Rechte-/Auth-Schlüssel gesperrt).

Einen Term-Meta-Wert setzen.

Ein Application-Passwort für einen Nutzer erstellen. Das Geheimnis wird einmalig zurückgegeben.

Ein Application-Passwort eines Nutzers per UUID widerrufen.

Site-Health-Überblick: PHP-/WordPress-Version, HTTPS, Debug, Speicher, Objekt-Cache, offene Updates.

Inhalt auf einen Blick: Beiträge nach Typ/Status, Nutzer nach Rolle, Kommentare und Medien.

Cron-Ereignis planen: einmalig zu einem Zeitpunkt oder wiederkehrend (stündlich/täglich/…).

Alle geplanten Ereignisse eines Hooks entfernen.

Einen Transient-Wert mit optionaler Ablaufzeit (Sekunden) setzen.

Einen Transient per Name löschen.

OPTIMIZE TABLE auf den Datenbanktabellen dieser Installation ausführen.

Abgelaufene Transients löschen, um die Options-Tabelle aufzuräumen.

Dateien innerhalb eines installierten Plugin-Ordners auflisten.

Eine Datei in einem Plugin-Ordner lesen.

Eine Datei in einem Plugin-Ordner schreiben (überschreiben/anlegen). Blockiert, wenn DISALLOW_FILE_MODS oder DISALLOW_FILE_EDIT gesetzt ist. Bevor eine PHP-Datei geschrieben wird, wird sie auf Syntax geprüft (bis 512 KB; die Antwort sagt, wenn die Prüfung nicht laufen konnte) und, wo der Server eine PHP-Kommandozeile derselben Version hat, mit php -l kompiliert; eine Datei, die durchfällt, wird nicht geschrieben. Nach dem Schreiben einer PHP-Datei eines aktiven Plugins oder Themes prüfen Probeaufrufe die Startseite, diesen Endpunkt und admin-post.php, und ein schwerer Fehler stellt die vorige Datei wieder her. Ab Werk legt jeder Schreibvorgang zuerst einen Undo-Punkt an.

Eine Datei in einem Plugin-Ordner löschen. Blockiert, wenn DISALLOW_FILE_MODS oder DISALLOW_FILE_EDIT gesetzt ist. Legt ab Werk zuerst einen Undo-Punkt an (wp_undo holt die Datei zurück). Löschen wird nicht mit Probeaufrufen geprüft: Stellen Sie vorher sicher, dass nichts die PHP-Datei lädt.

Dateien im Uploads-Verzeichnis auflisten (optional Unterordner).

Eine Datei aus dem Uploads-Verzeichnis lesen.

Eine Text-/Asset-Datei ins Uploads-Verzeichnis schreiben. Ausführbare Endungen (php, js, cgi …) blockiert.

Eine Datei aus dem Uploads-Verzeichnis löschen.

Die Snippets von Code Snippets oder WPCode auflisten, je nachdem, welches aktiv ist: Id, Name, Typ, Ort, aktiv, Priorität, sha256 des Codes und der letzte Fehler, den WPCode festgehalten hat. AlphaBridge führt keine eigenen Snippets. Nur für Administratoren (manage_options und edit_plugins); nicht auf Multisite; gesperrt durch DISALLOW_FILE_EDIT und DISALLOW_FILE_MODS.

Ein Snippet von Code Snippets oder WPCode samt Code lesen. Roher Codezugriff: Ein Snippet kann API-Schlüssel oder andere Geheimnisse enthalten.

Ein PHP-Snippet in Code Snippets oder WPCode anlegen oder ändern. Ohne apply=true eine Vorschau. Geprüft, ohne es auszuführen: Syntaxprüfung (bis 512 KB; die Antwort sagt, wenn sie nicht laufen konnte), php -l, wo der Server eine PHP-Kommandozeile derselben Version hat, und keine Funktion oder Klasse, die es schon gibt. Ab Werk legt jede Änderung zuerst einen Undo-Punkt an. Das Snippet wird ausgeschaltet gespeichert, dann eingeschaltet, und es folgen Probeaufrufe; ein geändertes Snippet, dessen Probeaufrufe scheitern, geht auf die vorige Fassung zurück, ein neues bleibt gespeichert und aus. Snippets zum einmaligen Ausführen werden abgelehnt.

Ein PHP-Snippet von Code Snippets oder WPCode ein- oder ausschalten. Vor dem Einschalten laufen die Prüfungen von wp_save_php_snippet; in beiden Richtungen folgen Probeaufrufe, und ein schwerer Fehler stellt den vorigen Zustand wieder her.

Ein PHP-Snippet von Code Snippets oder WPCode in den Papierkorb des Plugins verschieben oder mit force=true endgültig löschen. Ein aktives Snippet läuft dann nicht mehr, darum folgen Probeaufrufe; ein schwerer Fehler holt es zurück.

Die Abilities auflisten, die Plugins und WordPress bei der Abilities-API registrieren (ab WordPress 6.9): Name, Bezeichnung, Kategorie, die Kennzeichen nur lesend und zerstörend, ein kurzes Eingabeschema, ob sie laufen kann und, wenn nicht, den Weg dahin, und ob ein Aufruf einen Rückweg hat.

Eine Ability über ihren Namen aus wp_list_abilities ausführen, über die Abilities-API. Die Ability prüft Eingabe und Berechtigung selbst. Sie läuft, wenn die Schreibrechte an sind und die Verbindung vollen Zugriff hat. Dann läuft jede Ability, die ein Administrator nicht unter Feineinstellung ausgeschaltet hat. Nur lesende laufen sofort. Jede andere zeigt standardmässig eine Vorschau und läuft mit apply=true. Wenn die Eingabe einen Beitrag nennt, kommt zuerst ein Undo-Punkt dieses Beitrags (bis 25 Beiträge je Aufruf). Danach werden die Beiträge zurückgelesen. Ohne einen solchen Beitrag sagt die Vorschau, dass es keinen Rückweg gibt.

Chunked-Upload-Session für eine grosse Datei starten. Gibt eine Session-ID zurück; Datei mit wp_upload_append senden, mit wp_upload_commit abschliessen.

Einen Base64-Chunk (empfohlen 1–4 MB Rohdaten pro Aufruf) der Reihe nach an eine Upload-Session anhängen.

Upload-Session abschliessen. Prüft optional eine SHA-256-Prüfsumme. Die fertige Datei ist dann über das "session"-Argument der Install- und Deploy-Tools nutzbar.

Upload-Session abbrechen und ihre Daten löschen.

Ein Deploy vorab ansehen: Das ZIP, das übertragen werden soll, wird mit dem verglichen, was wirklich auf dem Server liegt. Es wird nichts hochgeladen, geschrieben oder gelöscht — gelesen werden nur Verzeichnislisten und das ZIP-Inhaltsverzeichnis, nie Dateiinhalte. Pro Pfad meldet es neu, geändert und, im Atomic-Modus, entfernt.

Site-Deploy-Verbindung prüfen: Konfiguration, Same-Server-Verifikation und ein Live-Listing des Deploy-Roots. Öffnet mit den gespeicherten Zugangsdaten eine angemeldete Verbindung und läuft darum, wie jedes Deploy-Werkzeug, erst mit Schreibrechten.

Ein Verzeichnis im Deploy-Bereich auflisten (Pfad relativ zum Deploy-Root).

Eine Datei aus dem Deploy-Bereich lesen (max. 2 MB pro Aufruf). Binärinhalte kommen base64-codiert zurück.

Eine Datei in den Deploy-Bereich schreiben. Quellen: "content" (optional base64) oder eine abgeschlossene Upload-"session". Fehlende Verzeichnisse werden angelegt.

Ein ZIP-Archiv in den Deploy-Bereich hochladen und entpacken — deployt eine ganze Site oder einen Ordner in einem Schritt. Bestehende Dateien werden überschrieben.

Eine Datei — oder mit "recursive":true ein ganzes Verzeichnis — im Deploy-Bereich löschen.

Die STRUKTUR dieser Site als portables JSON exportieren: schreibbare Einstellungen, Taxonomie-Begriffe, die Seitenhierarchie, Menüs samt Punkten und Theme-Positionen, die Platzierung der Widgets, den Plugin-Bestand und das aktive Theme. Beitragsinhalte werden nie exportiert, ebensowenig Widget-Einstellungen, Zugangsdaten oder Benutzerdaten.

Ein Blueprint mit dem AKTUELLEN Zustand dieser Site vergleichen und genau das zurückgeben, was ein Anwenden tun würde. Auf jedem Plan verfügbar. Nur lesend: schreibt nichts. Je Abschnitt kommen create, update, unchanged und extra_on_target zurück — was hier existiert, aber nicht im Blueprint steht, wird nie angetastet; einen Lösch-Modus gibt es nicht.

Die anwendbaren Teile eines Blueprints auf diese Site übertragen. Standardmässig eine Vorschau: erst den Plan ansehen, dann apply=true setzen. Es löscht, deaktiviert und entfernt NIE etwas, und ein zweiter Lauf meldet alles als unverändert. Jeder Schreibvorgang läuft über die gewöhnlichen Werkzeuge — deren Rechte, der Token-Bereich und die Schalter je Werkzeug gelten also alle.

Die eigenen Undo-Punkte auflisten: die Sicherungen, die schreibende Werkzeuge vor einer Änderung angelegt haben. Jeder Eintrag trägt ein Token, das Ursprungswerkzeug, eine kurze Zusammenfassung und ein Verfallsdatum. Sichtbar sind nur die eigenen Punkte. Sie verfallen nach dem Undo-Fenster der Site, 7 Tage, sofern ein Administrator nicht 1 bis 30 Tage eingestellt hat; aufbewahrt werden ab Werk die neuesten 50 (insgesamt 100 MB). Das Auflisten räumt auch weg, was diese Grenzen schon ausscheiden — abgelaufene Punkte und die ältesten über den Grenzen, aller Benutzer, samt Sicherung —, wie es das Anlegen eines neuen Punkts tut.

Eine frühere Änderung über ihr Undo-Token zurücknehmen. Mit dry_run=true zuerst ansehen, was genau wiederhergestellt und was abgelehnt würde. Ein Undo verlangt dieselbe Berechtigung wie die ursprüngliche Aktion, und jeder Posten wird gegen den AKTUELLEN Zustand neu geprüft — eine inzwischen geschützte Option wird als blockiert gemeldet statt wiederhergestellt. Das Undo einer Page-Builder-Änderung oder eines Ability-Aufrufs stellt jede gespeicherte Fassung der Seite bytegleich wieder her und lehnt eine Seite ab, die seither jemand geändert hat, ausser mit force=true.

Einen Undo-Punkt samt Sicherung verwerfen, ohne etwas wiederherzustellen. Sinnvoll, sobald eine Änderung als gut bestätigt ist; mit all=true lassen sich alle eigenen Punkte auf einmal verwerfen. Undo-Punkte anderer Benutzer bleiben unberührt.

Inhalte als WordPress-WXR-Datei in einen geschützten Uploads-Unterordner ohne öffentliche Adresse exportieren; gibt upload_path zurück. Die Datei über das Dateisystem oder SFTP holen und danach löschen.

Multisite: die Seiten im Netzwerk auflisten. Benötigt Multisite.

Multisite: eine neue Seite im Netzwerk anlegen. Benötigt Multisite.

Multisite: ein Plugin netzwerkweit über alle Seiten aktivieren. Benötigt Multisite.