[Warten auf das Feedback der Benutzer] WP-Menu Sync Timeout

Hi WPML Support,
kurzes Update nach Rücksprache mit unserem Hoster (Kinsta): Das Problem ist weiterhin 100% reproduzierbar und tritt auch auf, wenn wir nur **einen** Menüeintrag synchronisieren.

Kinsta hat serverseitig bereits temporär **max_execution_time** und **max_input_time** erhöht, trotzdem endet der AJAX-Call weiterhin mit **HTTP 524**. Laut Kinsta ist bei deren Cloudflare-Integration ein **Response Timeout von 185 Sekunden** gesetzt und **nicht änderbar**. Der WPML-Call `admin-ajax.php` → `action=icl_msync_confirm` läuft regelmäßig bis ca. **3.1 Minuten** und wird dann abgebrochen (entspricht genau den ~185s).

Wichtig: Auf Kinsta ist Cloudflare/Edge **integriert**, d. h. wir können Cloudflare **nicht “temporär deaktivieren/umgehen”** (ohne Plattformwechsel). DB-Optimierung ist ebenfalls nicht verfügbar, da WPML die Tabellen bereits als „optimiert“ einstuft.

Damit brauchen wir eine WPML-seitige Lösung bzw. einen WPML-seitigen Workaround:

* Gibt es eine Möglichkeit, `icl_msync_confirm` in **kleinere Batches** aufzuteilen (mehrere kurze Requests statt ein langer)?
* Gibt es einen **WP-CLI**/serverseitigen Weg, die Menü-Sync ohne Browser/AJAX durchzuführen?
* Falls bekannt: Gibt es einen **Patch/Hotfix** oder ein Flag/Filter, um den besonders langsamen Teil der Menü-Sync (z. B. Orphans/Checks) zu entschärfen?

Wir können gerne zusätzliche Logs/Debug-Infos liefern, aber aktuell ist der Blocker: WPML Menü-Sync benötigt länger als 185s und wird dadurch in unserer Hosting-Architektur zuverlässig abgebrochen.

Danke & beste Grüße
Christoph

Hallo Bruno,

vielen Dank für deine Rückmeldung und die konkrete Liste der benötigten Daten.
Ich habe den Menü-Sync auf unserer **Staging-Umgebung** erneut reproduziert und kann euch nun folgendes liefern:

**1) Cloudflare cf-ray ID (524-Response)**

* Request: `POST /wp-admin/admin-ajax.php` mit `action=icl_msync_confirm`
* Cloudflare Ray ID: **9ac2c296b1de5ad5**
* Der Request läuft ca. 3 Minuten und endet dann mit HTTP 524 (Screenshots aus dem Network-Tab und der Cloudflare-Fehlerseite habe ich angehängt).

**2) PHP Error Log / PHP-FPM Log**

Zum gleichen Zeitraum erscheinen im Error-Log wiederholt folgende Einträge (Auszug):

```text
2025.12.11. 06:04:45
[error] 42776#42776: *2314 FastCGI sent in stderr: "PHP message: PHP Notice: Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the

acf

domain was triggered too early. ...
PHP message: PHP Deprecated: Optional parameter $menuId declared before required parameter $depth is implicitly treated as a required parameter in /www/casarista_591/public/wp-content/themes/casarista/functions.php on line 8309" while reading response header from upstream, client: 84.115.210.196, server: staging.casarista.com, request: "POST /wp-admin/admin-ajax.php HTTP/2.0", upstream: "versteckter Link:", host: "staging.casarista.com:61072", referrer: "versteckter Link"
```

Diese Notices/Deprecated-Meldungen treten bei jedem Menü-Sync auf, es gibt aber **keinen PHP Fatal Error** bei diesem Lauf – der Request läuft einfach so lange, bis Cloudflare mit 524 abbricht.

Zur Vollständigkeit:
Bei einem früheren Testlauf **mit aktiviertem Kinsta APM** hatten wir einen Fatal Error wegen Speicherlimit:

```text
PHP Fatal error: Allowed memory size of 1073741824 bytes exhausted
(tried to allocate 33554440 bytes)
in /usr/share/apm/src/Collection/Collection.php on line 116
```

Daher haben wir APM für die jetzigen Tests deaktiviert, um das „normale“ Verhalten zu sehen. Ohne APM gibt es keinen Fatal Error, aber der Request erreicht weiterhin das Cloudflare-Timeout (~185 Sekunden).

**3) MySQL Slow Query Log / APM**

Wir haben auf dem Staging-Server das MariaDB Slow Query Log aktiviert und `long_query_time` testweise stark reduziert. Das Log `mysql-slow.log` enthält jedoch **keine Einträge** – nur den Header von MariaDB.
Parallel dazu haben wir mit **New Relic APM** gemessen:

* Die Datenbank-Operationen (CSV Export angehängt) zeigen **Durchschnittszeiten im Millisekunden-Bereich**, max. Werte < ~150 ms pro Query.
* Die WordPress Hooks (ebenfalls als CSV exportiert) liegen ebenfalls im Bereich weniger Millisekunden bis maximal einige hundert Millisekunden.
* Es gibt **keine einzelnen Queries oder Hooks im Bereich von mehreren Sekunden**, die die Gesamtlaufzeit von über 180 Sekunden erklären würden.

Aus unserer Sicht bedeutet das: Die lange Laufzeit von `icl_msync_confirm` entsteht nicht durch einzelne langsame Datenbankabfragen, sondern durch die PHP-Verarbeitung/Logik innerhalb des Menü-Sync-Prozesses (z. B. Verarbeitung großer Datenstrukturen, Orphan-Checks, etc.).

**4) debug.log**

`WP_DEBUG_LOG` ist aktiviert; im `wp-content/debug.log` finden sich die gleichen Notices/Deprecated-Hinweise wie im Error-Log, aber keine zusätzlichen Fehler oder Fatals im Zusammenhang mit dem Menü-Sync. Den relevanten Auszug habe ich ebenfalls angehängt.

---

**Frage / Bitte um nächsten Schritt**

Auf Basis dieser Daten scheint die Datenbank selbst performant zu sein, während der PHP-Prozess `icl_msync_confirm` insgesamt so lange läuft, dass er in unserer Kinsta/Cloudflare-Architektur nach ca. 185 Sekunden abgebrochen wird.

Könnt ihr auf dieser Grundlage eingrenzen,

* ob es in der Menü-Sync-Logik bekannte Stellen gibt, die sehr speicher- oder CPU-intensiv sind (z. B. Orphan-Bereinigung, `get_page_orphan_sql` oder ähnliche Routinen), und
* ob es dafür bereits einen Patch/Hotfix oder eine Möglichkeit gibt, die Synchronisation in kleinere Batches aufzuteilen (mehrere kürzere Requests statt eines sehr langen)?

Vielen Dank für eure Unterstützung und die weitere Analyse!

Beste Grüße
Christoph

Hier die Files (kann kein CSV hochladen)
versteckter Link