However, when the parameter value is a JSON-encoded object, a critical WordPress error occurs.
Here is an example with mocked values:
Original URL (before switching language): hidden link
After switching language (WPML): hidden link{%22search_source%22:%22blogpost%22,%22results_order_by%22:%22date%22,%22results_order%22:%22desc%22}
Symptoms:
The encoding of the object changes after switching the language, leading to a fatal error in WordPress.
The error message is:
<code>PHP Fatal error: Uncaught TypeError: get_object_vars(): Argument #1 ($object) must be of type object, null given in /var/www/html/wp-content/plugins/jet-search/includes/ajax-handlers.php:876.</code>
The JetSearch plugin expects the parameter in a specific format, and when WPML changes the encoding, it receives null instead of the expected object, which breaks the code.
Questions:
How can I preserve custom query parameters when switching languages using WPML?
Why does the encoding of the JSON object change after switching languages with WPML?
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+02:00)
Hello,
Can you please share the code that is used to create such JSON and how do you add it as a parameter to the URL? because what i see at first sight is that the brackets exist in the portuguese version but the original one has it encoded, that might be part of the problem here but WPML doesn't really encodes or decodes the URL so there must be something else in between that might fail when you switch from one language to another.
Acctually that param is used by other plugin, Jet Engine search, however i can still see the error happenning if i create a custom param such "mycustomdata". The equivalent url generate for both are different. See below:
Original url: hidden link
New url after change the language: hidden link"hello%5C%5C"%3A%20%5C%5C"world%5C%5C"%20%7D
If you decode both params you get:
Original param:
mycustomdata={ "hello": "world" }
New param after changing the language:
mycustomdata={ \\"hello\\": \\"world\\" }
The plugin instead of keeping the data as it was before, it escapes and this causes the error.
Again, this params is not used at any place at all. I just created it to test and the wpml plugin does this.
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+02:00)
I ran a test and could verify that the results are a bit weird. In my case it was that it seems to double encode the content so it ends up being incorrect, so it's different than your example but it's enough to ask our devs to verify given that we can recreate the problem from scratch.
I have sent it to them and I'll be waiting on their updates. I'll keep you informed.
4) Save the changes
5) Retranslate the content that contains the JSON in the URL Parameter
6) Finish the translation and check if the problem has been solved.
Thank you for your response and for providing a possible solution.
Unfortunately, this change does not solve the problem in my case. However, I did notice a consistent pattern that might help narrow down the root cause(Also, i've tried it with other params not used by any plugin so its not related to the plugin in this case).
When the parameter contains double quotes ("), the browser already encodes them, escaping the quote with a backslash (\). This is the standard URL encoding behavior. But this escaping seems to be the source of the issue:
If I pass a simple JS object like { custom: 1 } (no quotes around the key), everything works fine and the URL remains consistent after switching languages.
However, if the object uses quotes around the key or value, like { "hello": "world" }, the problem appears. The URL gets extra escaping (with additional backslashes), and the parameter is broken after changing the language.
It seems that somewhere else in the code (not just in the sitepress.class.php section you've shown), an additional escaping is applied, especially when the parameter already contains backslashes from the initial browser encoding. Removing just the backslashes here is not enough, since another part of the codebase appears to re-add or double-escape them.
To summarize:
The issue happens specifically when the parameter contains double quotes (") and they are already escaped by the browser in the URL.
Parameters without quotes or with simple values do not trigger this bug.
The ideal solution would be to identify where in the process the extra escaping or double encoding is being added, and remove or bypass it only for these cases.
If you need more technical details or examples, I'm happy to provide them. Thank you for your support!
