Display on language not saving

This is the technical support forum for WPML - the multilingual WordPress plugin.

Everyone can read, but only WPML clients can post here. WPML team is replying on the forum 6 days per week, 22 hours per day.

Tagged: Bug

This topic contains 7 replies, has 2 voices.

Last updated by Nigel 1 year, 7 months ago.

Assisted by: Nigel.

Author	Posts
September 21, 2022 at 9:22 am #12093095
severinP	Following up on https://wpml.org/errata/widgets-display-on-language-feature-not-working-for-nested-widgets/ I am using WPML 4.5.10 the issue is still present When using the block widget editor any change made to "Display on language" is never saved, if I reload the page all the "Display on language" selects are set to English
September 22, 2022 at 11:47 am #12103721
Nigel Supporter Timezone: Europe/Madrid (GMT+02:00)	Hi there What you are describing is different than the issue reported in the erratum. I just checked on my local test site, and the problem you describe (it not being possible to save the display language settings on the widget editor page) works correctly, as does the issue described in the erratum (their display on the front end). To see why the problem occurs on your site, could you try clearing your browser cache and any caching you have in operation on your site. If you still see the problem, please check whether the issue persists in a minimal version of your site (i.e. with all non-WPML plugins disabled, and with a default theme such as twentytwentyone). (If you have a staging server available, you'll want to try it there.) If the problem disappears then it seems to occur because of a conflict with some other code, and you should be able to determine which by a process of elimination. Let me know what you find.
September 22, 2022 at 12:39 pm #12104139
severinP	Hello, Thanks for checking, I've found that the issue happens with the HTML Block only Here is an example of a save request with both the HTML Block and the Paragraph block {"validation":"require-all-validate","requests":[{"path":"/wp/v2/widgets/block-2","body":{"id":"block-2","instance":{"raw":{"content":"<p>Test</p>"}}},"method":"PUT"},{"path":"/wp/v2/widgets/block-3","body":{"id":"block-3","instance":{"raw":{"content":"<p>Test 2</p>"}}},"method":"PUT"},{"path":"/wp/v2/widgets/block-4","body":{"id":"block-4","instance":{"raw":{"content":"<!-- wp:paragraph -->\n<p>Test</p>\n<!-- /wp:paragraph -->"}}},"method":"PUT"},{"path":"/wp/v2/widgets/block-5","body":{"id":"block-5","instance":{"raw":{"content":"<!-- wp:paragraph {\"wpml_language\":\"en\"} -->\n<p>Test 2</p>\n<!-- /wp:paragraph -->"}}},"method":"PUT"}]} As you can see the paragraph has the wpml_language attribute but the html block doesn't There is no conflict, I can reproduce it with just WPML on a clean wordpress install
September 22, 2022 at 3:24 pm #12105623
Nigel Supporter Timezone: Europe/Madrid (GMT+02:00)	I can see the same on my own test site, that paragraph blocks include wpml_language attribute in the request but the custom HTML block doesn't, but that's not related to the issue. I was testing just with custom HTML blocks initially (no wpml_language attributes) and it worked as expected, and it still works as expected mixing up paragraph and HTML blocks. I created a sandbox site where you can see it working, log in here: hidden link If you go to Appearance > Widgets you'll note that the different blocks have retained the language setting, and if you visit the translated Sample Page on the front end and switch languages, the visibility of the widgets updates accordingly.
September 22, 2022 at 3:40 pm #12105769
severinP	I was able to cause the issue as well on the sandbox. Your test blocks seem to work (maybe because they are nested) But go the inactive widget section, I added 2 test blocks, try to change the language, reload the page, it's still marked as Display on all languages So yes it works if they are nested but not if they are not. It might be an issue with wordpress core
September 22, 2022 at 5:00 pm #12106169
severinP	After some digging wordpress has this thing called FREEFORM_FALLBACK_BLOCK_NAME which is set to block/html (why it's set like this, I still don't know), this causes the html block when at the root to skip the code that wraps it in attributes hidden link
September 23, 2022 at 9:02 am #12109387
Nigel Supporter Timezone: Europe/Madrid (GMT+02:00)	OK, thanks for the detective work. A custom HTML element at the root level fails to save the language setting, confirmed. I'll escalate this a little later when I'm done with some other tickets, and in the meantime you can workaround the problem by, for example, using the columns block with a single column and adding your custom HTML widget there.
September 26, 2022 at 7:16 am #12121127
Nigel Supporter Timezone: Europe/Madrid (GMT+02:00)	I've done that now, escalated the issue with all the details. Given that the issue arises because of WP core, I'm not how likely it is we'll come up with a fix, and for now I suggest you continue to workaround the problem by adding Custom HTML blocks inside some container block. Thanks again for reporting this.

This ticket is now closed. If you're a WPML client and need related help, please open a new support ticket.