BEAR

woobe_get_products() übernimmt start, length und order von DataTables und reicht sie an WOOBE_PRODUCTS::gets() weiter, das die WP_Query aufbaut. Beim Sortieren nach einer Meta-Spalte wird für die Typen number, timestamp und unix auf meta_value_num umgeschaltet, sonst auf meta_value.

Die Seitengröße ist im Einstellungsmodell auf 100 Zeilen begrenzt, mit dem Kommentar, dass größere Seiten auf schwachen Servern zu HTTP 500 führten; die kostenlose Version ist fest auf 10 eingestellt. Ist der Variationen-Schalter aktiv, werden die Variationen jedes variablen Produkts abgefragt und als Zeilen direkt hinter ihrem Elternprodukt eingefügt.

woobe_get_fields() beschreibt jede Spalte: field_type (field, meta, prop, taxonomy, attribute, downloads, gallery, upsells und weitere), Werttyp, Bearbeitungsansicht, Sanitizer, Produkttypen, für die die Spalte nicht gilt, und die Sichtbarkeit für Shop-Manager. Globale Attribute und alle Produkt-Taxonomien werden zur Laufzeit aus wc_get_attribute_taxonomies() und get_object_taxonomies() ergänzt.

update_page_field() verzweigt nach field_type: update_post_meta für Meta, WC_Product-Setter plus save() für Eigenschaften, wp_set_post_terms für Taxonomien, neu aufgebaute WC_Product_Attribute-Listen für Attribute. Zellen der Tabelle, History-Rücknahmen und die meisten Bulk-Schreibvorgänge enden in dieser Funktion. Bulk-Änderungen an Taxonomien und Attributen schreiben die Terms direkt und lösen vor dem Schreiben denselben History-Hook aus.

woobe_meta_get_keys() liest alle Meta-Keys eines Beispielprodukts und zieht die internen Keys von WooCommerce ab. Diese Liste ist eine geschützte Eigenschaft des Product Data Store, deshalb erweitert WOOBE_PDS_CPT den Store nur, um sie zurückzugeben, und ergänzt _button_text und _product_url.

Meta-Keys werden getrimmt, aber weder in Kleinbuchstaben umgewandelt noch bereinigt, weil echte Keys, die andere Plugins schreiben, etwa _woocs_sale_price_USD, zwischen Groß- und Kleinschreibung unterscheiden.

woobe_extend_fields() macht aus jeder gespeicherten Meta-Definition eine Spalte; ein Zahlentyp erhält den floatval-Sanitizer und numerische Sortierung. Dieselbe Definition speist woobe_filter_numbers (Bereich von/bis), woobe_filter_text (LIKE, =, !=, NOT LIKE, leer, nicht leer), Switcher-Filter und woobe_bulk_number (setzen, erhöhen oder verringern um einen Wert oder um Prozent).

Eine Switcher-Spalte kann andere Werte als 1/0 speichern (zum Beispiel yes/no), und zwar über eine Override-Regel pro Key, die over_switcher_swicher_to_val() liest. Die kostenlose Version behält die ersten 2 Meta-Felder.

process_jsoned_meta_data() baut einen Meta-Wert aus keys/values-Paaren für Arrays und keys2/values2 für Objekte wieder auf, dekodiert verschachtelte JSON-Werte und greift bei einfachen Strings und Zahlen auf den Rohwert zurück. Die History speichert solche Werte als JSON mit JSON_HEX_QUOT und JSON_HEX_TAG, damit sie den Hin- und Rückweg unbeschadet überstehen.

Filter und Bulk-Konfigurationen werden von WOOBE_STORAGE zwischen Requests gehalten. Unter Redis oder Memcached lebt ein Transient nur im Object Cache und geht beim Leeren verloren. Deshalb ist der Standardspeicher eine Option woobe_memory_<user id>: Jeder Key hat sein eigenes Ablaufdatum, abgelaufene Keys werden beim Schreiben verworfen, Autoload ist aus, und die Zeile wird mit dem Benutzer gelöscht. Session-, Transient- und Cookie-Modus bleiben über den Filter woobe_storage_type verfügbar.

woobe_filter_products() speichert das geparste Filterformular unter woobe_filter_<key>, wobei der Key ein bei jedem Filtern erzeugter Zufalls-String ist, sodass Bulk-nach-Filter in mehreren Browser-Tabs gleichzeitig funktioniert. Jeder Aufruf von WOOBE_PRODUCTS::gets() reicht seine Argumente durch woobe_apply_query_filter_data(), das den gespeicherten Filter liest, tax_query, meta_query, post__in und post_status zurückgibt und für den Rest posts_where-Hooks anhängt.

Tabellenpaginierung, Bulk-Zähler, Export-Zähler und die Variationswerkzeuge rufen alle gets() auf, daher können sie sich nicht darüber uneinig sein, welche Produkte ein Filter meint.

regular_price_where(), sale_price_where(), stock_quantity_where() und dimensions_where() fragen postmeta sowohl für product als auch für product_variation ab, lesen dann post_parent der gefundenen Variationen und beschränken die Hauptabfrage auf die Elternprodukte plus Variationen mit ID IN (...).

Gibt es keinen Treffer, wird die Klausel zu ID = -1, damit eine leere Übereinstimmung keine Produkte liefert statt des ganzen Katalogs, was einen Klick vor einem Bulk-Edit entscheidend ist.

Benutzerdefinierte Zahlenbereiche verwenden meta_query-Typ DECIMAL(30,20): Ein nacktes DECIMAL hat Skala 0, sodass eine Suche von 100 bis 150 auch 99.xx finden würde. Preis-SQL castet auf DECIMAL(30,10).

Ein leeres Gewicht wird als '' gespeichert, und MySQL liest '' als 0, daher verlangen Preis- und Maßbereiche meta_value <> '', damit ein leeres Feld nie als 0 zählt. Ein fehlendes Bereichsende ist offen (ersetzt durch -999999999 oder 999999999), und von gleich bis bedeutet genau diesen Wert.

posts_txt_where() teilt den Text an ^; ein Präfix ~ verbindet den Teil mit AND, ein Präfix ! macht daraus ein NOT REGEXP in einer separaten AND-Gruppe. Die Verhaltensweisen exact, begin, end, not und empty werden auf = und verankertes REGEXP abgebildet; eckige und geschweifte Klammern werden maskiert. Es gilt für Titel, Inhalt, Auszug und Slug.

Der SKU-Filter nimmt eine kommagetrennte Liste und baut vorbereitete LIKE-Bedingungen mit esc_like, OR für die Treffermodi und AND für „not“.

Beim Operator AND wird jeder Term zu einer eigenen tax_query-Klausel unter relation AND, weil eine einzelne Klausel mit Operator AND keine Produkte liefern kann. Operatoren stehen auf einer Whitelist aus IN, NOT IN, AND, EXISTS und NOT EXISTS; WordPress verwirft eine Klausel mit unbekanntem Operator und würde jedes Produkt treffen.

Die Katalogsichtbarkeit wird in Kombinationen der product_visibility-Terms exclude-from-catalog und exclude-from-search übersetzt, und ein Lagerstatusfilter beschränkt product_type zusätzlich auf Typen, die einen Lagerstatus haben.

woobe_bulk_products_count() speichert die Bulk-Konfiguration unter einem zufälligen, 16 Zeichen langen bulk_key und gibt jede gefilterte ID zurück (fields=ids, ohne Paginierung). __woobe_bulk_products() in bulk.js zerlegt diese Liste, sendet einen Batch nach dem anderen, aktualisiert die Fortschrittsanzeige und ruft am Ende woobe_bulk_finish auf; der Benutzer kann den laufenden Request abbrechen.

Die Batch-Größe ist number_posts_processed, 10 bis 100 pro Request, standardmäßig 30, sodass ein schwacher Server Geschwindigkeit gegen Stabilität tauschen kann.

Würde man die gefilterte Abfrage zwischen den Batches paginieren, würden Produkte übersprungen: Eine Preisänderung schiebt ein Produkt aus einem Preisfilter, und jeder spätere Offset verschiebt sich. Die zu Beginn erfasste ID-Liste hält der Client, und jeder Batch-Request sendet seine IDs ausdrücklich, ohne den Filter-Key.

Nach dem Durchlauf werden markierte Zeilen, die in der neu gezeichneten Tabelle nicht mehr erscheinen, aus der Auswahl entfernt, damit die nächste Aktion keine Produkte trifft, die der Benutzer nicht mehr sieht.

_process_number_data() wendet setzen, erhöhen oder verringern um Wert oder Prozent an sowie feldübergreifende Regeln wie Aktionspreis = regulärer Preis minus Prozent. Danach folgt eine optionale Formel mit einem anderen Meta-Feld (+, -, *, / mit Schutz vor Division durch null), dann ein optionaler Zufallsbetrag in einem Bereich mit festgelegten Dezimalstellen.

update_page_field() rundet auf die Preisdezimalstellen des Shops: auf ganze Einheiten, auf 0.05, auf 0.1 oder auf eine feste Cent-Endung wie .99. Textfelder erhalten Anhängen, Voranstellen, Ersetzen (mit oder ohne Beachtung der Groß-/Kleinschreibung) und Platzhalter wie {TITLE}, {SKU}, {meta:key} und {attribute:pa_size}.

In einem Bulk-Durchlauf wird ein berechneter Aktionspreis, der den regulären Preis erreicht, übersprungen, und ein Wert von null oder weniger löscht den Aktionspreis. Ein einzelnes Schreiben eines Aktionspreises auf oder über dem regulären Preis wird auf den regulären Preis minus die kleinste Preiseinheit begrenzt.

Beim Schreiben von Aktionsdaten wird _price sofort auf den aktuell geltenden Preis gesetzt (Aktion noch nicht begonnen, laufend, beendet) und die Produkt-Transients werden geleert, statt auf den geplanten Aktions-Job von WooCommerce zu warten.

WooCommerce liest die Preise eines variablen Produkts aus seinen Variationen, daher wird ein ins Elternprodukt geschriebener Preis übersprungen, und ein löschendes Schreiben entfernt jeden übrig gebliebenen Elternpreis. Ein Lagerbestand von 0 oder weniger schaltet normalerweise die Lagerverwaltung ein; das geschieht nicht bei einem variablen Elternprodukt, das keinen Lagerbestand führt, weil sonst jede Variation ohne eigenen Lagerbestand als nicht vorrätig gälte, und auch nicht bei einer Variation, die aus dem Lager ihres Elternprodukts verkauft, weil sie dadurch abgekoppelt würde.

WooCommerce leert Menge, Nachbestellung und Warnschwelle für niedrigen Lagerbestand, wenn die Lagerverwaltung ausgeschaltet wird. keep_stock_on_switch() speichert sie in einem eigenen Meta und stellt sie wieder her, wenn die Verwaltung erneut eingeschaltet wird.

generate_combinations() bildet das kartesische Produkt der gewählten Attribut-Terms. Beim Anwenden werden die Attribute als Variationsattribute angehängt, Kombinationen übersprungen, die ein Produkt bereits hat, Elternpreise kopiert, jeder neuen Variation zur Vermeidung von Duplikaten die SKU parent-SKU-<id> vergeben und die Variationen über den Data Store neu sortiert.

Beim Bearbeiten, Löschen und Exportieren einer Teilmenge von Variationen werden die Attribute jeder Variation mit den gewählten Kombinationen verglichen: Keys und Werte sortiert, Einträge '-1' gelten als beliebiger Wert, und beide Seiten werden URL-dekodiert, weil nicht-lateinische Attribut-Slugs kodiert gespeichert werden.

update_page_field() löst woobe_before_update_page_field aus, und WOOBE_HISTORY::write() liest den aktuellen Wert und kodiert ihn nach Typ: Term-IDs, Attribute, Galerie und Relationen als JSON, Downloads als name/file/hash, Lagerstatus als 1/0, Aktionsdaten als ISO-Daten mit ihrem Zeitzonen-Offset, sodass eine Rücknahme den genauen Zeitplan wiederherstellt.

Die Zeilen enthalten field_key, product_id, prev_val, mod_date, bulk_key, user_id und via_mcp, indiziert nach Produkt, Bulk-Key und Benutzer. Eine zweite Tabelle führt pro Bulk-Durchlauf einen Kopfeintrag: Status (completed oder terminated), Start, Ende, Produktanzahl und die Feld-Keys.

Das Umschalten der Lagerverwaltung oder ein Lagerbestand von 0 bei einem nicht verwalteten Produkt lässt WooCommerce den Lagerstatus ableiten; das Ausschalten der Verwaltung entfernt auch die Menge. update_page_field() protokolliert stock_status und bei Bedarf stock_quantity als zusätzliche Zeilen direkt nach dem bearbeiteten Feld.

stock_status_pair() und stock_row_at() finden diese Zeilen über benachbarte IDs (+1, +2) und verlangen dasselbe Produkt, denselben Autor, denselben Kanal (von Hand oder über einen Agenten) und denselben Bulk-Key sowie eine nahe Schreibzeit. revert() stellt dann die Menge vor dem Status wieder her, weil WooCommerce den Status aus der Menge ableitet, solange der Lagerbestand verwaltet wird. Ein leerer vorheriger Lagerbestand bedeutet „nicht verwaltet“, daher schaltet untrack_stock() die Verwaltung aus, statt 0 zu schreiben.

Im Tab History setzt woobe_history_revert_bulk_portion() 10 Zeilen pro AJAX-Request zurück, mit Fortschrittsanzeige, und die Kopfzeile wird gelöscht, wenn der Zähler die Gesamtzahl erreicht. Jede Rücknahme löscht ihre Zeile, sodass die nächste Portion einfach nimmt, was übrig ist.

Das MCP-Rollback-Werkzeug ist ein eigener Pfad: revert_bulk_portion() setzt bis zu 200 Zeilen pro Aufruf zurück und meldet die tatsächlich entfernten Zeilen, weil die beiden Zeilen einer Lageränderung gemeinsam zurückgesetzt werden und eine Portion eine Zeile mehr als ihr Limit enthalten kann.

revert() entfernt zuerst alle woobe_before_update_page_field-Listener, damit die eigenen Schreibvorgänge des Rollbacks nicht als neue History aufgezeichnet werden.

Jede Zeile trägt user_id und via_mcp. Der Shop-weite MCP-Schlüssel schreibt als Benutzer -777, was weder mit einem echten Benutzer noch mit 0 (nicht angemeldet) kollidieren kann. scope() liefert eine SQL-Bedingung, die jede Liste, Rücknahme, Löschung und Bereinigung verwendet, sodass keine Abfrage von der Regel abweichen kann.

Handler prüfen solo_in_scope() oder bulk_in_scope() und antworten mit 403 auf einen von Hand gebauten Request für eine Zeile, die der Benutzer nicht sehen darf. Die Autorennamen für die Liste werden in einer einzigen Abfrage gelesen.

CREATE TABLE IF NOT EXISTS verändert nie eine bereits vorhandene Tabelle. maybe_upgrade_schema() läuft einmal pro Schema-Version (derzeit 2), prüft vor jedem ALTER mit SHOW COLUMNS, damit ein gleichzeitiger Request nicht daran scheitert, versucht es beim nächsten Laden erneut, falls ALTER fehlschlägt, und markiert alte Zeilen von Benutzer -777 als über einen Agenten geschrieben.

In der kostenlosen Version behält prune_author() die zwei neuesten Einzeländerungen und die zwei neuesten Bulk-Durchläufe eines Autors. Die Zeilen, die zu einer behaltenen Lageränderung gehören, bleiben über stock_change_rows() mit erhalten. Die Bereinigung läuft beim Shutdown nach einem Schreibvorgang, und das Öffnen des Tabs löscht nie Zeilen eines anderen Benutzers.

woobe_export_products_count() löscht frühere Dateien, schreibt den CSV-Header oder das XML-Gerüst und gibt die gefilterten IDs zurück. woobe_export_products() hängt pro Request einen Batch mit fopen(a+) und fputcsv an, da WP_Filesystem nicht zeilenweise streamen kann; bei XML lädt es das WXR-Dokument und hängt item-Knoten an.

Variationen werden nach ihrem Elternprodukt eingefügt, wahlweise ohne nicht vorrätige, und können auf Attributkombinationen beschränkt oder davon ausgeschlossen werden.

get_csv_titles() schreibt 'Attribute N value(s)', 'name', 'visible' und 'global' pro Attribut sowie 'Download N name' und 'URL' pro Datei-Slot, also die Spalten, die der WooCommerce-Importer liest; Meta-Spalten heißen 'Meta: key'.

flatten_export_value() reduziert Arrays und Objekte (Terms, Attribute, WC-Datenobjekte) auf Skalare, die mit '|' verbunden werden, sodass ein Spaltentyp, den das Plugin nie gesehen hat, auch von Drittanbietern, nicht das Wort 'Array' schreibt.

Das Postfix des Dateinamens muss einem Minuten-Zeitstempel entsprechen und erhält eine 12 Zeichen lange Endung aus hash_hmac('sha256', postfix, wp_salt('auth')): identisch für jeden Request eines Exports, sodass alle Batches in einer Datei landen, von außen aber nicht erratbar. Die Endung ist bei nginx wichtig, das die .htaccess-Sperrregel ignoriert.

woobe_export_download() prüft Nonce und Berechtigung, akzeptiert nur Namen, die die Erweiterung erzeugt, leert alle Ausgabepuffer und streamt mit readfile() ohne Content-Length. Dateien, die älter als 8 Stunden sind, werden gelöscht, höchstens einmal pro Stunde geprüft.

Ein Klick im Browser kann keinen Authorization-Header senden, und der MCP-Schlüssel wird aus URLs herausgehalten. Das Export-Werkzeug speichert den Dateinamen unter einem zufälligen Token in einem Transient mit 900 Sekunden Lebensdauer, und /woobe/v1/mcp/export/<token> liefert nur diese Datei aus.

woobe_find_products führt den Filter einmal aus und speichert die IDs in einer nicht automatisch geladenen Option (bis zu 200,000 IDs, 24 Stunden gültig). Die Antwort enthält selection_id, count, eine Stichprobe und whole_catalogue, gemessen an einer ungefilterten Abfrage, sodass ein Filter, der nichts eingrenzt, als solcher gemeldet wird.

woobe_apply_bulk akzeptiert gar keinen Filter. Es lehnt ab, sofern confirm_count nicht der Auswahlgröße entspricht, sodass ein Agent, der die Zahl nicht gelesen hat, sie nicht erraten kann. Produkte, die nach dem Find angelegt wurden, gehören nicht zur Auswahl.

Die Filter-Engine liest die Felder des eigenen Formulars des Editors und ignoriert jeden anderen Key. Ein Agent kann einen falsch geschriebenen Key oder ein Datum als {from, to} senden, und eine ignorierte Bedingung würde die Auswahl ausweiten. WOOBE_MCP_FILTER prüft jeden Key gegen die Feldliste, die die Engine liest, lehnt unter Nennung des Keys und der akzeptierten Form ab und übergibt den Rest in der Form, die die Oberfläche sendet.

Die Engine hängt posts_where-Hooks an, die für den Rest des Requests bestehen bleiben, was auf der Oberfläche ein Seitenaufruf ist, in einem JSON-RPC-Batch aber mehrere Finds sein können. release_filter_hooks() entfernt sie nach jeder MCP-Abfrage, damit ein Find nie die Bedingungen eines anderen erbt. Argumenttypen werden gegen das inputSchema jedes Werkzeugs geprüft, sodass der String 'maybe' keine Bestätigung ist.

simulate() kopiert _process_number_data() wortgetreu, und run_chain() reicht jedes Ergebnis an die nächste Operation weiter, sodass ein zusammen mit einem neuen regulären Preis gesetzter Aktionspreis gegen den neuen geprüft wird. Arithmetik wird nur auf die numerischen Felder angewendet, auf denen die Engine rechnet; jedes andere Feld wird als einfache Ersetzung angezeigt.

Die Vorschau liefert drei Zahlen (Auswahl, betroffen nach Ausweitung der Elternprodukte auf Variationen, beschreibbar) sowie Warnungen: Prozent eines leeren Feldes übersprungen, variable Elternprodukte ohne eigenen Preis, Lagerbestand nicht verwaltet.

Die Apply-Schleife zerlegt die Warteschlange in Chunks zu 25 und ruft WOOBE_BULK::do_bulk() auf, die Engine der Oberfläche, bis 20 Sekunden vergangen sind. Sie gibt next_offset und bulk_key zurück; eine Fortsetzung schreibt in denselben History-Kopf, sodass ein Rollback den ganzen Auftrag zurücknimmt. Caches werden einmal nach den Schreibvorgängen geleert, nicht pro Chunk.

In der kostenlosen Version schrumpft der Chunk auf das verbleibende Schreibkontingent: ein Token Bucket von 100 Produkten, der sich über 30 Minuten kontinuierlich auffüllt, mit Bruchteil-Tokens und fester Obergrenze, sodass Leerlaufzeit keinen großen Durchlauf bezahlen kann.

include_variations 'all' ergänzt jedes Kind der gefundenen Elternprodukte; 'matching' behält Kinder, deren Attributwerte zu allen pa_-Terms des Filters passen („gelb und klein“ ist eine Variation, nicht die Vereinigung), wobei ein leerer Wert als „beliebig“ gilt. Kategorien und Schlagwörter können Kinder nicht eingrenzen.

Attribut-Keys werden mit sanitize_title() gebildet, wie WooCommerce sie bildet, weil nicht-lateinische Attributnamen URL-kodiert gespeichert werden und sanitize_key() sie entfernen würde. Im Matching-Modus werden variable Elternprodukte aus der Auswahl entfernt, damit ein späteres variations_only sie nicht wieder auf alle Variationen ausweitet.

WOOBE::init() läuft bei init, bevor REST_REQUEST definiert ist, sieht also bei einem REST-Aufruf weder Admin noch REST und würde nichts tun. bootstrap.php hängt sich selbst an rest_api_init und fährt das Plugin hoch; is_should_init() erlaubt REST nur für die eigenen Routen des Plugins, nicht für den gesamten REST-Verkehr der Website.

Währungsumschalter filtern Preis-Getter, sodass der Agent umgerechnete Preise las; strip_price_filters() entfernt diese Filter nur für den MCP-Request. Ein Produkt, das in eine Unterkategorie gelegt wird, wird über einen set_object_terms-Listener auch in deren Vorfahren gelegt, da in einem Chat niemand übergeordnete Kästchen anhakt.

Nach einem WPScan-Bericht wurde die gesamte Menge der AJAX-Handler geprüft, nicht nur die gemeldeten, und jeder Handler wurde auf WOOBE_HELPER::check_ajax_access() umgestellt. Es prüft die Nonce, dann die Berechtigung, dann current_user_can('edit_post') für jede Produkt-ID.

Variationen werden gegen das Elternprodukt geprüft: WooCommerce bildet edit_post bei einer Variation auf das einfache edit_products ab, das den Besitz ignoriert, und Variationen haben post_author 0. get_request_array() weist einen Skalar zurück, wo ein Array erwartet wird, statt ihn zu casten. Nicht-Admin-Rollen sind zusätzlich pro Feld eingeschränkt.

Bei ausgeschaltetem MCP kehrt register_routes() zurück, bevor etwas registriert wird, sodass der Endpunkt nicht existiert. permission() verlangt den Schlüssel bei jedem Request, auch beim MCP-Handshake, sodass ein nicht authentifizierter Aufrufer nichts über den Endpunkt erfährt. Der Schlüssel wird aus Authorization: Bearer oder X-WOOBE-KEY gelesen, mit dem Apache-Fallback REDIRECT_HTTP_AUTHORIZATION, und mit hash_equals verglichen.

Ablehnungen verwenden 403, nicht 401: In MCP startet ein 401 die OAuth-Erkennung, und der Client meldet den Server als defekt. Download- und Upload-Links verwenden eigene Tokens für einen einzigen Zweck, weil ein Klick im Browser keinen Header senden kann.

Der Assistent fordert ein Token an, bestehend aus vier Gruppen zu je acht Buchstaben und Ziffern aus random_int, und es wird von einer in WordPress angemeldeten Person bestätigt: bei dem Shop-weiten Schlüssel von einem Administrator, bei einem persönlichen Schlüssel vom Inhaber des Schlüssels in seinen eigenen Einstellungen. Beim Shop-weiten Schlüssel ist dieser zweite Faktor eine Einstellung; bei persönlichen Schlüsseln ist er immer aktiv. Gespeichert wird nur sein sha256-Hash zusammen mit den Zeiten der Bestätigung und der letzten Verwendung. check_connection() vergleicht mit hash_equals und trennt die Verbindung nach 3600 Sekunden ohne Aufruf; die Zeit der letzten Verwendung wird höchstens einmal pro Minute geschrieben.

Verbindungen gehören jeweils einem Inhaber: Ein für einen persönlichen Schlüssel bestätigtes Token wird mit jedem anderen Schlüssel abgelehnt.

Ein persönlicher Schlüssel hat die Form woobe_<40 hex>-<user id>. personal_key_owner() liest und vergleicht den gespeicherten Schlüssel immer mit hash_equals, mit einem Platzhalter gleicher Länge, wenn der Benutzer keinen hat, und fragt Freigabeliste und Berechtigung erst nach vollständiger Übereinstimmung ab, sodass die Antwortzeit einem Fremden nicht verrät, wer Zugriff hat. IDs mit führenden Nullen nehmen den Platzhalterpfad.

Der Request läuft dann über wp_set_current_user() als dieser Benutzer, sodass seine Rolle und Feldsichtbarkeit genau wie auf der Oberfläche gelten, und die Zwei-Faktor-Verbindung ist bei persönlichen Schlüsseln immer aktiv.

Jedes Werkzeug deklariert einen Bereich und annotations.readOnlyHint. Der Inhaber liefert eine Matrix über den Filter woobe_mcp_permissions; '*' setzt den Standard, sodass sie als Allow-List funktioniert. Ungültige Einträge werden protokolliert und ignoriert, und ein ungültiges '*' fällt auf full zurück, genau wie ohne Callback. Bei einem persönlichen Schlüssel wird jeder Bereich zusätzlich durch die Berechtigung eingeengt, die WooCommerce für diesen Bildschirm verlangt (edit_products, edit_shop_orders, view_woocommerce_reports und weitere).

Werkzeuge, die die Identität nicht aufrufen darf, werden gar nicht aufgelistet. Ein Schreibvorgang, der in einem anderen Bereich landet, etwa ein Rollback, das Produkte neu schreibt, fragt vor dem Schreiben require_access() für diesen Bereich. Der Filter woobe_mcp_tool_allowed kann nur weiter einengen. Kein MCP-Schlüssel, weder Shop-weit noch persönlich, darf post_author oder ID schreiben; diese werden im wp-admin von einer Person bearbeitet.