FOX

Im Modus, in dem der Kunde in der gewählten Währung zahlt, wird raw_woocommerce_price() an woocommerce_product_get_price, die Getter für regulären und Angebotspreis und die Varianten-Getter gehängt. Die Ausführung bei 9999 stellt es hinter andere Plugins, die den Basispreis anpassen. Im reinen Anzeigemodus wird nur der Filter raw_woocommerce_price verwendet, sodass gespeicherte Warenkorb- und Bestellbeträge in der Basiswährung bleiben.

Im Konverter behandelte Sonderfälle: leere Preise laufen unverändert durch, ein variables Elternprodukt, das mit display=false abgefragt wird, wird übersprungen, um Min/Max nicht doppelt umzurechnen, und der Angebotspreis-Getter gibt einen leeren String zurück, wenn kein Angebotspreis gespeichert ist. Ohne das würde ein umgerechneter leerer Angebotspreis zu 0, und WooCommerce würde einen durchgestrichenen Preis zeigen.

WooCommerce speichert die berechneten Preis-Arrays eines variablen Produkts in einem Transient, dessen Schlüssel ein Hash der Preiseingaben ist. Ist die Währung nicht Teil dieses Hashs, werden die umgerechneten Preise des ersten Besuchers an alle ausgeliefert. woocommerce_get_variation_prices_hash() hängt die aktuelle Währung an.

woocommerce_variation_prices() rechnet dann jeden Eintrag um, wendet feste Preise pro Variante an und sortiert jedes Array mit asort() neu. Der Preisbereich wird aus dem ersten und letzten Element gelesen, und feste Preise pro Währung können die Reihenfolge der Varianten gegenüber der Basiswährung verändern.

Feste Preise werden als Produkt-Meta pro Feld und Währung gespeichert (_woocs_regular_price_EUR, _woocs_sale_price_EUR), wobei -1 'nicht gesetzt, Kurs verwenden' bedeutet. Ein fester Preis in der Währung des Besuchers wird unverändert verwendet. Andernfalls ersetzt ein Länderpreis den Basispreis, und das Ergebnis wird mit dem Kurs umgerechnet. Länderpreise gruppieren Länder in Blöcke mit einem Preis pro Block, und das Land des Besuchers stammt aus der WooCommerce-Geolokalisierung, die im Besucherzustand gespeichert wird.

Rollenpreise werden nach diesem Schritt angewendet. Ist für die Rolle des Benutzers ein Preis gesetzt, ersetzt er den bis dahin gewählten Preis, einschließlich eines festen Währungspreises, und wird mit dem Kurs umgerechnet.

Bleibt ein Angebotspreis pro Land leer, kopiert get_product_geo_data() den regulären Preis hinein, sonst würde das Produkt in diesem Land kostenlos. Ist ein festes Angebotsfeld leer, fällt die Suche auf das feste Feld für den regulären Preis zurück.

Feste Preise werden pro Feld gespeichert, aber woocommerce_product_get_price übergibt nur eine Zahl. get_price_type() vergleicht den eingehenden Wert mit den rohen regulären und Angebotspreisen des Produkts, die im Kontext 'edit' gelesen werden. Passt keiner, führt es eine statische Übersicht des ersten im Request gesehenen Preises je Produkt und behandelt einen späteren, größeren Wert als regulären Preis.

Das ist eine Heuristik, daher werden ausdrückliche Feldtypen übergeben, wo immer der Aufrufer sie kennt. Rollenpreise verwenden ihre eigene Kopie derselben Logik.

Die optionale Preisliste unter einem Produkt wird in woocommerce_price_html() aufgebaut. Für jede Währung wird die aktuelle Währung umgeschaltet, der Wert mit den Dezimalstellen und Trennzeichen dieser Währung formatiert und danach die ursprüngliche Währung wiederhergestellt.

Der Bereich eines variablen Produkts lässt sich nicht als Basis-Min/Max mal Kurs berechnen, weil einzelne Varianten feste Preise haben können. _get_min_max_variation_prices() berechnet den Preis jeder Variante für die Zielwährung neu und verwirft Nullwerte. Gruppierte Produkte durchlaufen ihre Kinder und behandeln variable Kinder genauso.

woocs_skip_conversion wird im Konverter als Erstes geprüft: eine Integration, die einen Artikel bereits in der aktiven Währung bepreist hat, gibt true zurück, und der Betrag läuft unverändert durch. Das Request-Flag woocs_block_price_hook schaltet die Umrechnung für einen Codeabschnitt ab, etwa während Webhook-Payloads gebaut werden.

Für die Gegenrichtung lassen woocs_convert_price und woocs_back_convert_price Plugins von Drittanbietern ihre eigenen Beträge in Basiswährung umrechnen, und convert_from_to_currency() rechnet über die Basis zwischen zwei beliebigen Shop-Währungen um: value / rate_from * rate_to.

WooCommerce liest die Zahl der Dezimalstellen aus einer einzigen Option. FOX beantwortet diese Option mit der Einstellung der aktuellen Währung, und der Konverter rundet mit number_format() auf dieselbe Genauigkeit, sodass der gespeicherte Warenkorbwert und der angezeigte Wert übereinstimmen.

JPY und TWD sind fest als Währungen ohne Cent hinterlegt, der Admin kann weitere hinzufügen, und mit dem Filter woocs_precision_on_calc kann eine Website die Genauigkeit pro Währung überschreiben.

Versandtarife werden in der Basiswährung berechnet und später in woocommerce_package_rates umgerechnet. Würden sie zuvor auf die Dezimalstellen der Besucherwährung gerundet (zum Beispiel 0 bei JPY), verlöre der Basiswert vor der Umrechnung an Genauigkeit. woocs_fix_decimals() gibt die Basis-Dezimalstellen zurück, wenn add_rate auf dem Call Stack liegt.

Dasselbe gilt für Variantenpreis-Arrays: woocs_fix_variation_decimal() formatiert sie mit Basis-Dezimalstellen, bevor der Konverter darüber läuft.

Dezimal- und Tausendertrennzeichen werden pro Währung gefiltert (sechs Schemata in get_decimal_sep() und get_thousand_sep()). Im Bestell-Editor in wp-admin setzen die Eingabefelder von WooCommerce, ihre JS-Validierung und wc_format_decimal() alle das Shop-Trennzeichen voraus, daher würde ein Komma als Dezimaltrenner dort die gespeicherten Beträge verändern. Die Trennzeichen pro Währung werden deshalb im Bestell-Editor abgeschaltet.

woocs_is_admin_order_edit_context() erkennt AJAX-Aktionen des Bestell-Editors am Namen, andere AJAX-Aufrufe am Referer (Seite wc-orders, Post-Type shop_order, Bestell-Post-ID) sowie die HPOS- und klassischen Bildschirme. Der Request-Teil wird in einer statischen Variable zwischengespeichert; die Prüfung des Bildschirms wird erneut ausgewertet, weil get_current_screen() früh im Request leer ist. Mit Komma eingegebene Erstattungsbeträge werden normalisiert, bevor WooCommerce sie validiert.

apply_conversion() läuft auf woocommerce_paypal_args und formatiert jedes Feld amount_* und tax_cart mit 0 Dezimalstellen neu, wenn die aktuelle Währung keine Cent hat. enable_custom_currency() erweitert die PayPal-Währungs-Whitelist von WooCommerce, damit das Gateway verfügbar bleibt, wenn der Besucher in einer anderen als der Basiswährung zahlt.

Ein Kurs wie Coins pro USD kann weit unter 0.0001 liegen, und die Float-zu-String-Umwandlung von PHP liefert Exponentialschreibweise, die das Admin-Formular und die Kurs-E-Mail nicht verwenden können. rate_to_string() berechnet die Zahl der Dezimalstellen aus log10 des Werts, begrenzt sie auf 20 und entfernt nachgestellte Nullen.

WOOCS_STORAGE stellt set_val/get_val/is_isset bereit und schaltet auf das konfigurierte Backend um. Der Transient-Speicher nutzt einen Hash der Client-IP als Schlüssel, wobei hinter Cloudflare CF-Connecting-IP bevorzugt wird, weil Cloudflare jeden vom Client gelieferten Wert überschreibt. Memcached und Redis werden ebenfalls unterstützt.

WOOCS_SESSION verwendet die Tabelle woocommerce_sessions mit einem HMAC-signierten Cookie wieder, liest über den Object Cache und schreibt beim Shutdown nur, wenn sich Daten geändert haben.

Bei Transient-Speicher und aktivem Cache-Modus erzeugt front.js einmalig eine zufällige ID (crypto.randomUUID, sofern verfügbar) und sendet sie mit jedem Request. Der Server bereinigt sie mit sanitize_key() und hasht sie in den Transient-Schlüssel, sodass Nutzer hinter Büro-NAT oder Mobilfunkanbietern getrennte Bereiche erhalten. Die ID wird absichtlich kleingeschrieben erzeugt: sanitize_key() wandelt in Kleinbuchstaben um, und eine ID in gemischter Schreibweise würde auf einen anderen Bereich gehasht.

In diesem Modus lebt der Transient 30 Tage statt 1, weil der Schlüssel pro Browser stabil ist. Ist localStorage blockiert, fällt der Code stillschweigend auf den IP-Schlüssel zurück.

jQuery-Requests erhalten den Schlüssel über einen ajaxSend-Handler, aber WooCommerce Blocks, die Store API und PayPal Payments nutzen fetch() und starten vor DOM ready. Der Wrapper wird auf oberster Ebene installiert. Der Schlüssel steht in einem Header X-WOOCS-SK, nicht in einem Query-Argument, weil ein Query-Argument pro Besucher den Seiten-Cache pro Besucher aufspalten würde. Cross-Origin-Aufrufe bleiben unberührt, da ein eigener Header einen CORS-Preflight auslöst, der Payment-SDKs stören kann.

Auf der PHP-Seite halten wp-json-Requests an Cart-, Store- und Batch-Routen das Plugin geladen, damit der Block-Warenkorb und der Checkout in der Währung des Besuchers gerendert werden.

woocommerce_price_html() umhüllt jeden Preis mit einem Span mit der Produkt-ID und einer eindeutigen Redraw-ID. Auf einer zwischengespeicherten Seite sammelt front.js die Marker und sendet sie an woocs_get_products_price_html; Varianten-JSON im Formular zum Warenkorb und eigene Preis-Shortcodes werden auf dieselbe Weise aktualisiert. Ein Preloader-Stil kann veraltete Preise verbergen, bis die Antwort eintrifft.

Der Server gibt eine leere Antwort zurück, wenn die Währung, in der die zwischengespeicherte Seite gerendert wurde, bereits der gespeicherten des Besuchers entspricht, sodass ein solcher Seitenaufruf kein Rendering kostet. Er rendert get_price_html() nur für veröffentlichte, sichtbare Produkte.

WooCommerce speichert Warenkorb-Fragmente im sessionStorage unter dem Warenkorb-Hash, und der Hash hängt nur vom Warenkorbinhalt ab. FOX filtert woocommerce_cart_hash zu md5(cart + currency), sodass ein Wechsel die gespeicherten Fragmente ungültig macht und der Versand neu berechnet wird.

Kommt die Währung auf einer zwischengespeicherten Seite per URL an, spiegelt front.js sie zuerst in den Bereich des Browser-Schlüssels und löst erst dann wc_fragment_refresh aus, sonst würde die Aktualisierung einen leeren Bereich lesen und auf die Basiswährung zurückfallen.

set_currency() speichert nur aktivierte Währungen, und der gespeicherte Wert wird bei jedem Request erneut geprüft, sodass eine vom Admin entfernte Währung auf die Basis zurückfällt. get_woocommerce_currency() gibt nie einen unbekannten Code an WooCommerce zurück, weil WooCommerce ihn in die Bestellung schreiben würde.

Als privat markierte Währungen lassen sich weder über ?currency= noch über den AJAX-Wechsel auswählen. Der Request-Wert woocs_in_order_currency akzeptiert eine private Währung nur für Benutzer mit edit_shop_orders.

woocommerce_package_rates() multipliziert Kosten und jeden Steuereintrag mit dem Kurs und rundet auf die Dezimalstellen der Währung. Feste Pauschalkosten pro Währung werden in der Options-Einstellung der Instanz der Versandmethode gespeichert. Werden feste Kosten verwendet, wäre die Skalierung der alten Steuer falsch, daher wird die Steuer mit WC_Tax::calc_shipping_tax() neu berechnet.

Flat-Rate-Kosten wie '[cost] * 0.1' erhalten die Warenkorbkosten in der Währung des Besuchers, und der entstehende Versandtarif wird dann in woocommerce_package_rates erneut umgerechnet. woocommerce_fix_shipping_calc() teilt das Argument cost zuerst durch den Kurs, sodass die Umrechnung nur einmal erfolgt.

Die Methode für kostenlosen Versand vergleicht die angezeigte Zwischensumme mit min_amount. Zahlt der Kunde in der gewählten Währung, liegt die Warenkorb-Zwischensumme in dieser Währung vor, daher wird die Prüfung neu implementiert: die Zwischensumme wird mit dem aktuellen Kurs zurückgerechnet, Rabatt und Rabattsteuer ebenfalls, die Einstellungen ignore_discounts und zur Steueranzeige werden beachtet, und die Anforderungen coupon/either/both werden wie in WooCommerce ausgewertet.

Ist ein fester Mindestbetrag pro Währung gesetzt, wird auch er zurückgerechnet, sodass beide Seiten des Vergleichs in der Basiswährung vorliegen.

woocommerce_coupon_loaded() rechnet den Gutscheinbetrag (nicht bei den Typen percent und percent_product) sowie den Mindest- und Höchstbetrag um und schreibt sie mit den Setzern des Gutscheins zurück, sodass die gesamte WooCommerce-Validierung in einer Währung läuft. Feste Gutscheinbeträge und Grenzen pro Währung, die als Gutschein-Meta gespeichert sind, überschreiben die umgerechneten Werte.

Im reinen Anzeigemodus wird die Währung auf der Checkout-Seite, bei checkout_process, im Block-Checkout und bei Aktualisierungen der Bestellübersicht auf die Basis zurückgesetzt. Im Modus Zahlung in gewählter Währung liest der Checkout-Request die gespeicherte Währung ausdrücklich, und optional wird die Währung durch das Land des Besuchers erzwungen. Eine ausstehende Bestellung, die später über ihren Zahlungslink bezahlt wird, wird auf die eigene Währung der Bestellung umgestellt.

Zahlungs-Gateways lassen sich pro Währung ausblenden oder anzeigen, da viele Gateways nur einige Währungen unterstützen.

RateProvider::getRate() baut die URL, ruft mit Timeout ab und delegiert an parseResponse(). Feeds von Zentralbanken sind gegen ihre eigene Währung notiert, daher berechnen die Parser Kreuzkurse: die EZB basiert auf EUR, und der Feed der Bank of Russia enthält außerdem ein Nominal (Kurs pro 10 oder 100 Einheiten), das herausgeteilt werden muss.

get_rate_provider() ordnet den konfigurierten Quellennamen einer Klassendatei zu. Websites können über die Filter woocs_add_custom_rate und woocs_add_aggregator_processor eigene Quellen hinzufügen.

Die Quelle Pulse Verity liefert für jedes Symbol einen USD-Preis, sodass ein Fiat-Code stillschweigend den Preis eines unverwandten Tokens erhielte. Der Provider prüft zuerst eine fest hinterlegte ISO-4217-Liste, weil Krypto-Zahlungs-Plugins Coins zur WooCommerce-Währungsliste hinzufügen und dieser Liste nicht zu trauen ist. Er funktioniert nur mit USD-Basis, sendet den API-Schlüssel als Bearer-Header, meldet für jede Antwort außerhalb von 2xx den eigenen Fehlercode der API (falscher Schlüssel, Planbeschränkung, Rate Limit) und lehnt Null oder nicht numerische Preise ab. Der gelieferte USD-Preis pro Coin wird in Coins pro 1 USD umgekehrt.

PN_WP_CRON_WOOCS hält Start, nächsten Lauf, Intervall und letzten Lauf pro Hook in einer Option und wird von init, admin_init und rest_api_init aus geprüft. Weil es bei jedem Request aufgerufen wird, muss attach() idempotent sein: bei unverändertem Intervall lässt es next unberührt, und bei einer Intervalländerung berechnet es next aus dem letzten Lauf neu, begrenzt auf jetzt plus ein Intervall. Die drei Hooks werden mit 0 akzeptierten Argumenten registriert, weil rest_api_init das WP_REST_Server-Objekt übergibt, das sonst im Parameter $reset landen und den Zeitplan bei jedem REST-Request neu starten würde.

process() schiebt den nächsten Lauf vor dem Aufruf des Hooks nach vorn, fängt von ihm geworfene Exceptions ab und protokolliert sie, und führt jeden Hook höchstens einmal pro Request aus. Der aktualisierte Zeitplan wird nach Ausführung der Hooks in der Option gespeichert.

rate_auto_update() ruft jede Währung in einem eigenen try-Block ab und ersetzt einen Kurs nur durch eine positive Zahl, sodass eine fehlschlagende Währung oder Quelle die anderen nicht stoppt und nie null oder einen Fehlertext als Kurs schreibt. get_rate() reicht jeden numerischen Kurs durch ExchangeRateLimiter, der ihn auf eine optionale Unter- und Obergrenze pro Währung begrenzt. Nach dem Speichern lässt die Action woocs_sheduler_rates_updated anderen Code reagieren.

Alle Kurse werden als Einheiten pro 1 Basis gespeichert, daher wird mit einer neuen Basis jede Zahl auf einmal falsch. save_etalon() speichert das neue Basis-Flag, schaltet default_currency im Speicher um und ruft get_rate() für jede andere Währung auf, bevor der Admin-Bildschirm antwortet, sodass das Formular mit konsistenten Werten neu gefüllt wird.

Der Aufschlag wird neben dem Kurs als fester Betrag oder Prozentsatz gespeichert und in einem Filter woocs_currency_data_manipulation mit Priorität 1 angewendet, sodass jeder Verbraucher von get_currencies() den aufgeschlagenen Kurs sieht. get_currencies(true) überspringt Filter, wenn der Rohwert benötigt wird.

Beim Checkout und auf der Danke-Seite werden Kurs, Basiswährung und eine Markierung 'manuell geändert' mit $order->update_meta_data() geschrieben, was sowohl für HPOS als auch für die Post-Speicherung funktioniert. Ist die aktuelle Währung nicht in der Liste, wird der Basiskurs verwendet. Die Meta-Schlüssel werden in der Posten-Anzeige ausgeblendet. Ein Admin kann den gespeicherten Kurs im Bestellbildschirm korrigieren, und die Produkt-Analytics-Zeilen der Bestellung werden neu synchronisiert.

Die Neuberechnung rechnet Bestellsummen, Posten-Zwischensummen und -Summen, Steuer-Arrays pro Satz, Versandposten und deren Steuern, Steuerposten und Erstattungen um. Bei HPOS läuft sie über die CRUD-Setter, rechnet auch Gebührenposten und Gutscheinposten um und berechnet die Steuern neu. Bei der klassischen Speicherung aktualisiert sie Post-Meta und Bestellposten-Meta direkt, einschließlich des Warenkorb-Rabatts der Bestellung.

Definiert eine Website woocs_order_recalculated_custom(), wird es vor dem Speichern mit der Bestellung, beiden Währungen und dem alten Kurs aufgerufen, für Beträge, die pro Währung einen festen Wert behalten müssen. Eine Sammelaktion rechnet alle Bestellungen in die Basiswährung um.

Die aktuelle Währung gehört demjenigen, der den Request ausgelöst hat: ein Admin, der eine Bestellung abschließt, ein Cron-Job oder ein Kunde, der in einer anderen Währung stöbert. FOX schaltet auf die Währung der Bestellung um in wc_get_template für E-Mail-Templates, bei der Benachrichtigung über den Abschluss und beim erneuten Senden von E-Mails, beim Rendern von PDF-Rechnungen, in den Bestelllisten und Bestellansichten von Mein Konto, in der Admin-Bestellvorschau und pro Zeile der HPOS-Bestellliste über den Filter für den Käufernamen.

WooCommerce Analytics kopiert Bestellbeträge unverändert in seine eigenen Lookup-Tabellen, sodass der Umsatz Währungen mischen würde. WOOCS_analytics hängt sich an woocommerce_analytics_update_product, _tax und _coupon, liest die gerade von WooCommerce geschriebene Zeile, teilt jeden Betrag durch den gespeicherten Kurs der Bestellung (oder den aktuellen Kurs, falls keiner vorliegt) und rundet auf die Basis-Dezimalstellen. Die klassischen WooCommerce-Berichte werden auf dieselbe Weise angepasst, indem jede Bestellung zurückgerechnet wird.

wp-admin läuft normalerweise in der Basiswährung. Für die AJAX-Aktionen des Bestell-Editors (Posten hinzufügen, Posten speichern, Steuern neu berechnen) wird die aktuelle Währung für Benutzer, die Bestellungen bearbeiten dürfen, auf die der Bestellung gesetzt. Wird ein Produkt mit einem festen Preis in dieser Währung manuell hinzugefügt, werden Zwischensumme und Summe des Postens aus dem festen Preis gesetzt und die Bestellsummen neu berechnet. Wird im Editor ein Gutschein hinzugefügt, wird die aktuelle Währung auf die der Bestellung umgeschaltet.

POS- und ERP-Systeme synchronisieren Preise über die WooCommerce REST API, und ein Request kann die Session eines Besuchers tragen, der eine andere Währung gewählt hat. Die vom allgemeinen REST-Guard genutzte Servervariable SCRIPT_URI existiert unter Apache, aber nicht unter nginx, daher wird die Route zusätzlich aus REQUEST_URI mit rest_get_url_prefix() oder aus ?rest_route= geparst, und das Plugin kehrt für jede Route wc/vN zurück, bevor sein Objekt erzeugt wird. Die Store API und der eigene Namespace von FOX sind nicht betroffen.

woocs_validate_currency() antwortet mit der Shop-Währung, wenn das Plugin-Objekt im Request nicht existiert. Premium-Edition.

Die asynchrone Zustellung läuft über Action Scheduler: die Basiswährung wird bei Priorität 1 von woocommerce_deliver_webhook_async eingeschaltet und bei 999 ausgeschaltet. Die synchrone Zustellung ist schwieriger: seit WooCommerce 4.4 werden Webhooks in eine Warteschlange gestellt und beim Shutdown zugestellt, daher schaltet FOX die Basiswährung im Filter woocommerce_webhook_deliver_async nur ein, wenn er beim Shutdown mit einem WC_Webhook und async=false aufgerufen wird, und in woocommerce_webhook_payload direkt nach build_payload() wieder aus.

Die Zustellung kann in einem Request laufen, der die Cookies eines Besuchers und damit dessen Währung trägt. Sowohl das Umrechnungs-Flag als auch current_currency werden umgeschaltet, weil feste Preise pro Währung current_currency direkt lesen. Premium-Edition.

Crawler können mit einer Währung in der URL ankommen. Bekannte Bot-User-Agents werden in wp_head auf die Basiswährung zurückgesetzt, sofern der Admin das nicht abschaltet. Unabhängig davon setzt structured_data_product_offer() priceCurrency auf die Basis und teilt die Einträge price, lowPrice, highPrice und priceSpecification durch den Kurs, sodass das Produkt-Markup mit der Shop-Währung konsistent bleibt.

Der Produkt-CSV-Export setzt die Währung vor seiner Abfrage zurück, sodass exportierte Preise Basiswerte sind, die wieder importiert werden können. Das Laden von Varianten im Produkt-Editor und jede wp-admin-Seite ohne AJAX laufen in der Basiswährung. Das Plugin lädt nicht für die AJAX-Aktionen des BEAR-Massen-Editors, für das Laden von Bestellposten, für REST-Requests, deren URL /refunds oder paypal enthält (PayPal Payments), und für Backend-Erstattungen, es sei denn, ein bekanntes Plugin braucht es, weil diese Requests gespeicherte Beträge schreiben.

woocs/v3 stellt die Währungsliste, den Preis eines Produkts und die Preise einer Gruppe von Produkten bereit. Der Callback setzt die angeforderte Währung nur, wenn sie im Shop existiert, berechnet Preise mit derselben Rangfolge wie der Hauptkonverter (fest, Land, Rolle, dann Kurs), liefert Rohwerte pro Variante mit Min und Max oder HTML und stellt die vorherige Währung wieder her.

Die Basiswährung des Shops war AUD. Während des Import-Requests hatte GeoIP die aktuelle Währung auf USD umgestellt, und der Importer schrieb die aktuelle Währung in jede Bestellung. Ein Aufruf von $WOOCS->reset_currency(), abgesichert durch class_exists('WOOCS'), wurde an zwei Stellen im Bestellcode des Importers eingefügt, sodass Bestellungen in der Basiswährung geschrieben werden. Das ist ein Patch am Importer eines Drittanbieters und muss nach einem Update dieses Plugins erneut angewendet werden. Der Kunde bestätigte, dass es funktionierte.