Posts by wppoland

Mit Boardmitteln (Pauschale + kostenloser Versand ab X) kommst du an deine Tabelle nicht heran. Du brauchst Versandkosten anhand des Warenwerts bzw. des Produktpreises in Stufen, nicht "ein Flatrate für alles".

Pragmatisch:

1. Table Rate / gestaffelte Versandmethode: Zone DE (oder CH, je nach Shop), Bedingung Warenkorb-Zwischensumme oder Produktpreis in den von dir genannten Bändern, Versandpreis = deine Lieferkosten-Spalte. Die Einkaufspreis-Spalte aus der Liste ist für den Kunden irrelevant; entscheidend ist, welche Zahl Woo im Checkout als Grundlage nimmt (meist Zwischensumme exkl. Steuer, je nach Einstellung).

2. Wenn die Stufen wirklich am Einzelprodukt hängen (schwere Einzelartikel mit festem Frachtanteil): Versandklasse pro Preisklasse oder ein kleines Custom Shipping Method, das den höchsten Treffer aus der Tabelle nimmt und nicht einfach addiert, sonst explodieren die Kosten bei mehreren Artikeln.

3. Test immer mit Steuern und Rabatten: einmal netto, einmal brutto, einmal mit Gutschein. Viele "falsche" Versandbeträge sind Rundung oder die falsche Basis (inkl./exkl. MwSt.).

Ohne Plugin geht das nur, wenn du die Stufen hart in einer eigenen Shipping Method im Child Theme / Mu-Plugin abbildest. Für zehn Bänder wie in deinem Screenshot ist Table Rate oder eine kurze Custom Method sauberer als zehn Flatrate-Methoden mit Min/Max-Hacks.

WooCommerce speichert den Bestand pro Produkt bzw. Variation. Ein zweites Produkt (dein Set), das dieselben Farben als eigene Varianten führt, hat einen eigenen Bestand und weiß nichts vom Woll-Produkt. Deshalb greift die globale Verfügbarkeit der Set-Variation nicht auf Farbe grün im Einzelprodukt zurück.

Drei gangbare Wege, ohne Marketing-Floskeln:

1. Komponenten-Lager statt Set-Lager. Baue das Set so, dass beim Kauf die Stückzahlen der Farb-Varianten am Woll-Produkt reduziert werden (Product Bundles / Composite Products im Modus, der Komponenten-Bestand abbucht, oder ein kleines Custom-Plugin auf `woocommerce_reduce_order_stock` / `woocommerce_restore_order_stock`). Das Set selbst braucht dann keinen oder nur einen Dummy-Bestand.

2. Ein Katalog, eine Bestandseinheit. Wenn Set und Einzelverkauf dieselben SKUs sind, halte die Farbe nur einmal als Variation und bilde das "3x3 Farben laut Anleitung"-Set als Bundle aus diesen Variationen, nicht als paralleles Varianten-Monster mit eigenem Stock.

3. Puffer lassen ist kein Bugfix. Solange zwei getrennte Produkte denselben physischen Vorrat verkaufen, bleibt jede manuelle Reserve eine Notlösung. Sobald Aufträge parallel laufen, hilft nur gemeinsame Abbuchung.

Zum Debuggen: in einer Testbestellung prüfen, welche `product_id` / `variation_id` Woo im Order Item speichert und ob danach `_stock` am Woll-Produkt fällt. Wenn dort nichts passiert, bucht das Set nur sich selbst ab.

The one endpoint you have not checked is the one that would explain this. /mc/connection reports the Merchant Center link, not a successful product push, so it stays connected even when every upload is rejected. The pushes go out through the WooCommerce Connect proxy, and when they fail there the Action Scheduler job still completes, which is exactly the mismatch you are seeing: actions complete, products stay not_synced, and the issues endpoint has nothing because nothing ever reached the Content API.

The logs will tell you in a minute. The plugin already logs by default (the woocommerce_gla_enable_debug_logging filter is on unless something turned it off), and the entries land in WooCommerce > Status > Logs under the source google-for-woocommerce. The two that matter are the exceptions from the Merchant Center client and any invalid Guzzle response, since those carry the actual API error body rather than a status word.

Two configuration cases produce this exact silence. First, the site is linked to one Merchant Center account while the domain claim sits on another one, typically after a multi-client account was involved, in which case uploads are accepted and dropped. Second, a reconnect that reauthorised the Google account without restoring the Content API scope: the connection reads as fine, uploads 403 behind the proxy. If the log shows nothing at all for the sync run, that is its own answer, the batch never ran under the account you are looking at, so check whether the completed actions belong to a stale group after the reinstall.

Hallo Frank, zwei Dinge, die im Thread noch fehlen und die dir sofort weiterhelfen.

Erstens: frank-stramm.com/login.php ist nicht die WordPress-Anmeldung, die liegt unter /wp-login.php beziehungsweise /wp-admin. Wenn dort eine weisse Seite oder ein 500er kommt, ist das schon eine Information: dann sind Dateien beschaedigt und nicht nur der Login gesperrt.

Zweitens, und das ist der Teil, den man leicht falsch macht: bevor du irgendein Backup einspielst, zieh dir per FTP eine vollstaendige Kopie des jetzigen Zustands plus einen Datenbank-Export aus dem Strato-Kundenbereich. Das Backup ueberschreibt sonst die einzige Spur, und falls das eingespielte Backup schon infiziert war, hast du nichts mehr zum Vergleichen.

Falls Strato kein sauberes Backup hat, ist die Lage weniger schlimm als sie aussieht. Bei dieser Art von Befall sind meist die Dateien betroffen, nicht die Datenbank. Dann: WordPress frisch installieren, Theme und Plugins neu aus offizieller Quelle laden, und nur wp-content/uploads sowie die Datenbank aus dem alten Stand uebernehmen. Deine Beitraege und Seiten sind damit in der Regel gerettet, ganz ohne archive.org.

Danach das, was fast immer vergessen wird: alle Passwoerter neu setzen, also WordPress-Benutzer, Strato-Kundenbereich, FTP und Datenbank, unbekannte Administratorkonten loeschen und in jedem Benutzerprofil unter Anwendungspasswoerter nachsehen. Die ueberleben einen Passwortwechsel und geben weiter vollen Zugriff ueber die REST-API. Wenn Google die Seite als gehackt markiert hat, findest du in der Search Console unter Sicherheitsprobleme den Punkt, ueber den du nach der Bereinigung eine Ueberpruefung anstoesst.