Dieses Thema ist gelöst. Hier finden Sie eine Beschreibung des Problems und der Lösung.
Problem: Sie versuchen, die automatische Übersetzung in WPML zu nutzen, aber es gibt Probleme bei der Zuordnung der Standardsprache und Fehlermeldungen wie 'Internal Server Error' und 'PHP Fatal error: Uncaught Error'. Solution: 1. Überprüfen Sie die Servereinstellungen und das Caching. Ein häufiges Problem ist, dass das HTML-Zeichen für das kaufmännische Und (&) durch die Funktion
http_build_query
in PHP falsch kodiert wird. Dies kann die Kommunikation mit unserem Server stören. 2. Überprüfen Sie Ihre
php.ini
-Datei auf die Zeile
arg_separator.output = &
. Dies könnte ebenfalls zu Problemen führen. 3. Kontaktieren Sie Ihren Hosting-Anbieter, um zu sehen, ob Einstellungen wie 'mod_security' aktiviert sind oder ob ein Caching- oder CDN-Problem vorliegt.
Falls diese Lösungen nicht relevant sind oder das Problem weiterhin besteht, empfehlen wir Ihnen, ein neues Support-Ticket zu eröffnen. Überprüfen Sie auch die bekannten Probleme und stellen Sie sicher, dass Sie die neuesten Versionen Ihrer Themes und Plugins installiert haben. Für weitere Unterstützung besuchen Sie bitte unser Support-Forum.
Dies ist das technische Support-Forum für WPML – das mehrsprachige WordPress-Plugin.
Mitlesen können alle, doch nur WPML-Kunden können hier Fragen veröffentlichen. Das WPML-Team antwortet im Forum an 6 Tagen pro Woche, 22 Stunden am Tag.
Okay, at this point I am unable to verify those assumptions via code, but Query Monitor produced results which contains API requests to our server which appear to have wrongly encoded parameters.
At this point I suspect issue from Cloudflare - as your server appears to be behind a cloudflare caching platform.
Would it be possible if you can temporarily disable Cloudflare so that we can test this?
I did this yesterday already, because I had the same idea, but nothing has changed. But yeah, I have switched the orange cloud (Proxy Status) to "only DNS" and deleted the cache right now!
Yes, I noticed now that the site is accessible via its normal server.
I even tried disabling Redis cache, but the situation did not improve.
As I am not sure what causes the encoding of the API call to our server, and as I cannot reproduce the issue in my local setup using the same code on your site, I would like to ask you for permission to test this in a minimal setup - with a default theme like Twenty Twenty One and only WPML core plugin and all other plugins and cache disabled.
I am not entirely sure if this was covered by my colleague, so please excuse me if this was already addressed.
Thank you. But since you've already tested the full copy of my live site – including all active plugins and the current theme – and it worked flawlessly in your environment, I don't see how a minimal setup on my side would provide additional insights.
Wouldn’t it be more effective to focus on why the API request from my server does not send the token, while the exact same setup on your server does?
Your server sends the request to our API on our server, but it appears to contain an html encoded value for ampersand.
This is not something that should happen unless there is something in the middle that processes and alters the request.
My suspicion is that something is different between our environments or that there might be code that is specifically tailored to run on your domain due to some environment variables perhaps, and I feel that eliminating the most of the "moving components" may help.
In the mean time, I am consulting with our developers about this.
Gotcha. So if it would help, yes try the Twenty Twenty One theme with only WPML, but you know only as long you you need this, because it's a live site 😉
Okay, I think I mostly figured it out.
The issue is mostly with ampersands being html-encoded by http_build_query PHP function, and it is probably related to server side setting or cache or CDN.
And thus - it corupts the parameters and generates & instead of just an ampersand.
This is the reason WHY the communication with our server fails - we expect different values and while this is encoded in this way, it never completes the secure signed message that we normally generate.
So perhaps you should contact hosting provider and ask them for this?
Maybe you have mod_security enabled? Maybe it is as I said above - caching or CDN issue...
At this point, without being able to fully explore your server configuration it will be impossible for me to tell.
You were absolutely right – the problem was caused by the arg_separator.output directive in my server's php.ini, which was previously set to & instead of just &. I’ve now corrected it (I'm the Hoster, because it's a dedicated server) and restarted PHP.
Here’s the output from my test script: versteckter Link
→ It now returns correctly: "args": { "a": "1", "b": "2" }
The issue should therefore be resolved, and API communication with your server should now work as expected.
I am doing a cleanup on your site - just removing Adminer, Query MOnitor and the other HTTP logging plugin.
I noticed that everything seems to be in working order now.
Thanks again for your persistence and support – you were absolutely right:
The issue was caused by the arg_separator.output directive in my server’s php.ini, which was previously set to & instead of just &. I’ve now corrected it (I manage the server myself) and restarted PHP.
Here’s the updated output from my test script: versteckter Link
→ It now returns correctly: "args": { "a": "1", "b": "2" }"
Also, I’d like to revisit a topic I raised earlier regarding WPML AI:
I understand you use proprietary pre- and post-processing for translations, and that it’s not currently possible to insert custom prompts.
Still, I wanted to emphasize my use case:
Preserve my editorial tone (“Florido style”)
Generate native-sounding U.S. English content (not literal translation)
Optimize content for English keyword clusters, not just translate existing German ones
I’ll now begin testing WPML AI on selected pages to evaluate real-world translation quality.
One final note:
This issue required quite a bit of time and debugging effort on my side (including PHP-level analysis). Since the root cause was very obscure and only indirectly related to my setup, I was wondering:
Would it be possible to receive some translation credits as a goodwill gesture?
Your support was excellent throughout – and a gesture like that would certainly reinforce the very positive impression I now have of WPML.
Now that the technical issue is resolved, may I ask if there are any best practices or recommendations from your side to optimize WPML’s performance, especially on larger sites like mine? For example, anything related to REST API usage, translation memory cleanup, or avoiding unnecessary overhead would be very helpful.
