IDF MCP Adapter

Changelog

v3.53.0

Hinzugefügt

• replace-in-content mit quelle_id (#65): Ausgangspunkt der Ersetzungen ist dann der Content eines anderen Eintrags, etwa einer Musterseite. Das Ergebnis ersetzt den Content von post_id in einem einzigen Schreibvorgang, mit Revision und ohne Zwischenentwurf. md5_vorher gilt dann für die Quelle, die Antwort nennt zusätzlich Länge und MD5 des überschriebenen Contents.

Warum

• Bestehende Landingpages sollen direkt auf das Layout 2027 umgestellt werden, ohne Test-Entwürfe, die liegen bleiben (Joerg, 19.09.2026). Ihr alter Content hat mit dem neuen nichts gemein; eine Ersetzungsliste darauf wäre so groß wie der Content selbst. Von der Musterseite aus braucht eine Seite rund 42 Ersetzungen.

v3.52.0

Hinzugefügt

• clone-cpt kopiert einen CPT-Eintrag auf dem Server (#65): post_content Zeichen für Zeichen, dazu die Avada-Seitenoptionen (Meta _fusion*, fusion_*) und das Seiten-Template. Nicht kopiert werden ACF-Felder, Rank Math, Terms und Beitragsbild; das Beitragsbild lässt sich direkt mitgeben. Status nur draft, pending oder private. Die Antwort meldet Länge, MD5 und ob der gespeicherte Content dem Original gleicht.
• replace-in-content ersetzt Textstellen, ohne den ganzen Content zu übertragen (#65): für Beiträge, Seiten und öffentliche CPTs. Jede Ersetzung {alt, neu, anzahl} muss im Zwischenstand genau so oft vorkommen, sonst wird nichts geschrieben. md5_vorher sichert gegen Änderungen dazwischen, md5_nachher belegt das Ergebnis vor dem Schreiben, nur_pruefen rechnet nur. Status, Titel, Auszug und Felder bleiben unberührt.

Warum

• Eine Landingpage im Layout 2027 hat rund 130.000 Zeichen Content, weil der Avada-Builder jede Einstellung ausschreibt. So viel kommt durch keinen Modell-Aufruf: am 19.09.2026 scheiterten zwei Entwürfe per create-cpt am Ausgabe-Limit und an einem Ausgabefilter. Mit Klonen und Ersetzen gehen nur die geänderten Stellen über die Leitung.

v3.51.0

Hinzugefügt

• wc-list-variations liefert die Lieferzeit je Variation (#64): delivery_time ist der Name der German-Market-Lieferzeit aus der Post-Meta _lieferzeit, so wie der Shop sie anzeigt. Leer bei „nicht angegeben“ (-1), ohne Wert oder mit gelöschtem Term. Jeder Termname wird je Aufruf nur einmal nachgeschlagen.

Warum

• Der Bestands-Flow shop-bestand-woo (toni-tool-n8n #102) setzt die Lieferzeit je Variation, konnte sie aber nicht lesen und schrieb sie deshalb nur mit, wenn sich der Bestand einer Variation änderte. Nach der Umstellung auf „Versand innerhalb 48 Stunden nach Auftragsklarheit“ auch für Ware, die nur der Lieferant hat (Joerg, 19.09.2026), standen rund 8.000 Variationen weiter auf „ca. 10 Werktage“. Mit dem Wert vergleicht der Flow die Lieferzeit wie Menge und Status.

v3.50.0

Hinzugefügt

• Sammel-Ability wc-set-bestand-geprueft (#63). Setzt den Prüfzeitpunkt des Bestands-Syncs (Meta _idf_bestand_geprueft, bei idf-woo-addons „(geprüft: …)“ hinter der Lagerampel) an bis zu 500 Produkten je Aufruf. Sie schreibt nur diesen Meta-Wert, ohne die Produkte zu speichern, also ohne Produkt-Hooks und ohne Cache-Leerung. Leerer zeitpunkt löscht den Wert, ein unlesbarer wird abgewiesen.

Warum

• Der Bestands-Flow shop-bestand-woo (toni-tool-n8n #99) schrieb den Zeitpunkt alle 30 Minuten per wc-update-product an 220 Produkte. Jedes davon speicherte das ganze Produkt, und jede Speicherung leerte bei WP Rocket den Cache von Produktseite, Archiven und Startseite. Gemessen am 18.09.2026: Startseite während des Laufs 4 bis 11 s statt 0,3 s, auch ohne eine einzige Bestandsänderung.

Geändert

• Die Beschreibung von bestand_geprueft an wc-update-product verweist für viele Produkte auf die Sammel-Ability.

v3.49.0

Hinzugefügt

• Vollprüfung der produktabhängigen Checkbox (#62). wc-set-product-depending-checkbox meldet je Produkt jetzt auch status, variationen (alle Variationen) und variationen_abweichend: Variationen mit eigenem Wert, der weder -1 („Gleiche wie übergeordnet“) noch die gewünschte Checkbox ist. Bei ihnen erscheint an der Kasse eine andere oder gar keine Checkbox. abweichend nennt bis zu 20 davon mit Variations-ID und Wert, die Summen stehen daneben. Ein dry_run über ein Sortiment beweist damit ohne Schreibzugriff, dass jede Variation greift: vorher gleich dem gewünschten Wert, variationen_auf_uebergeordnet 0 und variationen_abweichend 0.
• wc-create-product und wc-update-product melden unter product_depending_checkbox dieselbe Zahl variationen_abweichend.
• Anlass: Joerg konnte bei der Abnahme nicht prüfen, ob die Checkbox an allen Kleidungsprodukten steht. Bisher zählte der Probelauf eigene Werte nur, ohne sie zu unterscheiden; eine Variation mit 0 („Keine Checkbox erforderlich“) sah aus wie eine mit -1.

Unverändert

• Variationen mit eigenem Wert bleiben weiter, wie sie sind. Die Ability meldet Abweichungen, sie überschreibt sie nicht.

v3.48.0

Hinzugefügt

• Produktabhängige Checkbox von German Market (#62). Neues Feld product_depending_checkbox an wc-create-product und wc-update-product (0 = keine Checkbox erforderlich, 1 bis n = diese Checkbox), an wc-create-variation und wc-update-variation zusätzlich -1 = „Gleiche wie übergeordnet“ (flach und je Batch-Zeile). German Market speichert den Wert als Meta _gm_product_depending_checkbox.
• Neue Sammel-Ability wc-set-product-depending-checkbox: setzt den Wert an bis zu 50 Produkten je Aufruf und alle Variationen ohne eigenen Wert auf -1. Sie schreibt nur diese Meta-Werte, ohne die Produkte zu speichern, also ohne Produkt-Hooks und Cache-Abgleich; dry_run: true zählt nur. Anlass ist die Regel von Joerg vom 17.09.2026, dass die Checkbox an allen rund 640 Kleidungsprodukten aktiv ist.
• wc-get-product liefert product_depending_checkbox, wc-list-variations je Variation den gespeicherten Wert und product_depending_checkbox_wirksam, also den Wert, den German Market an der Kasse tatsächlich nimmt.

Warum die Variationen mitgesetzt werden

• German Market liest an der Kasse den Wert der Variation im Warenkorb mit intval() und schaut nur bei -1 beim Elternprodukt nach. Eine Variation ganz ohne Wert zählt deshalb als „keine Checkbox“, auch wenn das Elternprodukt eine verlangt. Im Backend fällt das nicht auf, weil die Auswahl einen leeren Wert als „Gleiche wie übergeordnet“ anzeigt; per Schnittstelle angelegte Variationen haben den Wert aber nie bekommen.
• Deshalb setzt ein Wert am variablen Produkt alle Variationen ohne eigenen Wert auf -1, und wc-create-variation gibt einer neuen Variation -1 mit, sobald das Elternprodukt einen Wert trägt. Variationen mit eigenem Wert bleiben, wie sie sind.
• Fehlt German Market, wird der Wert abgewiesen. Ist die gewählte Checkbox in German Market nicht eingeschaltet oder ohne Text, speichert die Ability den Wert und sagt in hinweis, dass an der Kasse noch nichts erscheint.

v3.47.0

Geändert

• Vorauswahl und Variationen erkennen ein globales Attribut auch am Slug (apps-v2 #1131). default_attributes an wc-create-product und wc-update-product sowie attributes an wc-create-variation und wc-update-variation nehmen als Schlüssel jetzt auch den blanken Slug (farbe). Bisher trafen dort nur die Taxonomie (pa_farbe) und der Name (Farbe). Die Attributliste am Produkt kannte den Slug schon (idf_mcp_wc_resolve_global_attribute()), der Abgleich für Vorauswahl und Variationen (wc-create-product0) nicht.
• Anlass: pa_farbe soll im Shop „Kleidungsfarbe" heißen, der Slug bleibt. Ohne den Slug-Abgleich wäre danach jede Vorauswahl in der Form {"Farbe": "Weiss"} abgewiesen worden („nicht jeder Wert liess sich einem Attribut des Produkts zuordnen"), und genau so schreiben der Skill idf-shop-produkte und die Import-Werkzeuge. Groß- und Kleinschreibung zählen nicht: Farbe trifft den Slug farbe auch dann, wenn das Attribut längst anders heißt.

v3.46.0

Hinzugefügt

• wc-list-products blättert und filtert nach Marke (#54, apps-v2 #1109). Neue Eingaben page, brand (Marken-Slug der Taxonomie product_brand), orderby (date, id, title, modified) und order. Die Antwort nennt page0 (Einträge dieser Seite), page1 (alle Treffer), page2 und page3, je Produkt zusätzlich page4. Anlass ist der Import der Berufskleidung nach Directus: 496 Produkte, davon 276 von Greiff, die Liste endete bei 100.
• Beim Blättern orderby: id nehmen. Dann verschiebt ein Produkt, das während des Durchlaufs neu angelegt wird, die Seiten nicht.

Geändert

• total ist bei wc-list-products jetzt die Zahl aller Treffer, bisher war es die Zahl der gelieferten Einträge. Eine abgeschnittene Liste sah damit vollständig aus. Die gelieferten Einträge zählt jetzt count. Kein Flow und keine App hat total bisher gelesen.
• Ohne die neuen Eingaben bleibt die Liste, wie sie war: die zehn neuesten Produkte.

v3.45.0

Hinzugefügt

• wc-remove-attribute-value: einen Wert komplett aus einem variablen Produkt nehmen (apps-v2 #1092). Anlass sind ausgelaufene Farben: Wenn es Coral nicht mehr gibt, soll Coral im Shop nicht mehr wählbar sein (Joerg, 11.09.2026). Die Ability löscht zuerst alle Variationen, die den Wert tragen, und nimmt ihn danach aus der Attributliste, der Term-Zuordnung und einer etwaigen Vorauswahl des Produkts. Alle anderen Attribute und Werte bleiben, wie sie sind.
• Bisher ging das nicht: Ein Löschen einzelner Variationen gab es nicht, und wc-update-product ersetzt die Attributliste immer vollständig - wer damit eine Farbe entfernt, muss alle übrigen Attribute mitschicken und riskiert, dass Variationen ihre Achse verlieren.
• Die Reihenfolge ist fest und nicht umkehrbar. Scheitert eine Löschung, bleibt der Wert am Produkt und ein zweiter Aufruf versucht es erneut. Den letzten Wert eines Attributs entfernt die Ability nicht, dafür ist wc-delete-product da.
• dry_run: true meldet nur, welche Variationen gelöscht würden. Die Antwort nennt IDs und SKUs der gelöschten Variationen und die verbleibenden Werte.
• Rückweg, wenn der Wert wiederkommt: wc-update-product mit attributes_mode: "merge", danach wc-create-variation.

v3.44.0

Hinzugefügt

• Artikelstatus des Lieferanten je Variation (apps-v2 #1086). wc-update-variation nimmt artikel_status (kurzer Zahlencode, leer oder null löscht) und legt ihn als Variations-Meta _idf_artikel_status ab; wc-list-variations gibt ihn mit zurück. Bei ID Identity ist das der ItemCategoryCode: 100 Standard, 150 neu, 900 läuft aus, 901 manuelle Beschaffung, 903 verkauft und nicht geliefert, 905 ausgelaufen mit Bestand, 910 ausgelaufen ohne Bestand. Der Adapter legt den Code nur ab und deutet ihn nicht; was daraus im Frontend wird, entscheidet idf-woo-addons (901 ohne Bestand wird „Auf Anfrage"). Geschrieben wird er vom Bestands-Flow der IDF-Apps, wie zulauf_datum und zulauf_menge auch. Die Batch-Form kann das Feld mit, weil sie dasselbe Feldset benutzt.

v3.43.1

Behoben

• wc-update-variation wies einen leeren zulauf_menge ab (#52). Das Schema deklarierte das Feld als integer, waehrend Beschreibung, CHANGELOG und Handler den Leerwert als "Meta loeschen" fuehren - die Validierung schlug also zu, bevor der Handler ueberhaupt drankam (400 Bad request … ist nicht vom Typ integer). Der Typ ist jetzt integer | string | null; der Handler sanitisiert wie bisher selbst. Aufgefallen im Bestands-Flow der IDF-Apps (shop-bestand-woo), der fuer jede Variante mit Lieferantenzeile ohne Zulauf einen Leerwert schickt und deshalb seit dem naechtlichen Lieferanten-Import bei jedem Takt abbrach.

v3.43.0

Hinzugefügt

• Prüfzeitpunkt des Bestands-Syncs am Produkt (#51). wc-update-product nimmt bestand_geprueft (ISO 8601, leer löscht) und legt es als Produkt-Meta _idf_bestand_geprueft ab; wc-get-product gibt es mit aus. Ein Wert je Produkt, weil der Sync alle Variationen eines Produkts in einem Aufruf prüft. Schreiber ist der Bestands-Flow der IDF-Apps, Leser idf-woo-addons („geprüft: 07.09.2026, 19:26" hinter der Lagerampel).

v3.42.0

Hinzugefügt

• Zulauf und Lieferrückstand je Variation (#50). wc-update-variation nimmt backorders (no, notify, yes), zulauf_datum (YYYY-MM-DD) und zulauf_menge. Die beiden Zulauf-Werte liegen als Variations-Meta _idf_zulauf_datum und _idf_zulauf_menge; ein leerer Wert löscht, ein Datum in anderer Form wird nicht geschrieben. wc-list-variations gibt alle drei mit aus, damit ein Sync nur Abweichungen schreibt. Geschrieben wird das vom Bestands-Flow der IDF-Apps (toni-tool-n8n shop-bestand-woo), gelesen von idf-woo-addons für „Wieder verfügbar ab" und den Vorbestell-Button.

v3.41.0

Entfernt

• upload-file-chunked ist weg (#47). Eine Datei stückweise als Base64 durch das Protokoll zu schieben war fehleranfällig - drei Schritte mit Session-ID, rund dreißig Aufrufe für ein 390-KB-PDF - und in der Praxis unnötig: Material steht beim Lieferanten unter einer URL, und die holt der Server mit upload-media in einem Aufruf. Im Audit-Log steht außer dem Test dieser Session kein einziger Aufruf. Die Hilfsfunktionen und der stündliche Cleanup-Cron sind mit entfallen; ein aus früheren Versionen geplanter Zeitplan wird beim nächsten Laden einmalig abgeräumt.
• upload-file (eigener Ordner) und list-directory bleiben unverändert - sie betreffen den konfigurierten Ordner, nicht die Mediathek.

Geändert

• Der Beschreibungstext von upload-media benennt jetzt den Normalfall: Quell-URL aus dem Lieferanten-Feed oder ein Freigabelink; die data:-URI bleibt für kleine Dateien wie SVG-Symbole. Eine Datei vom eigenen Rechner durch das Protokoll zu schieben ist ausdrücklich der falsche Weg.

v3.40.2

Behoben

• addons-assign-group meldete Erfolg mit leerem Ergebnis. Wird eine Gruppe zugewiesen, die noch ein Entwurf ist, speichert das Plugin sie zwar, gibt sie aber nicht zurueck - es beruecksichtigt nur veroeffentlichte Gruppen. Die Antwort las sich dadurch wie "nichts passiert". Sie nennt jetzt gespeichert (was geschrieben wurde) neben nachher (was davon wirkt) und weist Entwuerfe unter nicht_veroeffentlicht samt Hinweis aus. Beim Smoke von v3.40.1 aufgefallen (#46).

v3.40.1

Behoben

• Die Produktliste einer Addon-Gruppe blieb leer. addons-list-groups und addons-get-group suchten die zugewiesenen Produkte mit einem LIKE auf die Gruppen-ID im Postmeta - dort steht aber ein serialisiertes Integer-Array, also ohne die Anfuehrungszeichen, auf die das Muster passte. Jetzt werden die Produkte mit Zuweisung geholt und ueber die Plugin-Funktion geprueft; das trifft auch nicht mehr zufaellig eine ID, die als Teilstring in einer anderen vorkommt. Beim Smoke von v3.40.0 aufgefallen (#46).

v3.40.0

Hinzugefügt

• Pack für IDF Woo Addons (Gruppe „Produkt-Addons" im Reiter WooCommerce, nur mit aktivem Plugin): addons-list-field-types nennt die neun Feldtypen samt der Angaben, die je Typ nötig sind; addons-list-groups und addons-get-group lesen die Feldgruppen inklusive der normalisierten Felddefinition; addons-create-group und addons-update-group legen sie an und ändern sie; addons-assign-group weist sie einem Produkt zu. Bisher war jede Veredelung, jeder Namensaufdruck und jede Zusatzleistung Handarbeit im Backend (#46).
• Alles läuft über die öffentlichen Klassen des Plugins (Idf_Woo_Addons_Groups, Idf_Woo_Addons_Fields), nie am Postmeta vorbei - sonst umgeht man die Normalisierung der Felddefinition.
• Vorgeschaltete Prüfung der Feldliste, die das Plugin selbst nicht macht: unbekannter Feldtyp, doppelter Schlüssel, fehlendes Label, und ein Auswahlfeld ohne options. Letzteres fiele sonst erst der Kundschaft auf - als leeres Dropdown.
• addons-update-group ersetzt die Feldliste (wie das Plugin selbst) und nennt in der Antwort die entfallenen Felder. addons-assign-group lehnt eine Variations-ID mit dem Hinweis auf das Elternprodukt ab; dort hängen die Addons.

Geändert

• Die Mediathek steht jetzt an einer Stelle. Die Gruppe „Mediathek" (auflisten, ändern, löschen) ist vom Reiter Inhalte in den Reiter Uploads gewandert, direkt neben „Mediathek-Upload". Die Zugriffsstufen bleiben unverändert - es wechselt nur der Reiter, unter dem die Gruppe steht (#45).
• update-media-meta ist wieder weg. Sie war eine Dublette von update-media, entstanden am selben Tag in v3.38.0. update-media kann jetzt alles, was sie konnte: attachment_id als Alias für media_id, leerer Wert löscht das Feld, und die Antwort enthält den Stand nach der Änderung. Beide Wege teilen sich dieselbe Schreiblogik (#45).

v3.39.0

Hinzugefügt

• wc-get-product zeigt, was seit 3.38.0 schreibbar ist: default_attributes (die Vorauswahl), downloads mit Name und Datei, download_limit, download_expiry sowie die Schalter virtual und downloadable. Beim Smoke von v3.38.0 fiel auf, dass sich das frisch Geschriebene nur im Backend nachsehen liess - eine Ability, deren Ergebnis man nicht lesen kann, ist nur halb da (#40, #42).

v3.38.1

Behoben

• default_attributes nahm einen Wert an, den es gar nicht gibt. Der interne Mapper faellt bei einem unbekannten Wert auf dessen Slug zurueck, deshalb lief {"Farbe":"Lila"} an einem Produkt ohne diese Farbe glatt durch - die Vorauswahl zeigte danach auf eine Kombination, die es im Shop nicht gibt, und die Produktseite startet wieder ohne Preis. Die Werte werden jetzt gegen die tatsaechlichen Auswahlwerte des Produkts geprueft; ein unbekannter Wert ist ein Fehler und nennt die moeglichen. Beim Smoke von v3.38.0 aufgefallen (#40).

v3.38.0

Hinzugefügt

• default_attributes in wc-create-product und wc-update-product - die Vorauswahl einer Variante, in Klartext ({"Farbe":"Weiss","Groesse":"M"}). Ohne sie startet die Produktseite ohne Preis und ohne Bild der Leitfarbe; bisher war das nach jedem Anlegen ein Handgriff im Editor. Ein Wert, den das Produkt nicht anbietet, ist ein Fehler mit der Liste der vorhandenen Attribute - keine stille Nichtsetzung. Leeres Objekt entfernt die Vorauswahl (#40).
• Alt-Text, Bildunterschrift und Beschreibung beim Upload - upload-media kennt jetzt alt_text, caption und description. Beim Upload steht der Text ohnehin fest (Produktname plus Farbe), er wurde nur nicht geschrieben; allein PRO Wear bringt 1.316 Produktbilder mit, die man nicht nachträglich in der Mediathek pflegt (#41).
• update-media-meta - dieselben Felder für Medien, die schon in der Mediathek liegen. Ohne das müsste man ein Bild neu hochladen, nur um einen Alternativtext nachzutragen. Leerer Wert löscht das jeweilige Feld, die Antwort gibt den Stand danach zurück (#41).
• Herunterladbare Dateien - downloads (Name plus URL je Datei), download_limit und download_expiry an Produkt-Create und -Update. Dateien ohne den Schalter downloadable wären unsichtbar, deshalb setzt der Adapter ihn mit und meldet das als downloadable_gesetzt (#42).
• Der Beschreibungstext von shipping_class nennt jetzt den Weg für neue Versandklassen: create-taxonomy-term mit product_shipping_class (#42).

v3.37.1

Behoben

• list-taxonomy-terms gab mit orderby: menu_order eine leere Liste zurueck, wenn kein einziger Term der Taxonomie einen Sortierwert traegt - bei pa_farbe also alle elf Terme verschluckt, obwohl total 11 meldete. Ursache war die Term-Query: ein meta_key filtert Terme ohne diesen Wert heraus, und der OR-Zweig mit NOT EXISTS half nicht. Die Sortierung nach menu_order laeuft jetzt in PHP; Terme ohne Wert stehen hinten, statt zu verschwinden. Beim Smoke von v3.37.0 aufgefallen (#39).

v3.37.0

Hinzugefügt

• wc-update-attribute - Typ und Sortierung eines bestehenden globalen Attributs waren bisher nicht erreichbar: wc-create-attribute ist idempotent und gibt einen vorhandenen Slug unverändert zurück. Am 05.09.2026 stand pa_groesse auf der falschen Sortierung, die Korrektur war ein Handgriff im Backend. Ziel per attribut_id oder slug, setzbar sind Name, Typ (select, mit Avada auch avada_color, avada_button, avada_image), Sortierung und Archivseiten. Die Antwort nennt vorher und wc-create-attribute0 (#38).
• Der Slug bleibt bewusst gesperrt: er ist der Taxonomiename, ein Wechsel hängt alle Term-Zuordnungen ab und macht die Variationen eines variablen Produkts unbrauchbar. Nach dem Ändern wird wc_attribute_taxonomies aus dem Transient geworfen, sonst zeigt der Shop bis zum nächsten Cache-Lauf den alten Typ.
• list-taxonomy-terms - listet die Terme jeder registrierten Taxonomie (product_cat, pa_*, faq_category, Versandklassen, Lieferzeiten). Bisher gab es nur list-categories und list-tags, beide fest verdrahtet; für alles andere blieb die öffentliche Store-API, und die zeigt nur Terme, an denen Produkte hängen - ein frisch angelegtes Attribut liefert dort eine leere Liste, obwohl die Terme existieren, und man legt Dubletten an. Mit meta: true kommen die Term-Meta mit, also auch der Hex-Wert eines Farb-Attributs (#39).
• Sortierung nach menu_order nimmt den Meta-Key der jeweiligen Taxonomie und lässt Terme ohne Wert trotzdem in der Liste, statt sie herauszufiltern.
• position je Attribut in wc-create-product und wc-update-product - die Reihenfolge der Attribute am Produkt ist damit setzbar und nicht mehr nur die Reihenfolge des übergebenen Arrays (#42).

Behoben

• wc-update-product löschte Attribute stillschweigend. attributes ersetzt die Liste vollständig - wer eines nachträgt und die vorhandenen nicht mitschickt, verliert sie, und bei einem variablen Produkt verlieren die Variationen damit ihre Achse. Das Verhalten bleibt (alles andere wäre ein stiller Semantikwechsel), aber es steht jetzt im Beschreibungstext, der Verlust wird in derselben Antwort benannt (attributes_entfallen plus Klartext-Hinweis), und mit attributes_mode: "merge" bleiben vorhandene Attribute erhalten (#43).

v3.36.1

Behoben

• acf-sync-get-status und acf-sync-snapshot-now brachen mit "Cannot use object of type stdClass as array" ab - beide deklarierten ihr leeres Eingabeschema als 'properties' => new stdClass(). Die Validierung im Gateway greift auf properties als Array zu; ein Objekt führt dort zum Fatal, bevor der execute_callback überhaupt läuft. Beim Live-Smoke von v3.36.0 aufgefallen. Jetzt 'properties' => array(), wie bei allen anderen parameterlosen Abilities (seo-get-sitemap, list-widgets, health-check).
• Dieselbe Schreibweise steht noch in borlabs-get-config und borlabs-check-config - beide sind seit ihrer Einführung nicht aufrufbar. Als #44 aufgenommen, nicht in diesem Release mitgeändert.

v3.36.0

Hinzugefügt

• Der bidirektionale ACF-Sync ist über MCP lesbar und steuerbar - neue Ability-Gruppe acf_sync (Reiter "ACF & Felder") mit elf Abilities für das Plugin IDF ACF Bidirectional Sync. Registriert wird sie nur, wenn dieses Plugin aktiv ist (IDF_ACF_SYNC_VERSION). Bisher war der Zustand des Sync aus einer Redaktionssession heraus unsichtbar: Ob ein Feld-Paar überhaupt konfiguriert und aktiv ist, stand ausschließlich im Backend unter IDF Home, und die Nacharbeit an einseitigen Verknüpfungen war ein Klick auf der Einstellungsseite (idf-acf-bidirectional-sync #7).
• Lesend, ab Stufe "Nur Lesen": acf-sync-list-pairs (konfigurierte Feld-Paare mit Aktiv-Schalter), acf-sync-get-status (Version, Anzahl Paare, Auto-Cleanup, letzter Snapshot-Build, ob der Sync-Hook hängt) und acf-sync-detect-pairs (Auto-Erkennung, je Kandidat mit configured und active).
• Schreibend, ab Stufe "Lesen & Bearbeiten": acf-sync-add-pair, acf-sync-update-pair (Aktiv-Schalter), acf-sync-delete-pair, acf-sync-sync-post (kontrollierter Sync für einen einzelnen Post), acf-sync-reconcile-pair (Spiegeln über den ganzen Bestand), acf-sync-snapshot-now und acf-sync-update-settings.
• Auf Admin-Stufe: acf-sync-unmirror-pair nimmt die vom Plugin erzeugten Spiegelungen zurück und lässt von Hand gepflegte Verknüpfungen stehen.
• acf-sync-sync-post schließt die praktische Lücke hinter dem Befund, dass acf/save_post bei Schreibzugriffen über den Adapter nicht feuert: Nach update-cpt oder update-acf-fields zieht ein Aufruf die Gegenseite nach. Derselbe Hinweis steht in der Antwort von acf-sync-get-status, damit er dort auffällt, wo man sucht.
• Feldnamen werden gegen die Relationship- und Post-Object-Felder der aktiven ACF-Feldgruppen geprüft, Post-Typen gegen post_type_exists(). Ein Tippfehler im Feldnamen legt kein totes Paar an, sondern kommt als Fehler mit der Liste der möglichen Felder zurück.
• Ein Paar wird über den richtungsunabhängigen pair_key adressiert; alternativ lassen sich die vier Endpunkte einzeln übergeben. Alle Abilities laufen ausschließlich über die öffentlichen Funktionen des Sync-Plugins, damit MCP-Weg und Backend-Weg dieselbe Anti-Kaskaden- und Snapshot-Behandlung bekommen.

v3.35.0

Hinzugefügt

• GTIN, EAN, UPC und ISBN sind setzbar - neues Feld gtin in wc-create-product, wc-update-product, wc-create-variation und wc-update-variation (dort flach wie in der Batch-Zeile). Geschrieben wird WooCommerces _global_unique_id, also dasselbe Feld wie im Reiter Inventar. Ohne GTIN bleibt der Google-Shopping- und Preisvergleichs-Export zu; bei den drei ID-Identity-Pilotprodukten lagen für alle 190 Variationen EANs vor, im Shop stand keine einzige (#37).
• Der Wert wird geprüft, nicht stillschweigend übernommen: Bindestriche und Leerzeichen fallen weg (so kommen sie aus Lieferantenlisten), übrig bleiben müssen 8 bis 14 Ziffern. Alles andere ist ein Fehler mit Klartext. Eine halb gelesene Nummer im Feed ist schlimmer als gar keine.
• Kompatibel nach unten: set_global_unique_id() gibt es ab WooCommerce 9.2, ältere Stände bekommen denselben Wert über die Meta-Ablage des CRUD-Objekts.
• wc-get-product, wc-list-variations und die Antwort von wc-create-variation geben die GTIN jetzt mit aus - sonst ließe sich das Gesetzte nur im Backend nachsehen.

v3.34.1

Behoben

• menu_order schrieb bei Attribut-Termen den falschen Meta-Key. WooCommerce Core führt die Sortierung von Attribut-Termen unter order_<taxonomy>, gelesen wird auf ihre-ideenfabrik.de aber order: die zehn pa_groesse-Terme tragen dort XS 1, S 2, 2XL 6, 6XL 10, und die Reihenfolge im Shop stimmt, während order_pa_groesse an keinem Term existiert. Ein Wert nur unter dem langen Key wäre wirkungslos geblieben. Attribut-Terme bekommen jetzt beide Keys mit demselben Wert, alles andere weiter nur order (#36).
• Der Beschreibungstext von menu_order sagt jetzt auch, dass die Reihenfolge nur dann stimmt, wenn ALLE Terme einer Achse einen Wert bekommen - Terme ohne Wert rutschen sonst nach vorn.

v3.34.0

Hinzugefügt

• wc-update-variation kennt jetzt eine zweite Form: variations, eine Liste mit eigener Nutzlast je Variation (variation_id plus die Felder dieser Zeile, höchstens 200 je Aufruf). Die bisherige Form (flache Felder plus variation_ids) bleibt unverändert und ist weiter richtig für „setze bei allen dasselbe". Sind beide gesetzt, gewinnt variations; die flachen Felder gelten dann als Vorgabe für alle Zeilen und werden vom Wert der Zeile überschrieben. Anlass: Die Variationsbeschreibungen der drei ID-Identity-Pilotprodukte nachzutragen kostete 190 Einzelaufrufe, weil der Text Farbe und Größe enthält und damit je Variation eindeutig ist. Mit der Batch-Form sind es drei (#35).
• Ein flaches attributes wird in der Batch-Form abgelehnt statt still angewendet - es würde allen Variationen dieselbe Kombination geben und damit ihre Identität einebnen. Doppelte variation_id in derselben Nutzlast melden ebenfalls einen Fehler, statt einen der beiden Werte zu verschlucken.
• create-taxonomy-term und update-taxonomy-term schreiben Term-Meta (meta) und Sortierreihenfolge (menu_order). Damit sind der Hex-Wert eines Farb-Attributs, Bilder an Termen und die Reihenfolge von Größen ohne Backend erreichbar; bisher kannten beide nur Name, Slug, Beschreibung und Parent (#36).
• Ein Objekt-Wert wird in ein vorhandenes Array-Meta gemischt statt es zu ersetzen. Grund: Avada legt Farbe, Bild und Beschriftung eines Attribut-Terms gemeinsam unter dem Term-Meta _fusion ab - flach überschrieben wäre das Bild mit dem Hex-Wert weg. Ein leerer Wert löscht das Meta, sonst bliebe ein falscher Hex für immer stehen.
• menu_order wählt den Meta-Key selbst: order_<taxonomy> bei Attributen (pa_*), sonst order. WooCommerce führt ihn je Taxonomie anders, und ein geratener Key schreibt an eine Stelle, die niemand liest.
• Die Antwort von update-taxonomy-term enthält bei Meta-Änderungen alle Term-Meta des Terms. So sieht man ohne Backend, unter welchem Key ein Theme seine Werte tatsächlich ablegt.

Geändert

• Beide Formen von wc-update-variation laufen über denselben Kern (idf_mcp_wc_update_one_variation()), und das Feldset steht nur noch einmal im Code (idf_mcp_wc_variation_update_props()). Zwei Kopien wären zwei Orte für jeden späteren Fix. Die Antwort nennt jetzt zusätzlich mode (single oder batch).

v3.33.1

Behoben

• Die Texte des PDF-Packs (Gruppenbeschreibung, Labels, Ability-Beschreibungen, Fehlermeldungen) schrieben „Eintraege", „hoechstens" und „ueber" statt Umlaute. Sichtbare Plugin-Texte sind Deutsch mit Umlauten; nur Identifier bleiben ASCII (#34).

v3.33.0

Hinzugefügt

• Neues Pack für IDF PDF Thumbnail (Gruppe „PDF-Dokumente" im Tab Inhalte, nur mit aktivem Plugin): pdf-list listet die Einträge des CPT idf_pdf mit PDF-Datei, Vorschaubild und den Flags pdf_exists / has_thumbnail; pdf-set-file ordnet ein Attachment als PDF zu und prüft vorher MIME-Typ und Datei auf dem Server; pdf-generate-thumbnail erzeugt Vorschaubilder über IDF_PDF_Thumbnail_Thumbnail::generate(), höchstens zehn Einträge je Aufruf, mit Ergebnis oder Fehlergrund je Eintrag.
• Ein altes Vorschaubild löscht das Plugin nicht. Die Antwort nennt es als previous_thumbnail_id, damit das Aufräumen per delete-media folgen kann.
• Anlass: Beim Datenblatt-Abgleich auf stucco-pompeji.com blieben 55 neue Einträge ohne Bild, weil das Plugin die Erzeugung nur an einen Admin-Nonce und die Sammelaktion in edit.php hängt. Die PDF-Zuordnung lief bis dahin über den Umweg update-acf-fields mit dem Meta-Key _idf_pdf_file_id (#34).

v3.32.1

Behoben

• Die Aktivierung konnte eine ganze Website lahmlegen. Der Dependency-Checker heißt jetzt IDF_MCP_Dependency_Checker statt des geteilten IDF_Dependency_Checker, den fast alle IDF-Plugins mitbringen. Auf k1.de war IDF Tweaks der einzige Deklarierer der geteilten Klasse; dessen return-Guard läuft unter OPcache nie, weil die Klasse im Cache früh gebunden ist und vor der ersten Codezeile in die Klassentabelle kommt. Sobald der Adapter alphabetisch davor lud und die Klasse deklarierte, starb jeder Request mit „Cannot declare class IDF_Dependency_Checker". Die Aktivierungs-Sandbox fängt das nicht, der Fatal kommt erst im Folge-Request. Mit dem eigenen Namen fasst der Adapter die geteilte Klasse nicht mehr an (#33).
• Dateikopf des Checkers korrigiert: die Ursache ist das Early Binding beim Kompilieren, nicht OPcache-Preloading. Checker-Datei jetzt v1.6.0.

v3.32.0

Hinzugefügt

• delete-taxonomy-term - schließt die Lücke neben create-taxonomy-term und update-taxonomy-term. Aufräumen endete bisher immer im Backend.
• Der Riegel ist die eigentliche Arbeit: Hängen noch Objekte am Term, bricht die Ability ab und nennt Anzahl und bis zu zehn Beispiel-IDs. Grund: einen belegten Term zu löschen entfernt ihn aus jedem Objekt, das ihn nutzt - bei einem Produkt-Attribut verlieren die betroffenen Variationen dadurch ihre Achse und werden unbrauchbar. Erst force: true löscht trotzdem, und die Antwort weist das als erzwungen aus.
• Gezählt wird über get_objects_in_term() statt über den count-Zähler des Terms - der ist bei Attribut-Taxonomien nicht verlässlich.
• Bei pa_*-Termen werden nach dem Löschen die Produkt-Transients der betroffenen Produkte geleert, sonst zeigt der Shop eine Auswahl weiter, die es nicht mehr gibt.

v3.31.0

Hinzugefügt

• wc-list-attributes - listet die globalen Produkt-Attribute (pa_*) mit ID, Taxonomie-Slug, Klartextname, Typ, Sortierung und Anzahl der Terme, auf Wunsch samt Termen. Bisher ließ sich nur raten, welche Attribute ein Shop führt; ein falscher Slug kostete jedes Mal einen Fehlversuch.
• wc-create-attribute - legt ein globales Attribut über wc_create_attribute() an. Ein bereits vorhandener Slug kommt unverändert zurück statt eines Fehlers. Löschen ist bewusst nicht enthalten: an einem Attribut hängen Terme und Produktzuordnungen.
• Die neue Taxonomie wird direkt nach dem Anlegen registriert. Ohne diesen Schritt registriert WooCommerce sie erst beim nächsten Seitenaufruf, und ein unmittelbar folgendes create-taxonomy-term scheitert an „Taxonomie existiert nicht".

v3.30.2

Behoben

• Das Umhaengen einer Variation scheiterte bei Custom-Attributen. Die Pruefung „wird der Wert am Elternprodukt angeboten?" verglich einen unslugifizierten Wert gegen slugifizierte Optionen - 200 x 80 mm gegen 200-x-80-mm - und wies gueltige Werte ab. Bei globalen pa_*-Attributen fiel das nie auf, weil dort beide Seiten Term-Slugs sind. Jetzt wird auf beiden Seiten normalisiert.
• Die Fehlermeldung listet die vorhandenen Werte wieder lesbar („200 x 80 mm") statt als Slug („200-x-80-mm").

v3.30.1

Behoben

• wc-create-variation hat virtual und downloadable stillschweigend verworfen. Beide Felder gab es nur an wc-update-variation; beim Anlegen wurden sie kommentarlos ignoriert, die Antwort meldete trotzdem Erfolg. Wer eine virtuelle Variation anlegen wollte, bekam eine versandpflichtige und merkte es erst im Shop. Aufgefallen beim Nachweis zu #29: die Testvariationen waren gar nicht virtuell, deshalb blieb der erwartete Hinweis aus.

v3.30.0

Hinzugefügt

• German-Market-Lieferzeit setzbar - neues Feld delivery_time in wc-update-product und wc-update-variation. Nimmt einen Namen oder eine Term-ID aus der Taxonomie product_delivery_times. German Market führt die Lieferzeit zweigleisig: Term in der Taxonomie und Post-Meta _lieferzeit mit der Term-ID; die Anzeige im Shop richtet sich nach der Meta. Beides wird jetzt gemeinsam gesetzt - die Term-Zuweisung allein blieb bisher unsichtbar. Leerer Wert setzt auf „nicht angegeben" (-1) zurück.
• Fehlende Lieferzeiten legt die Ability bewusst nicht selbst an, sondern bricht mit der Liste der vorhandenen ab. Welche Lieferzeiten ein Shop anbietet, ist eine Entscheidung; zum Anlegen gibt es create-taxonomy-term.
• virtual und downloadable auch am Produkt. Beide gab es bisher nur an Variationen. Ohne sie ließ sich ein Produkt, das beim Typwechsel seine Virtualität verloren hat, über die Schnittstelle nicht reparieren.

Geändert

• Der Typwechsel meldet verlorene virtual/downloadable-Eigenschaften. Bei einem variablen Produkt hängen sie an den Variationen; nach dem Wechsel auf simple liest das neue Objekt sie aus der eigenen Meta und findet nichts. Das Produkt verlor die Eigenschaft still und bekam plötzlich Versandoptionen. Die Ability merkt sich jetzt vor dem Wechsel, was an den Variationen hing, und weist in hinweise darauf hin - samt der Angabe, wie man es wieder setzt.
• Die Fehlermeldung beim Umhängen einer Variation nennt den richtigen Weg. Fehlt der Zielwert am Elternprodukt, verwies sie pauschal auf wc-update-product. Bei einem globalen pa_*-Attribut ist das der schlechtere Weg, weil attributes dort alle Attribute des Produkts ersetzt. Bei Taxonomie-Attributen verweist die Meldung jetzt auf set-post-terms und nennt die Taxonomie; bei Custom-Attributen bleibt es bei wc-update-product. Dazu der Hinweis, dass term_ids kommagetrennt ist und Term-Namen selbst ein Komma enthalten können („1,5 kg") - beim Ersetzen also Term-IDs übergeben.

v3.29.0

Hinzugefügt

• wc-update-product kann den Produkttyp wechseln - neues Feld type (simple, variable, grouped, external). Umgesetzt über wc_get_product_object() plus save(); WooCommerce zieht den product_type-Term in update_version_and_type() selbst nach. Der Wechsel passiert vor dem Anwenden der übrigen Felder, sonst gingen sie beim Klassenwechsel verloren.
• Zwei stille Fallen werden dabei benannt statt verschwiegen: Beim Wechsel auf simple meldet die Antwort, wenn das Produkt danach keinen Preis hat - ein variables Produkt führt am Elternteil keinen. Und sie sagt, wie viele Variationen liegen bleiben; gelöscht wird nichts, sie kommen zurück, wenn der Typ zurückgestellt wird. Das entspricht dem Verhalten im Backend.
• Neue Ability refresh-plugin-catalog (Gruppe Transients, Schreibrecht). Leert die Caches zwischen einem frischen IDF-Plugin-Release und seiner Sichtbarkeit auf der Kundenseite und prüft danach sofort neu. Läuft IDF Home, wird dessen clear_all_caches() aufgerufen - derselbe Weg wie der Knopf „Katalog aktualisieren"; ohne IDF Home werden die WordPress-Update-Caches geleert. Die Antwort nennt die tatsächlich gegangenen Wege und wie viele Plugin-Updates danach sichtbar sind.

Behoben

• Die Transient-Abilities erreichen jetzt Site-Transients. get-transient, set-transient und delete-transient haben ein Feld site (Standard false). Bisher liefen sie ausschließlich über get_transient() / set_transient() / delete_transient(); update_plugins, update_themes und set-transient0 liegen aber als Site-Transients in einer eigenen Option und waren damit unerreichbar. set-transient1 meldete dabei set-transient2 und löschte einen Schlüssel, den es gar nicht gibt.
• Beim Löschen von update_plugins mit site: true wird zusätzlich wp_clean_plugins_cache() aufgerufen. Nur den Transient wegzunehmen genügt nicht, weil WordPress daneben noch die Plugin-Liste hält.
• Die Antworten der drei Abilities geben site mit zurück, damit erkennbar ist, welche Variante gegriffen hat.

v3.28.0

Hinzugefügt

• wc-update-variation kann die Attribut-Kombination ändern - neues Feld attributes in Klartext, z. B. {"Menge":"5 kg"}. Damit lässt sich ein Gebinde umbenennen, ohne die Variation neu anzulegen; Variations-ID, SKU, Lagerdaten, Bestellzuordnung und Kundengruppen-Preise bleiben erhalten. Bisher ging das nur im Backend.
• Drei Prüfungen vor dem Schreiben, weil die Kombination die Identität einer Variation ist: das Attribut muss am Elternprodukt eine Varianten-Achse sein, der Zielwert muss dort als Auswahlwert angeboten werden, und keine andere Variation darf die Ziel-Kombination schon belegen. Jede Prüfung bricht mit einer Meldung ab, die sagt was fehlt - bei einem unbekannten Wert inklusive der Liste der vorhandenen.
• attributes ist nur bei genau einer Ziel-Variation erlaubt. Mehrere Variationen auf dieselbe Kombination zu setzen wäre immer falsch und wird vorab abgewiesen.
• Fehlende Auswahlwerte legt die Ability bewusst nicht selbst an: was ein Produkt zur Auswahl stellt, ist eine Entscheidung und wird über wc-update-product gepflegt.

Geändert

• Nur die übergebenen Achsen werden geändert, der Rest der Kombination bleibt stehen.
• Der Mapper aus wc-create-variation (idf_mcp_wc_map_variation_attributes()) wird wiederverwendet statt einer zweiten Fassung.

v3.27.0

Behoben

• B2B-Market-Pack erkennt die tatsächliche Speicherform. In v3.26.0 galt ein Meta-Wert nur dann als Gruppenpreis, wenn er numerisch war. B2B Market speichert aber serialisiert - am 02.09.2026 auf stucco-pompeji.com (B2B Market 2.2.1) belegt: bm_handwerker_group_prices enthält a:1:{i:0;a:2:{s:11:"group_price";s:5:"21.50";s:16:"group_price_type";s:3:"fix";}}. Die Erkennung fand deshalb keine einzige Vorlage, und der Schreibpfad brach immer ab.
• Neue Haupterkennung am Key-Muster bm_{gruppe}_group_prices, die den Wert entpackt und Preis samt Preisart liest. Die alte Erkennung über Rollen-Token in numerischen Werten bleibt als Fallback für abweichende Versionen.
• Kundengruppen werden nicht mehr gegen die Rollenliste erzwungen: B2B Market führt neben echten Rollen eigene Pseudogruppen (guest). b2b-list-customer-groups gibt sie jetzt mit aus und markiert je Gruppe, ob sie eine WordPress-Rolle ist.

Geändert

• b2b-set-group-price hat andere Eingabefelder. Statt regular_price / sale_price / meta_key_regular / meta_key_sale jetzt price, price_type und meta_key. Grund: B2B Market führt je Gruppe einen Preis mit einer Preisart, keinen getrennten Angebotspreis. Die Felder aus v3.26.0 bildeten eine Struktur ab, die es nicht gibt; sie waren nie funktionsfähig, weil der Schreibpfad in v3.26.0 ohnehin immer abbrach.
• Beim Schreiben bleiben vorhandene Zusatzfelder der Preiszeile erhalten, es werden nur Preis und Preisart gesetzt. Staffelpreise werden nicht angefasst.
• b2b-set-group-price gibt vorher, gesetzt und gelesen zurück - der Nachweis, dass der Wert wirklich steht.
• mit_rohdaten bei b2b-get-group-prices steht jetzt standardmäßig auf false; die Rohausgabe ist ein Diagnosewerkzeug und blähte die normale Antwort auf.

v3.26.0

Hinzugefügt

• B2B-Market-Pack - neue Ability-Gruppe b2b_market (Tab WooCommerce, Standard „Nur Lesen"). Gruppe und Abilities erscheinen nur, wenn B2B Market (MarketPress) aktiv ist. - Neue Ability b2b-list-customer-groups: listet die WordPress-Rollen, die als Kundengruppe in Frage kommen, sagt je Rolle ob im Shop Gruppenpreise dafür hinterlegt sind, und gibt die erkannten Meta-Key-Vorlagen aus. - Neue Ability b2b-get-group-prices: Gruppenpreise eines Produkts oder einer Variation, bei variablen Produkten inklusive aller Variationen. Gibt zusätzlich alle Meta-Schlüssel aus, die nicht von WooCommerce stammen - damit bleibt auch eine abweichende Speicherform sichtbar statt unauffindbar. - Neue Ability b2b-set-group-price: setzt Regular- und Angebotspreis je Kundengruppe, auf Produkt oder Variation. Leerer Wert löscht den Preis.
• Der Meta-Schlüssel wird nie geraten. B2B Market dokumentiert seine Speicherform nicht öffentlich und liegt nur als Quellcode auf der Kundeninstanz. Das Pack leitet die Schreibweise stattdessen aus einem Gruppenpreis ab, den es im Shop tatsächlich findet: Kundengruppen sind Rollen, ein Meta-Key mit einem Rollen-Slug als eigenem Token und numerischem Wert ist ein Gruppenpreis, daraus entsteht die Vorlage. Fehlt die Vorlage oder ist sie mehrdeutig, bricht der Schreibpfad mit Meldung ab, statt einen erfundenen Key ins Postmeta zu schreiben.
• Nach dem Schreiben werden die WooCommerce-Produkt-Transients des Elternprodukts geleert, damit Preisanzeige und Preisspanne nicht auf altem Stand stehen bleiben.

v3.25.0

Geändert

• Admin-Menü folgt der IDF-Menükonvention: Läuft IDF Home, hängt der MCP-Adapter als ein einzelner Eintrag darunter, sonst bleibt das eigene Top-Level-Menü mit Icon und Position 3.1 wie bisher. Einstellungen, Hilfe und Deinstallation sind jetzt Reiter statt drei Untermenüpunkte. Alle bisherigen URLs funktionieren unverändert.
• Berechtigungsprüfung je Seite kommt aus der neuen idf_mcp_seiten()-Funktion, die auch die Reiterleiste versorgt. Die drei Seiten-Callbacks prüfen die Berechtigung jetzt selbst; bisher verließen sie sich allein darauf, dass WordPress den Menüpunkt ausblendet.
• idf_mcp_fix_menu_highlight() ersetzt durch idf_mcp_menue_aufklappen() und idf_mcp_eintrag_markieren(), die beide Konstellationen abdecken.

v3.24.0

Hinzugefügt

• Steuer-Pack für WooCommerce - neue Ability-Gruppe wc_taxes (Tab WooCommerce, schaltbar wie jede andere Gruppe, Standard „Nur Lesen"). - Neue Ability wc-list-tax-rates: alle Steuerklassen inklusive Standard, je Klasse die Satz-Zeilen (Land, Bundesland, Satz, Name, Priorität, Versand-Flag, PLZ/Ort). Meldet zusätzlich, ob die Steuerberechnung im Shop überhaupt aktiv ist, ob die Preise inklusive Steuer gepflegt werden und welches Land als Shop-Standort gilt. - Neue Ability wc-create-tax-class: legt eine Steuerklasse per Klartext-Name an und gibt ihren Slug zurück. Existiert sie schon, kommt sie unverändert zurück statt eines Fehlers. - Neue Ability wc-create-tax-rate: legt eine Satz-Zeile in einer Klasse an (Land, Satz, Name, Priorität, Versand, Bundesland/PLZ/Ort optional). - Neue Ability wc-update-tax-rate: ändert eine bestehende Satz-Zeile per rate_id, nur übergebene Felder werden angefasst. - Beide Schreib-Abilities lesen die Zeile nach dem Speichern über ihre Klasse zurück und geben sie als saved mit. Damit ist belegt, dass der Satz wirklich in der gemeinten Klasse steht. - Bewusste Grenze: kein Löschen von Klassen oder Sätzen. Steuersätze hängen an vergangenen Bestellungen, das bleibt Backend-Arbeit.

Behoben

• Unbekannte Steuerklasse wird nicht mehr still verworfen. set_tax_class() nimmt in WooCommerce jeden Slug entgegen, wirft einen unbekannten weg und speichert das Produkt trotzdem - wc-update-product meldete daraufhin Erfolg, während das Produkt weiter im Standardsatz stand. Eine Massen-Umstellung sah damit erfolgreich aus, obwohl kein einziges Produkt die neue Klasse trug. wc-create-product, wc-update-product, wc-create-variation und wc-update-variation prüfen die Klasse jetzt vorher und antworten mit Fehler und der Liste der gültigen Slugs. Bei Variationen bleibt parent (= erbt vom Produkt) gültig.

Hintergrund: Auf thueringer-landkost.de sollten die Salat-Produkte auf 7% umgestellt werden. Der Shop hatte nur die Standard-Klasse (19%), eine ermäßigte Klasse gab es nicht - und der Adapter konnte sie weder sehen noch anlegen. Drei Schreibversuche meldeten success: true und änderten nichts.

v3.23.0

Geändert

• Integritaets-Schutz gegen unvollstaendige Installationen. Eine fehlende oder leer geschriebene Include-Datei legt nicht mehr die ganze Website mit einem Fatal Error lahm. Jede Include-Datei wird vor dem Laden geprueft (is_readable()), jede Registrierungsfunktion vor dem Aufruf (function_exists()). Betroffene Ability-Packs fallen einzeln aus, der Rest des Plugins laeuft normal weiter.
• Neue Referenztabelle idf_mcp_get_includes() (Include-Datei zu erwarteter Funktion). Sie erkennt auch den Fall, dass eine Datei zwar existiert, aber leer oder nur teilweise geschrieben ist - die haeufigste Folge eines abgebrochenen Updates. Eine reine Existenzpruefung wuerde so einen Fall durchwinken.
• Neuer Helper idf_mcp_call_pack() und neue Pruefung idf_mcp_check_integrity().
• Neue Admin-Notice idf_mcp_integrity_notice(): benennt betroffene Dateien und Funktionen im Klartext, damit ein Schaden nicht still bleibt. Prueft unabhaengig vom Hook-Timing direkt auf Datei- und Funktionsebene.
• Zusaetzlich abgesichert: Activation-Hook und der Require des Master-Key-Dependency-Checkers.

Hintergrund: Auf einer Kundenseite war includes/abilities-upload.php nach einem abgebrochenen Update leer. Der Aufruf von idf_mcp_register_upload_abilities() warf daraufhin einen E_ERROR, WordPress deaktivierte das Plugin und schickte die Seite in den Recovery-Modus. Mit diesem Release waeren nur die vier Upload-Abilities ausgefallen.

v3.22.0

Hinzugefügt

• Borlabs Cookie (Consent) Read-Pack - neues, rein lesendes Ability-Pack ueber die offizielle Borlabs PHP-API v3 (borlabsCookieApi()), conditional geladen (nur wenn Borlabs aktiv). Kein direkter Zugriff auf den Borlabs-Namespace oder die DB-Tabellen (vom Hersteller ausdruecklich untersagt). - Neue Ability borlabs-get-config: liest die auslesbare General- und Plugin-Konfiguration (robuster JSON-Roundtrip, unabhaengig von den Property-Namen) samt aktueller Sprache. - Neue Ability borlabs-check-config: prueft die lesbaren Grundeinstellungen heuristisch (Plugin-Status, Secure-/SameSite-Cookie, Consent-Lebensdauer ueber 12 Monate, Do-Not-Track) und meldet Befunde mit Schweregrad (critical/warning/info). - Neue Kategorie/Gruppe/Tab Consent, im Settings-UI nur sichtbar wenn Borlabs Cookie aktiv ist. - Bewusste Grenze: Die Borlabs-API gibt nur die globale Config her, NICHT die Zuordnung von Diensten zu Dienst-Gruppen oder das Consent-Ladeverhalten. Ob Tracking-Skripte erst nach Einwilligung laden, bleibt ein Frontend-Test der Seite.

v3.21.0

Hinzugefügt

• Neue Ability wc-update-variation (batch-faehig): aktualisiert bestehende Variationen eines variablen Produkts, gezielt per variation_ids oder ohne Angabe fuer ALLE Variationen des Produkts. Setzbar u.a. virtual (Versand pro Variation aus-/einschalten), downloadable, Preise, Lager, Gewicht, Versandklasse, Steuer, Beschreibung, Bild und enabled. Die Attribut-Kombination der Variation bleibt unveraendert.
• Schliesst die Luecke, dass Variationen bisher nur angelegt (wc-create-variation), aber nicht mehr geaendert werden konnten - insbesondere liess sich der pro Variation gesetzte „Virtuell"-Haken (= kein Versand) gar nicht per MCP schalten.
• Gemeinsamer Feld-Helper idf_mcp_wc_apply_variation_fields() (Setter-basiert, nur uebergebene Keys werden angefasst).

v3.20.1

Behoben

• upsell_ids / cross_sell_ids / brand akzeptieren jetzt Integer-IDs UND Strings (SKU bzw. Name). Zuvor liess das Schema nur Strings zu, sodass ein Aufruf mit numerischen IDs an der 0.5.0-Validierung scheiterte.

Hinzugefügt

• wc-get-product liefert die in v3.20.0 ergaenzten Felder jetzt auch zurueck (Lese-Symmetrie): upsell_ids, cross_sell_ids, featured, catalog_visibility, menu_order, date_on_sale_from/date_on_sale_to, backorders, sold_individually, upsell_ids0/upsell_ids1, upsell_ids2, upsell_ids3, upsell_ids4.

v3.20.0

Hinzugefügt

• WooCommerce Cross-/Up-Selling editierbar und das komplette Produkt-Feld-Set stark erweitert. wc-create-product und wc-update-product nutzen jetzt einen gemeinsamen Feld-Helper und koennen exakt dasselbe (bisher konnte update deutlich weniger als create). - Cross-/Up-Sell: upsell_ids, cross_sell_ids - referenzierbar per Produkt-ID ODER SKU (SKU wird im Plugin aufgeloest). - Neu bearbeitbar: Angebotszeitraum (date_on_sale_from/date_on_sale_to), catalog_visibility, featured, wc-update-product0, wc-update-product1, Galerie (wc-update-product2), Masse (wc-update-product3/wc-update-product4/wc-update-product5), wc-update-product6, wc-update-product7/wc-update-product8, wc-update-product9, update0, update1, Marke (update2 -> product_brand, Namen werden bei Bedarf angelegt) sowie die external-Felder update3/update4. - Paritaet: update5 beherrscht jetzt auch update6, update7, update8, update9, create0 (fehlten zuvor). - Speicherfehler (z.B. doppelte SKU, ungueltige Enum-Werte) werden sauber als Fehlermeldung zurueckgegeben statt als generischer Abbruch.

v3.19.0

Hinzugefügt

• Variable WooCommerce-Produkte werden jetzt vollstaendig unterstuetzt. Bisher legte wc-create-product bei type=variable nur eine leere Huelle ohne Attribute/Variationen an - in WooCommerce unverkaeuflich. - wc-create-product + wc-update-product: neuer attributes-Parameter (name, options, variation, visible) definiert die Varianten-Achsen. Globale pa_*-Attribute werden am Namen automatisch erkannt (fehlende Terme werden angelegt), sonst wird ein produkteigenes Custom-Attribut gesetzt. - Neue Ability wc-create-variation (batch-faehig): legt Variationen an einem variablen Produkt an, je mit Attribut-Kombination in Klartext plus Preis/SKU/Lager/Bild. Danach automatisch WC_Product_Variable::sync. Doppelte SKU o. ae. werden pro Variation sauber als Fehler gemeldet, der Rest wird trotzdem angelegt. - Neue Ability wc-list-variations: listet die Variationen eines variablen Produkts mit Attributen, Preis, SKU und Lager. - Die fiddelige WC-Attribut-Logik (pa_-Praefix, Umlaut-Slugs, global vs. custom, Term-Mapping) ist im Plugin gekapselt - KI-Agenten uebergeben nur Klartext-Namen und -Werte.

v3.18.0

Hinzugefügt

• upload-media: robuster Bild-Upload per URL. file_url ist jetzt der empfohlene, dokumentierte Weg (ein Call, kein MCP-Groessenlimit). Beschreibung umgestellt, damit KI-Agenten bei Bildern file_url statt Base64 waehlen. Base64 bleibt fuer sehr kleine Dateien; der Fehlertext verweist bei Problemen explizit auf file_url.
• upload-media-Download gehaertet: Browser-aehnlicher User-Agent + Accept-Header (manche CDNs / Generator-Assets blocken den Default-WP-UA mit HTTP 403), Redirect-Follow, Leer-Datei-Erkennung; data:-URIs werden in file_url akzeptiert; fehlende Datei-Endung wird bei Bildern aus dem Dateityp ergaenzt.
• upload-media: neue Parameter attach_to_post + set_as_featured. Hochgeladenes Bild in einem Call einem Beitrag zuordnen und direkt als dessen Beitragsbild setzen.
• Beitragsbild aus der Mediathek setzen: Neuer optionaler Parameter featured_image (Attachment-ID; 0 entfernt das Beitragsbild) in create-post, update-post, create-page, update-page, create-cpt und update-cpt. Zentral via wp_register_ability_args ins Schema eingehaengt, gesetzt via set_post_thumbnail() mit Validierung (Attachment muss ein Bild sein).

v3.17.7

Behoben

• Leeres {} bei parameterlosen Abilities scheiterte trotz v3.17.6 weiter ("input ist nicht vom Typ object"). Der mcp_adapter_pre_tool_call-Workaround war die falsche Ebene und zudem fehlerhaft: der Guard strpos($tool_name,'execute') griff nicht, weil $tool_name der MCP-Tool-Name ist und "execute" nicht garantiert enthaelt. Die eigentliche Ursache (am Quellcode verifiziert): die INNERE Ability erhaelt bei parameterlosem Aufruf null und lehnt das gegen ihr type: object-Schema ab (WP-Core WP_Ability::validate_input → rest_is_object(null) === false).
• Neuer zentraler Fix ueber wp_register_ability_args: Allen idf-mcp-provider/-Abilities mit type: object-Schema wird ein 'default' => array() injiziert. WP-Core normalize_input() setzt das Default bei null-Input ein, bevor validiert wird; rest_is_object([]) ist true, der Aufruf passiert. Greift unabhaengig von Tool-Name, Transport und davon, ob der pre_tool_call-Filter feuert - auch bei direkten Tool-Calls.
• Zusaetzlich als Absicherung: Der mcp_adapter_pre_tool_call-Filter wurde ohne den fehlerhaften Tool-Namen-Guard neu gefasst (erkennt den Gateway-Call am ability_name-Schluessel) und fuellt leere/fehlende parameters der aeusseren Gateway-Huelle.

v3.17.6

Behoben

• Leeres parameters ({}) bei execute-ability scheiterte weiterhin trotz des Workarounds aus v3.17.3. Tatsaechliche Ursache: Das Gateway-Tool von WordPress/mcp-adapter 0.5.0 liest die inneren Parameter via $input['parameters'] ?? null (ExecuteAbilityAbility). Bei einem parameterlosen Aufruf kommt parameters als null an (nicht als leeres Array), und die innere Ability lehnt null gegen ihr type: object-Schema ab ("input ist nicht vom Typ object"). Der alte Filter pruefte nur is_array() && empty() und liess null durch. Der Filter execute-ability0 deckt jetzt null, fehlendes, leeres Array und leeres Objekt ab und greift gezielt nur fuer das execute-Gateway (discover/get-info bleiben unangetastet). Betrifft alle execute-ability1-Abilities, die ohne Parameter aufgerufen werden (z. B. execute-ability2, execute-ability3, execute-ability4, execute-ability5, execute-ability6).
• seo-get-sitemap brach mit "Cannot use object of type stdClass as array" ab. Das Input-Schema nutzte als einzige Ability 'properties' => new stdClass(); der typisierte Schema-Parser von mcp-adapter 0.5.0 verarbeitet properties als Array und stolperte ueber das Objekt. Auf 'properties' => array() umgestellt. Zusaetzlich werden die Rank-Math-Sitemap-Optionen jetzt defensiv zu Array gecastet (get_option kann Array oder stdClass liefern).
• list-widgets nutzte dasselbe new stdClass()-Schema und waere bei aktivierter Widgets-Gruppe identisch abgebrochen. Ebenfalls auf 'properties' => array() umgestellt.

v3.17.5

Behoben

• Inline-<svg> blieb beim Anlegen und Aktualisieren von Inhalten nicht erhalten. Der Schreibpfad jagte post_content durch wp_kses_post, und wp_insert_post/wp_update_post wendeten zusaetzlich wp_filter_post_kses an (der MCP-Nutzer hat effektiv kein unfiltered_html). Die kses-Standard-Allowlist kennt keine SVG-Tags und schreibt camelCase-Attribute klein (viewBox -> viewbox), was SVG zerstoert. Neuer Helfer idf_mcp_write_post_unfiltered() setzt die kses-Content-Filter eng begrenzt um genau diesen vertrauenswuerdigen Insert/Update herum aus und stellt sie danach wieder her. Der Adapter ist authentifiziert und der Inhalt stammt aus einer kontrollierten Quelle (den Skills), nicht aus oeffentlichem Formular-Input. Greift fuer post_content0/post_content1, post_content2/post_content3 und post_content4/post_content5. post_content6 (Attachment-Caption/Description) bleibt bewusst kses-gefiltert.

v3.17.4

Geändert

• Admin-Dashboard: Reiter, deren Abhängigkeit fehlt (WooCommerce, SEO/Rank Math, Formulare/Avada, Events, Cache/WP Rocket, QUEST), werden jetzt ausgeblendet statt deaktiviert mit „(nicht installiert)"-Zusatz angezeigt. Das verhindert unnötig breite Reiter und hält die Navigation aufgeräumt.

Hinzugefügt

• Hilfe-Seite: Neue Karte „Verfügbare Abilities" listet alle aktuell registrierten idf-mcp-provider/-Abilities (Name + Beschreibung) inkl. Anzahl. Quelle ist wp_get_abilities() zur Laufzeit - zeigt also genau die Abilities, die verbundenen MCP-Clients tatsächlich zur Verfügung stehen.

v3.17.3

Behoben

• Eigentliche Ursache für die abbrechenden Abilities (siehe v3.17.2): Ein execute-ability-Aufruf mit leerem parameters ({}) schlug fehl („An error occurred while executing the tool"). Das leere Objekt wird in PHP als leeres Array [] dekodiert; die in WordPress/mcp-adapter 0.5.0 verschärfte Eingabe-Validierung lehnt ein leeres Array gegen ein type: object-Schema ab - verschärft durch WordPress 7.0 (Abilities-API in Core). Lag nicht in unseren Abilities, sondern im Basis-Adapter.
• Workaround über den Filter mcp_adapter_pre_tool_call (includes/compat.php): Bei leerem parameters für eine idf-mcp-provider/-Ability wird ein harmloser Schlüssel injiziert, sodass ein gültiges JSON-Objekt entsteht. Unsere Abilities ignorieren unbekannte Eingabe-Schlüssel. Greift automatisch nicht mehr, sobald der Basis-Adapter das Verhalten selbst korrigiert.

v3.17.2

Behoben

• Abilities get-site-info und health-check brachen beim Ausführen aus einer MCP-Session ab (generischer Fehler, kein Eintrag im Audit-Log, da der Abbruch vor dem Logging erfolgte). Ursache waren teure bzw. nach außen telefonierende Aufrufe, die in den PHP-Timeout liefen: - get-site-info nutzte count_users() (GROUP BY über die komplette usermeta-Tabelle) - auf großen Sites mit vielen WooCommerce-Kunden ein Timeout-Risiko. Ersetzt durch WP_User_Query mit count_total (reines SELECT COUNT(*) FROM wp_users, kein Meta-Join). - health-check rief get_core_updates() / health-check0 / health-check1 auf, die einen blockierenden Remote-HTTP-Update-Check zu api.wordpress.org auslösen können. Liest jetzt ausschließlich die gecachten Transients (health-check2, health-check3, health-check4) - kein HTTP.

v3.17.1

Behoben

• Ability set-post-terms wird jetzt tatsächlich registriert. In v3.17.0 wurden nur Version und Changelog gebumpt, der Implementierungs-Code in includes/abilities-content.php fehlte im Release. Damit zählt der Adapter erst jetzt die angekündigten ~129 Abilities.

v3.17.0

Hinzugefügt

• Neue Ability set-post-terms: Weist Taxonomie-Terme (Kategorien, Tags, custom Taxonomies) an beliebige Posts/Pages/CPTs zu. Nutzt wp_set_object_terms() mit Validierung von Post-Existenz, Taxonomie-Existenz und Post-Type-Kompatibilität. Unterstützt append-Modus und akzeptiert sowohl Term-IDs als auch Term-Namen.

Geändert

• Aktive Abilities: ~128 → ~129, Gruppen: 30.

v3.16.0

Hinzugefügt

• Neuer Tab QUEST mit acht Ability-Gruppen (~30 Abilities) für das Plugin idf-quest: Sessions, Voting, Invites, Guardianships, Badges, Sponsors, Participants, Feedback/Reports. Gruppe und Abilities nur aktiv, wenn IDF_QUEST_VERSION definiert ist. DSGVO-sensible Gruppen defaulten auf OFF.
• Neue Ability-Kategorie quest und Settings-Tab quest.
• includes/abilities-quest.php - hybrid-gekoppelt (CRUD via WP-APIs, Business-Logik via QUEST-Services).

Geändert

• Aktive Abilities: ~98 → ~128, Gruppen: 22 → 30.

v3.15.0

Hinzugefügt

• MCP-Annotations destructive und idempotent flächendeckend gesetzt. Mappt auf MCP-Hints destructiveHint und idempotentHint und sorgt dafür, dass KI-Agenten zerstörerische Operationen bestätigen und idempotente sicher wiederholen können. - destructive (neu, mit idempotent): delete-post, delete-page, delete-cpt, delete-taxonomy-term, idempotent0, idempotent1, idempotent2, idempotent3, idempotent4, idempotent5. - idempotent6 zusätzlich für bestehende destructive: idempotent7, idempotent8, idempotent9, destructiveHint0, destructiveHint1, destructiveHint2. - destructiveHint3 (alleine) für überschreibende Operationen: destructiveHint4, destructiveHint5, destructiveHint6, destructiveHint7, destructiveHint8, destructiveHint9, idempotentHint0, idempotentHint1, idempotentHint2, idempotentHint3, idempotentHint4, idempotentHint5, idempotentHint6, idempotentHint7, idempotentHint8, idempotentHint9, destructive0, destructive1.

Geändert

• Dependency-Check auf Klasse WP\\MCP\\Core\\McpAdapter umgestellt. Unter WordPress 7.0 wandert die Abilities-API in Core (wp_register_ability existiert dann unabhängig vom MCP-Adapter-Plugin). Der bisherige Proxy-Check über wp_register_ability lieferte deshalb falsch-positive Ergebnisse, sobald das Adapter-Plugin fehlte. Neue Logik unterscheidet zwischen fehlender Abilities-API (vor 6.9) und fehlendem Adapter-Plugin und zeigt jeweils eine eigene Admin-Notice.
• Plugin-Header Requires at least: 6.0 → 6.9 (wp_register_ability ist erst ab WP 6.9 verfügbar - vorher per Polyfill-Plugin WordPress Abilities API).

Kompatibilität

• Verifiziert gegen WordPress 7.0 (Release vom 2026-05-20). REST-API-Permission-Verschärfung von WP 7.0 betrifft das Plugin nicht (keine eigenen register_rest_route-Aufrufe; alle 98 Abilities haben permission_callback mit current_user_can()).

v3.14.0

Hinzugefügt

• Neue Ability-Gruppe Diagnose-Pfade (IDF Pathway) mit fünf Abilities: pathway-list, pathway-get, pathway-create, pathway-update, pathway-delete. CRUD für den CPT idf_pathway inklusive komplettem Fragebaum (_idf_tree). Gruppe und Abilities werden nur registriert, wenn das Plugin IDF Pathway aktiv ist (IDF_PATHWAY_VERSION).
• includes/abilities-pathway.php - self-contained, nutzt Standard-WordPress-APIs, keine Abhängigkeit von den internen Klassen des idf-pathway-Plugins.

Geändert

• Aktive Abilities: 79 → 84, Gruppen: 21 → 22.

v3.13.2

Behoben

• update-post akzeptiert jetzt excerpt (Feld fehlte komplett).
• create-page akzeptiert jetzt excerpt (Feld fehlte komplett).
• update-cpt und update-post/update-page: excerpt per Leerstring loeschbar (isset statt ! empty).

v3.13.1

Geändert

• Auf Git-basiertes Deployment migriert (idf-ci Workflow, readme.txt + CHANGELOG.md als Pflichtdateien).

v3.13.0

Hinzugefügt

• Phase 5: 15 neue Abilities - Rank Math SEO (Sitemap, Redirects), generische Taxonomy-CRUD, Menu-Items, User-CRUD (mit Rollen-Whitelist und Administrator-Blacklist), Media-Update/Delete, Shortcodes/Widgets-Listing.

Geändert

• Aktive Abilities: 64 → 79.
• Defense in Depth: create-user degradiert defensiv auf subscriber, update-user lehnt jede Administrator-Modifikation ab.

v3.12.1

Behoben

• Admin-Einstellungsseite nutzt jetzt dynamisch die Bildschirmbreite.

v3.12.0

Hinzugefügt

• Phase 4: 10 System-Admin-Abilities - Audit-Log, Health-Check, Cron-Jobs, Plugin-Aktivierung, Transients, WXR-Export.
• Plugin-Whitelist-UI mit harter Blacklist (idf-mcp-adapter, idf-master-key).

v3.11.0

Hinzugefügt

• Phase 3: 8 Abilities - Events (TEC) und Cache (WP Rocket). Bedingte Registrierung über Plugin-Existenz-Checks.

v3.10.0

Hinzugefügt

• Phase 2: 8 WooCommerce-Abilities - Produkte, Bestellungen, Coupons, Reports.

v3.9.x

Hinzugefügt

• Phase 1: 10 Abilities - Pages, Tags, Categories, Options, Revisions, Search.
• Statuszeile für den Automattic-MCP-Basis-Plugin-Check.

Behoben

• Spinner-Bug, GitHub-Repo-Slug, Robustheit durch Fallback-Kette.

v3.8.0

Hinzugefügt

• Avada-Forms-Integration mit 8 Abilities.
• Vierte Zugriffsstufe Admin für hochrisikante Operationen.

v3.7.x

Behoben

• Fatal Error „Cannot redeclare class IDF_Dependency_Checker" (Dependency-Checker auf v1.5.2).
• class_exists-Guard im Dependency-Checker.

Geändert

• Dependency-Check von File-Ebene in plugins_loaded:15.

v3.7.0

Hinzugefügt

• list-directory Ability mit Realpath-Validierung gegen Directory-Traversal.

v3.6.1

Behoben

• Upload-Plugin Ability: ZIP-Ordnername enthielt Versionssuffix.

Hinzugefügt

• Automatische Erkennung Update vs. Install bei Plugin-Upload.

v3.6.0

Hinzugefügt

• Master-Key-Integration.
• DSGVO-Warnhinweis für Tabs mit personenbezogenen Daten.
• Uninstall-Unterseite mit Datenlöschungs-Checkbox.

Geändert

• ACF-Felder per Opt-in (include_acf) statt automatisch.

v3.5.x

Hinzugefügt

• Chunked-Upload Ability upload-file-chunked (init/append/finish, 30-Min-TTL).

Behoben/Optimiert

• Settings-Cache, Log-Stats konsolidiert (4 → 1 Query).
• Upload-Ordner-Sanitization gegen ..-Bypass.

v3.4.x

Hinzugefügt

• 4 granulare Upload-Abilities (Plugin, Theme, Media, File).
• Zwei Transport-Wege: Base64 oder URL-Download.

v3.3.0

Hinzugefügt

• Dependency-Check für Basis-Plugin.

Geändert

• Eigener Top-Level-Menüpunkt.

v3.2.0

Hinzugefügt

• get-post Ability.
• list-posts mit include_content-Parameter.
• Migrations-Logik im Activation-Hook.

v3.1.0

Behoben

• AJAX-Handler merged jetzt mit bestehenden Settings.

Hinzugefügt

• Hilfe-Unterseite.

v3.0.0

Geändert (Breaking)

• Komplettes Refactoring aller Prefixe von mcp_ap_ auf idf_mcp_.
• Neuer Plugin-Slug idf-mcp-adapter.
• PHP 8.0+ erforderlich.

v2.0.2

• Ursprüngliche Version als mcp-abilities-provider.