Use Divi display condition logic in a Divi template
I expected to see:
Divi display condition is functional in all languages
Instead, I got:
Divi display condition is working fine in default language but not applied in translations.
If a content block should only be visible if post has selected category this is applied as expected in default language but the same block is never displayed in translations.
If display condition is removed, the block is visible in default language and translations.
Sorry for the delayed response - it has been a full queue for the past few days.
This could be a compatibility issue between the latest versions of WPML and Divi, so please log in to this sandbox site and try to replicate the issue: hidden link
If the issue is replicable, please let me know the steps to reproduce the issue.
I built a similar situation in the testing environmant and was able to reproduce the problem.
Short description of Setup:
- 2 Lanugages (EN,DE), 1 custom post/page type, 2 categories
- Custom divi template asigned to custom post/page type
- Divi template contains 2 display conditions:
Display block 1 only if page category is "cat 1"
Display block 2 only if page category is "cat 2"
Excpected result: Orange and yellow blocks are displayed only if condition matches
Is working as expected in base language: hidden link hidden link
In translated pages the conditions on category do not trigger, none of the blocks are displayed: hidden link hidden link
I think part of the problem is the condition set to category, with a custom field as condition this behaves as expected (but this is no solution to the problem).
Thank you for the super detailed info - that was amazing and super helpful! 🙂
No matter what I tried, I was not able to get it to work. I also tried with a default post type (DE translation - hidden link) instead of a custom post and it is not working.
What's even weirder is that, if I go to this one for example that you created, where I tested a couple of things (hidden link), in the backend, it shows correctly, but on the front-end, if we look at the code, the div is empty, no content inside it.
I will escalate this further and I will keep you up to date as soon as I have news.
For now, we have workarounds available, and my colleagues already escalated this to be handled in future updates in a definitive manner.
1. What is mentioned below at this first point was tested initially on a local server where we were testing with a simple post with a conditional tag so we found this problem that we will explain below. The fix that we are mentioning at this point works only for this case I will explain below.
The translated page was empty because the content was coming from the Theme builder's custom body layout so no matter what we put into the post content - it was not rendered.
This is how it is set up:
- Theme builder custom body layout displayed on CPT
- Layout has module
- Module has this condition
To make it work you need to translate the Theme builder body layout after we can see the content but not the conditional content.
if ( 'categoryPage' === $condition['condition'] ) {
with
if ( in_array($condition['condition'], ['categoryPage','categories'], true) ) {
2. In our situation, the problem is the Global Module.
Now, when the global module is used in post content, it does not store the display condition in post content, instead, Divi merges the display condition at the time of rendering.
This is how shortcode attributes look like when a global module is added to post content.
"display_conditions" is empty so WPML can not adjust the conditions. Now Divi uses the global module ID 471 and merges the display conditions. All this happens after WPML is finished with adjusting the display conditions.
After that, Divi does not have any filter hook (as per our initial observation) so we can not provide a workaround to adjust the display conditions.
So here are the workarounds for this specific situation:
When not using the global module, the above workaround, presented at point 1, will work.
When using the global module, the workaround from point 1 will not work.
In that case, you can manually edit the global module in 2nd language and open the display conditions, remove the previous conditions, and add a new one for the translated module.
Once this is done, this change will reflect everywhere where that global module is being used.
I tested it with some changes, it seems to work (only tried point 2 because it fits our requirements).
Do you know if changing the templates and re-translating with ATE overrides this workaround? Do we need to edit the template again via the frontend to make these changes to the global element?
I'm trying to avoid mixing translations with ATE in the backend and in the DIVI builder frontend, we used to have problems with overwritten translations as soon as we did this.
Global elements translation is different and the translation of elements where global elements are being used is different.
If you modify the global and translate it with ATE, then the workaround will be lost.
If you modify the page and translate it with ATE without changing the global element, there will be no change.
So the workaround will be lost only if you translate the global elements explicitly. You can not translate the global element directly from the page/template where it is being used.
I hope that you will find this information helpful. 🙂
