Beiträge von wppoland

    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.