✅ 🔥 Elementor v3.20 Beta Release 🔥

[avivu]

===========

Beta 2 UPDATED - PLEASE READ BELOW!

===========

 

Hey Beta testers, 👋

Elementor 3.20 beta is now available, and we would love to hear your feedback on the new Display Condition abilities. You can now add the “OR” connector between groups of conditions and set rules based on Dynamic Tags for native WordPress Custom Fields.

We encourage you to try out 3.20 beta and provide us with your thoughts on our latest additions, which include:

• [Pro] Display Conditions Enhancements
• Performance and Accessibility Enhancements
• And More!

 

[Pro] New: Use Dynamic Tags and ‘OR’ Connector with Display Conditions for Unique Visitor Experiences

 

This version introduces additional capabilities to Display Conditions that enable you to customize your personalized visitor experiences with more specificity. In the previous version of Elementor, we introduced the first phase of Display Conditions, which enabled you to connect multiple conditions using the AND connector, displaying the element only when all conditions were met. With the enhancements to Display Conditions in Elementor 3.20, you can now create condition groups and connect them using the OR connector. This will allow you to set multiple conditions and display the element if any of the conditions are met.

In addition, you can now set display conditions based on Dynamic Tags for native WordPress Custom Fields. These conditions are particularly helpful in transforming your single post and page templates into dynamic designs that fit their content. For example, if you are using an Icon Box Widget to display an icon next to your dynamically populated title, then you can set a condition that displays the entire Icon Box Widget only when the title "Is not empty". Conditions based on Dynamic Tags also have additional parameters based on the values of Custom Fields, such as "Is/Is not" or "Contains" a certain value.

How to Test It:

1. Ensure that both Elementor and Elementor Pro are updated to version 3.20.
2. Activate the "Display Conditions" feature by accessing the Elementor menu in WordPress, then proceed to Settings → Features.
3. Go to the Advanced tab for the widget you want to modify.
4. Click on the "Display Conditions" icon to open the modal window.
5. Review the suggested rules and verify whether the element's display aligns with these rules.
6. Confirm that both the OR and AND logic functions are operating as intended.
7. Check that everything is working correctly, both in the Editor and on the front-end.

 

Improvements in Performance & Accessibility

Performance Improvements

This version of Elementor includes significant performance updates, resulting in faster and more enjoyable website building and browsing experiences.

Faster TTFB

Elementor 3.20 improves the Time to First Byte (TTFB) score by 3-5%, and even more on heavier pages through optimized rendering of elements. This is achieved by excluding unnecessary controls from being rendered on the frontend.

DOM Optimization

By updating to version 3.20, you will automatically reduce the DOM output of Containers, allowing you to build sophisticated layouts while maintaining high performance. In comparison to version 3.19, Flexbox Containers now produce 39% less code, and Grid Containers produce 85% less code. Additionally, this version improves the performance of the Editor by reducing the DOM output of the custom unit controls.

Accessibility Improvements

Elementor continues to dedicate time and effort to make the internet more accessible for visitors and web developers that rely on assistive technologies.

• Mega Menu: Enhanced keyboard navigation and usability on mobile devices.
• Login Widget: Screen readers can now read hidden labels, and each login widget has a unique ID when multiple widgets are placed on a page.
• Improved Editor: Navigate the Widget Panel and Editing Panel using the keyboard.

 

Feature & Experiment Updates

This version includes a number of status changes to features and experiments. Some have been made active by default on all new sites, and others have become an inseparable part of Elementor, and can no longer be activated or deactivated from the features page.

• Default on New Sites: Grid Containers, Taxonomy Filter Widget, and Display Conditions.
• Features Merged: Global Style Guide, Page Transitions, Scroll Snap.

 

---

More Improvements

Free version

• Tweak: Enanached TTFB metric by removing UI controls and some arguments from frontend loading for better site performance
• Tweak: Resolved excessive DOM output when using Grid Container and Flexbox Container widgets
• Tweak: Refined Editor's unit selection DOM output for better efficiency
• Tweak: Implemented accessibility improvements in Dynamic Tags control
• Tweak: Implemented accessibility improvements in widget panel sections
• Tweak: Implemented accessibility improvements in Site Settings items
• Tweak: Implemented accessibility improvements in the Elements panel keyboard accessible
• Tweak: Implemented accessibility improvements in Color Picker control
• Tweak: Implemented accessibility improvements in Site Settings header buttons
• Tweak: Implemented accessibility improvements for actions in the History panel
• Tweak: Implemented accessibility improvements for revisions in History panel
• Tweak: Added semantic <time> wrapper for items in History panel
• Tweak: Added semantic <search> wrapper to Widgets search
• Tweak: Promoted Build with AI feature to Stable status
• Tweak: Global Style Guide feature merged to version
• Tweak: Promoted Inline Font Icons feature to Stable status
• Tweak: Activated Grid Container feature by default for new sites
• Tweak: Removed separator-none argument from all Editor controls
• Tweak: Relocated Icon and Content Spacing controls to the Box section in Icon Box widget
• Tweak: Relocated Image and Content Spacing controls to the Box section in Image Box widget
• Tweak: Relocated Alignment control from Content tab to Style tab in Button widget
• Tweak: Replaced Position select control with toggle control in Tabs widget
• Tweak: Replaced Icon Position select control with toggle control in Button widget
• Tweak: Hide the Border Radius control of Drop Cap in Text Editor widget
• Tweak: Hide image controls when image is not selected in Image widget
• Tweak: Removed Size control for new usage in Button Widget
• Tweak: Replaced Dismiss Icon select control with toggle control in Alert widget
• Tweak: Replaced Additional Options select controls with toggle controls in Image Carousel widget
• Tweak: Added missing title attribute to the Editor preview iframe
• Tweak: Added a new reference to the Extensions page from Add New Plugin screen
• Tweak: Improved flexibility of the widget promotion area for better extendability and customization
• Tweak: Implemented general improvements to i18n for enhanced global support
• Tweak: Updated eicons library to v5.28.0
• Tweak: Standardized section names across various Elementor widgets for uniformity and clarity
• Fix: install_compare() in Experiments Manager throw an error in PHP 8.2+ if get_installs_history() returned an empty result

Pro version

• Tweak: Implemented OR logic in the Display Conditions feature
• Tweak: Added Archive Title dynamic tag rule in Display Conditions feature
• Tweak: Added Featured Image Title dynamic tag rule in Display Conditions feature
• Tweak: Added Featured Image Alt dynamic tag rule in Display Conditions feature
• Tweak: Added Featured Image Caption dynamic tag rule in Display Conditions feature
• Tweak: Added Author Bio dynamic tag rule in Display Conditions feature
• Tweak: Added Author Email dynamic tag rule in Display Conditions feature
• Tweak: Added Author Website dynamic tag rule in Display Conditions feature
• Tweak: Added Page Title rule in Display Conditions feature
• Tweak: Added Post Title rule in Display Conditions feature
• Tweak: Added Featured Image rule in Display Conditions feature
• Tweak: Added Comments Number rule in Display Conditions feature
• Tweak: Added Archive Author rule in Display Conditions feature
• Tweak: Added support for WordPress Custom Fields in Display Conditions feature
• Tweak: Implemented accessibility improvements in Menu widget (✅ ♿ 🐞 Bug Report: Mega Menu Accessibility is not intuitive #23875)
• Tweak: Implemented accessibility improvements in Login widget
• Tweak: Added additional style controls in the Table of Contents widget
• Tweak: Added Transition Duration option in Blockquote widget (✅ 🚀 Add Transition Duration option everywhere + custom unit for that #21295)
• Tweak: Added Transition Duration to button in Flip Box widget
• Tweak: Added Transition Duration to button in Author Box widget
• Tweak: Added Transition Duration to List in Table of Contents widget
• Tweak: Added Transition Duration to button in Login widget
• Tweak: Added Transition Duration in Post Navigation widget
• Tweak: Added Transition Duration Show More in Video Playlist widget
• Tweak: Added Transition Duration to button in Form widget
• Tweak: Removed separator-none argument from all Editor controls
• Tweak: Add <time> wrapper for Date and Time items in Post Info widget
• Tweak: Page Transitions feature merged to version
• Tweak: Scroll Snap feature merged to version
• Tweak: Promoted Display Conditions feature to Beta status and activated for new sites
• Tweak: Promoted Taxonomy Filter feature to beta status and activated for new sites
• Fix: Added better output escaping in Taxonomy Filter widget

---

Make An Impact: Share Feedback Before Features Are Released

We’re always looking to get to know Elementor customers on a deeper level. If you’re interested in meeting with our team and sharing your insights, feedback, and feature requests, you’re welcome to sign up for some quality time with us here.

How to Install the Beta Version

If you still haven't enabled beta testing in Elementor, please follow these steps:

• Go to Elementor > Tools > Versions
• Enable the beta tester feature
• Go to Dashboard > Updates and update to the latest beta version.
• This will get you set up to test the new Elementor 3.20 Beta.

---

Notes

As we make changes to our GitHub in an effort to keep it organized, improve the way we deliver information to you, and our ability to review your feedback, please follow the instructions below when reporting bugs, or making feature requests:

• To report a bug related to beta versions - open a new 🐞 Bug Report
• For feature requests - open a new 🚀 Feature Request
• For other comments specifically about this beta version - comment here

Designated time for release: March 11th, 2024 (Estimated)

Many thanks for your support and help!

Cheers,
Elementor Team

[perks98]

Great that dynamic conditions feature is now marked as beta so it can be used on production website from 3.20 onward, but I am disappointed in the custom fields implementation. Really need it so you can input your own meta key, so one for post custom meta and another for taxonomy custom meta. Also the dynamic tag pulls in the full list of possible custom meta, this can make it messy and long...

Also dynamic tags would be better if it pulls in the main dynamic tags list. The dynamics tags list seems more like a 'more' or 'other' selection thrown together; would be better if it had the list of existing tags and then it can automatically work with third-party tags from the start.

Also Post Title and Page Title doesn't make sense to me, is it getting the post by title and if so why do I need to find the post in a list and not manually type

Also still no display condition icon in the navigator panel.

[nicholaszein]

Hi @perks98! 👋

Thanks for this insightful feedback! Please understand this second phase is only focused on native WordPress Custom Fields. There is more to come, including an option to set a custom meta field value. But to handle custom inputs, we are still making some tests, and ensuring they are strong both from a security standpoint, but also from a functionality standpoint, and the logic is still being tested to avoid errors. There is more to come.

Also dynamic tags would be better if it pulls in the main dynamic tags list. The dynamics tags list seems more like a 'more' or 'other' selection thrown together; would be better if it had the list of existing tags and then it can automatically work with third-party tags from the start.

Just to be clear, you mean the Dynamic Tags available on widget input fields, is that what you mean by "existing tags"? If that's the case, these are still not part of this release. 3rd-party support will be added in future versions.

Also Post Title and Page Title doesn't make sense to me, is it getting the post by title and if so why do I need to find the post in a list and not manually type

Try the "Contains" parameter using the new Dynamic Tags option.

Also still no display condition icon in the navigator panel.

This is a work in progress. We appreciate your patience while we work on implementing this. 😉

[perks98]

Hi @nicholaszein,
Thanks for the reply. I guess my issue is a feature being put in beta phase when new additions like custom fields input and third-party planned integration isn't close enough to being finalised. But we will see what comes next. Since it is in beta I might create my own condition if I get desperate. Would you team also consider the URL parameter option like mentioned in the last beta? I have a use case with a few priority clients that I would like to use it on.

Try the "Contains" parameter using the new Dynamic Tags option.

See screenshot below, it is marked for archive which is why I hadn't thought to use it, could that be adjusted to be general or something like that?

---

For Post Title and Page Title conditions, I've just tried it again. I'm still personally not a fan, could it not be a condition as 'By Post' or 'By Page' and save the data by their post ID but searchable by title? Currently if you map it to a post by name, then change the name you just have a condition that doesn't do anything anymore and no post of that name now exists, which is why that dynamic tag option you mention would work better under dynamic tags. Maybe a dynamic tag of post ID and 'in list' and 'not in list' comparators with value separated by comma is needed maybe too. ~~ Just my personal thoughts.

[nicholaszein]

@perks98,

we changed the status to Beta because we believe now that we have both AND, and OR comparators, and a more stable structure, we are ready to leave the Alpha state, and start implementing more options. However, we will do this progressively, steadily, and responsibly. Baby steps.

We still do not recommend you add your own conditions, as we don't have an official API. Thigs still might change under the hood. So please, keep that in mind when implementing your own conditions.

URL parameters and custom meta are planned to be implemented in a future phase.

See screenshot below, it is marked for archive which is why I hadn't thought to use it, could that be adjusted to be general or something like that?

I'll check with the team and get back to you with an answer.

For Post Title and Page Title conditions, I've just tried it again. I'm still personally not a fan, could it not be a condition as 'By Post' or 'By Page' and save the data by their post ID but searchable by title?

Keep in mind that Display Conditions apply to any element in any scenario. For example, let's say you have a template and you want a specific element to appear only when a title from a page or post meets the condition. You then would implement two condition groups, one with the Page title, one with the Post title. This is why both are visible as options. However, I understand what you are talking about. I'll relay this back to the team to be considered.

The logic here is to indicate how a user can search for a Post or Page (by title). This is why it's currently represented as Page Title, and Post Title. But the condition is attached to the post object. Does that make sense for you?

[m1ga]

DOM Optimization

you are just talking about the data attributes on the divs, right? E.g. data-settings is gone now in the output. I don't see any DOM structure changes or class name (which is good). Just want to make sure I didn't miss any PR that was merged and all of the sudden the DOM structure change.

[m1ga]

Thanks for the quick reply!
For DOM structure changes I have my own container, headline and image widgets where I just removed the elementor-widget-container div 😉 Everything still works and the DOM size goes down. But don't think it will be good for backwards compatibility that's why I've just made new widgets for me so I can use them in new pages.

[nicholaszein]

Yep, we are researching ways of improving the DOM further, but for the time being, we won't make any breaking changes!

[koolked]

Hello @m1ga would it be possible to request those widgets or to know how I can do it? I'm trying to optimize the Elementor containers for my website as well. Thank you very much in advance!

[m1ga]

@koolked I've uploaded them to the plugin repo: https://wordpress.org/plugins/optimized-widgets-for-elementor/
Not put much effort in the Readme yet 😉

yellow is the normal Headline, pink is the optimized. I removed one div, so the content (eg. h2) is right inside the outer div now. Make sure to test it! In my case I was just using padding/margin and the normal font stuff and it worked just fine.

[koolked]

Wow thank you! As soon as I test them I'll make the review to give you the five!!

[perks98]

Also since you are enabling the grid feature on new sites by default, can you disable the default row of '2fr' that is set as in most cases it doesn't need to be set, I have to manually set it to 'auto'. It would be ideal to be 1fr by default or empty (auto). If someone can tell me a few use cases of having it as 2fr I would like to know, but right now it is just more clicks.

[nicholaszein]

Hi @perks98,

Thanks for the feedback!

Unfortunately, we have no plans to change the default settings for Grid Containers. But if you think this should be changed, please submit a new Feature Request, this way we can see if there are other users with the same demand and will consider making these changes.

[perks98]

@nicholaszein from a usability standpoint could you or one of your peers please explain the reasoning for the 2fr row just so I have an understanding of the decision for that default and the benefit to the end-user using the grid container? I'm just trying to make sure I'm not doing it wrong or missing something others are seeing the benefit of.
My understanding of grid CSS is you don't normally need to add a value to template rows for basic grid layouts but Elementor has added a default.

[nicholaszein]

@perks98,

I think the reasoning doesn't apply to you. I'm pretty sure you know how to use CSS Grids. Our reasoning was to ensure beginners understand what each setting does, and can see the possibility of adding content to multiple rows. It's a workflow indicator of how grids work and what to expect from them.

[hitsgee]

No FA6 still?

[perks98]

This was started 7 hours ago #25190 so maybe we might get Twitter X and Threads icon as a temp placement in another beta version of this update at some point and then the full FA6 in the next main update. Just my speculation though.

[nicholaszein]

Hi @hitsgee,

FA6 was going to be part of this beta, but it did not pass our tests, and we decided to continue developing the upgrade to ensure it's more complete and does not affect anything negatively. FontAwesome is an integral part of Elementor, and used extensively throughout the builder and its features.

Apologies for the delay. We want the transition to go as smooth as possible without any hiccups. I hope you can understand. 🙏

[hitsgee]

This was started 7 hours ago #25190 so maybe we might get Twitter X and Threads icon as a temp placement in another beta version of this update at some point and then the full FA6 in the next main update. Just my speculation though.

There is another PR a few hours ago around this. I think it's just updating the share icons when ready.

[portrayaloflife]

Really awesome work and really exciting. I know it may not be a part of this release but just to jump off some comments around custom fields, that is going to be a game changer! I just wanted to highlight one area that seems to often go untouched and that's the target attribute. Currently, when creating a post type there's no way for a user WP side to dynamically set a link to open in a new tab or not. It has to be chosen on the WP Grid set up side and it's either open in a new tab or not.

Would be great to add some type of dynamic ability to the target of a link for more diversity in loops when some need to link out of the site and some need to link to a site page. For action page post types to news/press, etc etc.

Keep up the great work!

[nicholaszein]

Hi @portrayaloflife!

Thank you for the feedback! 💪

As for dynamic attributes for links, you might want to join the discussion about this feature request here, and cast your vote! 😉

[portrayaloflife]

Done!

[Joliamendi]

Are display conditions compatible with WooCommerce now? For example, displaying a widget only in one of the desired product categories.

[nicholaszein]

Hi @Joliamendi!

Support for WooCommerce will be added in a future phase.

[nicholaszein]

Hi @lensbreak, how's it going?

Cache is actually a beast on its own. There are so many different ways to apply it, that it's simply not possible to cover the all, from all different types and levels that exist... Doing so would mean loading a pretty heavy script just to do all the work of consulting the server and then applying the conditions.

I can already hear you in this future alternate reality asking us to "cut off the bloat". We opted not to include this at this stage.

So if you are using LiteSpeed Cache, especially a combination of object and static, chances are it won't work for display conditions. And the reason is simple. The conditions are checked at the server level when the page is being loaded.

Object cache won't allow to check for updates to the real database depending on the situation (server time for example). Static cache will return whatever the page was generated when it was cached, regardless if the existing conditions (server time for example).

When you first load the Display Conditions screen, at the top you'll see a banner explaining they night not work with cache. I hope you have seen and read it before closing it. And that you can understand better why they might not work...

Hope this clarifies your question.

[toineenzo]

Hi @nicholaszein ,

I'll try to test this version as extensive as 3.19 ;)

First, I would like to give a heads up, that the Join Research doesn't work @ https://elementor.com/pages/join-the-list/
It gives the following error or nothing happens when clicking Send

[nicholaszein]

Hey @toineenzo!thank you for joining us yet again!

I haven't updated you yet because we are still discussing some details, but I'll have an answer to you by tomorrow, including related to the page you just shared. 😉

Thank you! 🙏

[nicholaszein]

Hi @toineenzo,

about the Research Lab form: unfortunately, the period for subscription has ended. That's why you don't see anything after submitting.
We usually announce new research on our Facebook Community. Keep an eye on future announcements! 😉

As for Translations of the Elementor Pro plugin, these are on hold for the moment, and the email you used is currently deactivated.

If you wish to contribute with translations for the Elementor Pro plugin, please submit a new 🚀 Feature Request, with the title "Contribution: Translation to {locale} for Elementor Pro", where {locale} should be replaced with the name of the WP Locale related to the language you are translating to as indicated in the table in this page (for example Contribution: Translation to pt_BR for Elementor Pro).

In the description of the Request, you can include both .po and .mo files you've generated. You can follow these instructions to make the translations.

Your request will be analyzed internally and eventually merged into the plugin. You can tag me there, and add your questions as well. I'll make sure to analyze them and forward them to the team. We really appreciate your contribution! 🙏

As for the translations for Elementor Core, they are analyzed regularly every few minor updates (major.minor.patch) and merged to the core. Just give it some time. The process requires analysis by someone from the Polyglots Team to be approved.

[nicholaszein]

Hey @toineenzo!

When you can, please check your Facebook! 🙂

[toineenzo]

Hey @toineenzo!

When you can, please check your Facebook! 🙂

Saw Verdi's message, thank you for the heads up!

[toineenzo]

@nicholaszein I just sent in my contribution: https://github.com/orgs/elementor/discussions/25373

[ClanScript]

Disable "required" for month/year input field at display conditions. I want to display containers for holidays/new year every year! https://github.com/orgs/elementor/discussions/24779

[nicholaszein]

Hello @ClanScript! Thank you for for your suggestion!

Would you be so kind to please submit a new 🚀 Feature Request, so we can consider it in a future phase if there is enough demand (votes) from other users?

A good title for this would be "Allow to set recurring Display Conditions similar to calendar schedules".

Thank you! 🙏

[perks98]

I have a technical question around the dynamic tags implementation for the display conditions. I have had a peek at the PHP code and I can see it seems to work for potential simple tags where there is always a render output or where you can set a default value where there is normally user input. Will the Elementor developers extend this by allowing dynamic tags to inject at least one select or text control type for user input comparison or is this implementation meant to be only for simple tags with minimal to no user input and other tags would need to be re-implemented for display conditions from the ground up in mind?

I hope that make sense. See screenshot below, where in settings you would normally have user input for the tag to select which option you want but in this case three conditions are added with settings predefined of title, alt and caption. Some tags require one or two user input, especially user text input or pulled in dynamically, so some tags would work better if it can pull in one of their controls e.g. for URL parameters you could have 3 pre-defined conditions get, post and query but you will need another for text input for the key for example.

---

Side question. How many more phases are there for the display conditions feature? It sounds like custom field input and woocommerce integration will be coming but are these a part of the same phase or are we talking spread across this year?

[nicholaszein]

Thanks for clarifying @perks98.

Since there is no official API for the Display Conditions, and the team is still implementing the infrastructure for this feature, there might be implementations in the future for different input types and methods. For now, this is not part of this feature yet. In other words, the code you are analyzing is not ready to be extended by developers, and we do not recommend anyone to extend it because the infra for this feature has not been finished yet, and there might be changes applied in the future.

Development of more advanced integrations such as URL parameters, ACF, and WooCommerce takes time and requires a responsible review process. We have plans to include a lot of functionality and are releasing them as they get ready. No one is holding or "planning not to release" any functionality. They are simply not ready to be released yet. We do have milestones to reach, but we do not share this information with the public simply because things can change, complications can arise, and the timeframe can move. I'm afraid this time I cannot share this information with you. I hope you can understand.

Please, let's focus on what we have today. Test the new features and let us know how they work. This is really important, and it's better to raise issues now instead of posting comments after the release.

Thank you for showing interest in this feature! 🙏

[perks98]

@nicholaszein the only feedback I can give on this beta update currently (since it is a smaller one in terms of new features) is that:

• I don't think custom fields should all be listed under dynamic tags, it should have its own dynamic tag of custom fields then another select option to browse tags from a list.
• The post and page title display condition I think is really not good as I can't see a practical sense for it as the flaw is you can only select existing page titles and if those page titles change the display condition is still there so when you manually change it you have to find the new title. The business I work for has started pushing more SEO services which includes changing titles and slugs, even clients do that frequently, so these actions could break that condition without anyone knowing. Really you should have this under dynamic tags of post title where you can use comparators like 'contains' and let users use the new 'OR' feature to list more post titles as a starting point. I can understand wanting to be able to have a list of values to check against in one condition, but I don't think that is the best implementation. Maybe it should be adjusted so when you type something in and hit enter on your keyboard it adds that as a value for the list, which is manual input. I think it should have been a 'By Post' or 'By Page' where like with the page and post title display condition you can type and select multiple posts by name, but it is attached as a reference to that post, so if the post title or slug changes then the condition would still work as it is attached to that post, since it should be checking by post ID anywhays. Just my thoughts. (also a quick hacky way around this is to copy the widget JSON, update the condition manually adding in your own titles and paste from other site and now it checks against your input rather than existing page titles)
• It would be great to get more WordPress related display conditions (since this seems to be the focus) like the display conditions available in the theme component display conditions of direct child. Or would be good to have ones around 'is archive', 'is post' and so on so when using the template widget, the same template can appear different on other pages becoming more flexible.
• The only new things in the display conditions are the 'OR' grouping, post/page title and dynamic tags (with mixed in custom fields). From a few loose tests it seems to work fine overall. But the only condition I can see using currently on really simple sites is the featured image is set one and the date related ones. Would be better to extend the date related conditions so you can select a whole day, like the 7th so it would be the 7th of every month, and a whole month so then every December so it can add some Christmas widget to the page automatically, as general examples. Those would be great.

Side question: will this be available for developers to hook into officially when marked as stable or (hopefully) before that? (since in some cases it can take over a year to finish a feature as stable or merged to Core)

[nicholaszein]

Hi @perks98!

Thanks for the extensive feedback! It really helps us understand better our users' needs! 🙏

I don't think custom fields should all be listed under dynamic tags, it should have its own dynamic tag of custom fields then another select option to browse tags from a list.

Interesting. Why do you think they should be separated? Is it just an organization thing, or is there something more behind your suggestion?

The post and page title display condition I think is really not good as I can't see a practical sense for it as the flaw is you can only select existing page titles and if those page titles change the display condition is still there so when you manually change it you have to find the new title. The business I work for has started pushing more SEO services which includes changing titles and slugs, even clients do that frequently, so these actions could break that condition without anyone knowing. Really you should have this under dynamic tags of post title where you can use comparators like 'contains' and let users use the new 'OR' feature to list more post titles as a starting point. I can understand wanting to be able to have a list of values to check against in one condition, but I don't think that is the best implementation. Maybe it should be adjusted so when you type something in and hit enter on your keyboard it adds that as a value for the list, which is manual input. I think it should have been a 'By Post' or 'By Page' where like with the page and post title display condition you can type and select multiple posts by name, but it is attached as a reference to that post, so if the post title or slug changes then the condition would still work as it is attached to that post, since it should be checking by post ID anywhays. Just my thoughts. (also a quick hacky way around this is to copy the widget JSON, update the condition manually adding in your own titles and paste from other site and now it checks against your input rather than existing page titles)

So basically you would like to instead of having a multiselect that is not bound to the post object, but only to the title, it should have an option to choose "contains" so you can type your own text?

Moreover, you think it would be nice if there was an option to select by Post/Page/CPT based on the object (ID)?

It would be great to get more WordPress related display conditions (since this seems to be the focus) like the display conditions available in the theme component display conditions of direct child. Or would be good to have ones around 'is archive', 'is post' and so on so when using the template widget, the same template can appear different on other pages becoming more flexible.

The child of Page Parent is already possible:

However, the other ones might be useful as you said. Good points! We are definitely not over, we will continue to add more conditions as the development matures. Thanks for the suggestions! 💪

[...] Would be better to extend the date related conditions so you can select a whole day, like the 7th so it would be the 7th of every month, and a whole month so then every December so it can add some Christmas widget to the page automatically, as general examples. Those would be great.

That's actually a great idea! I think I saw the team working on researching this possibility. I'll definitely pass this on to them! 😉

will this be available for developers to hook into officially when marked as stable or (hopefully) before that? (since in some cases it can take over a year to finish a feature as stable or merged to Core)

Yes, once we deem it stable and fully featured, we will lift the flag on not recommending 3rd-party devs from extending it. Our plan is to make it ready by the end of this quarter. Things might change, so please be aware, but that's our goal. We will let you know when it's ready to be extended! 😉

[perks98]

Interesting. Why do you think they should be separated? Is it just an organization thing, or is there something more behind your suggestion?

It is for organising and for less clutter. For sites with historic meta data it can pick them up, and themes can add their own meta data too, see GIF below of what I mean. Also as more dynamic tags are added over more updates it just makes it so you don't have to scroll so much to find what you need. If it is under its own tag then you can then, in future, add another tag for custom meta input separate to the already listed custom meta suggestions.

So basically you would like to instead of having a multiselect that is not bout to the post object, but only to the title, it should have an option to choose "contains" so you can type your own text?

Moreover, you think it would be nice if there was an option to select by Post/Page/CPT based on the object (ID)?

I think with the post/page title display condition I think the current implementation would be better if you could type your own text and when you hit enter on your keyboard register that as an option rather than type to find an existing page from a list, so remove the part where you select from existing pages maybe. Or add an additional option under the dynamic tags section for raw text input to use 'contains' and other comparators, if that makes sense. Also yes I think we should be able to select by page or post object, so like the post/page title display condition implementation you select by title but it saves the data by post ID (the post ID the end user doesn't see).

The child of Page Parent is already possible:

Odd, I must have overlooked it greatly. Maybe my suggestion for this is wording consistency, for example on the theme display conditions the wording is as 'Direct Child Of' or 'Any Child Of' so the condition is recognised from both display condition facilities. But that is just being picky, as long as it works.

That's actually a great idea! I think I saw the team working on researching this possibility. I'll definitely pass this on to them! 😉

I think it would be great to implement it in this update (since it is small) as I know your marketing team love to push these updates out, so it would give them the idea to push in users mind the idea of styling your website for any season without needing to directly push updates out i.e. valentines day, mothers day, Christmas month, black Friday deals day, Halloween week and other seasons.

Yes, once we deem it stable and fully featured, we will lift the flag on not recommending 3rd-party devs from extending it. Our plan is to make it ready by the end of this quarter. Things might change, so please be aware, but that's our goal. We will let you know when it's ready to be extended! 😉

That's great news, thanks for letting me know. If certain conditions don't get added by the end of the quarter I will plan to start adding conditions then.

[nicholaszein]

Hi @perks98!

Thank you for the feedback! 🙏

It is for organising and for less clutter. For sites with historic meta data it can pick them up, and themes can add their own meta data too, see GIF below of what I mean. Also as more dynamic tags are added over more updates it just makes it so you don't have to scroll so much to find what you need. If it is under its own tag then you can then, in future, add another tag for custom meta input separate to the already listed custom meta suggestions.

I see, your logic makes total sense. We are discussing this internally, and may change this behavior! Thanks!

I think with the post/page title display condition I think the current implementation would be better if you could type your own text and when you hit enter on your keyboard register that as an option rather than type to find an existing page from a list, so remove the part where you select from existing pages maybe. Or add an additional option under the dynamic tags section for raw text input to use 'contains' and other comparators, if that makes sense. Also yes I think we should be able to select by page or post object, so like the post/page title display condition implementation you select by title but it saves the data by post ID (the post ID the end user doesn't see).

Perfect! That's awesome feedback! Thank you for sharing this! 🙏

Odd, I must have overlooked it greatly. Maybe my suggestion for this is wording consistency, for example on the theme display conditions the wording is as 'Direct Child Of' or 'Any Child Of' so the condition is recognised from both display condition facilities. But that is just being picky, as long as it works.

I think this also makes sense. Keeping consistency is always good for User Experience! Our team will take a look at this. 😉

I think it would be great to implement it in this update (since it is small) as I know your marketing team love to push these updates out, so it would give them the idea to push in users mind the idea of styling your website for any season without needing to directly push updates out i.e. valentines day, mothers day, Christmas month, black Friday deals day, Halloween week and other seasons.

Thanks for the suggestion! Indeed it's something people could benefit from. I'm not sure it would be possible to implement this logic right now (every X date). So this would need to be something implemented and marketed in the future.

That's great news, thanks for letting me know. If certain conditions don't get added by the end of the quarter I will plan to start adding conditions then.

Please, wait until we confirm this feature can be extended safely. We might still apply breaking changes to the code.

[nmbrthirteen]

No info about the Components feature again? Any future ideas regarding this?

https://github.com/orgs/elementor/discussions/22203

[nicholaszein]

Hello @nmbrthirteen!

Thank you for joining this beta discussion! We are monitoring that suggestion. Unfortunately, it is not part of the goals we set up for this year's Q1. But we will consider it for future releases.

We would love to know your feedback about this one though. Have you tested this beta yet? How about the new OR combinatória in Display Conditions. Is it working as expected for you?

Please, consider testing this version as suggested in the release post, and let us know if you have any insights on these new features.

Thanks! 🙏

[jlemonz]

i tested the reduced dom a couple times but i dont see any decline in dom elements? I use gtmetrix to test. And verified the file is 3.20 beta.

[m1ga]

see https://github.com/orgs/elementor/discussions/25200#discussioncomment-8518093

it is not reducing DOM elements, it is just removing an attibute on the div so the HTML size will be smaller (less text) but still the same amount of DOM elements.

[mbaierl]

Will display conditions now work if a tag/category is selected on a Blog Single template? Does not work in 3.19.

[nicholaszein]

Hello @mbaierl!

Thank you for joining the discussion! Can you please elaborate on your question? I don't want to give you the wrong answer based on the wrong interpretations.

What exactly are you trying to achieve, in which way?

[mbaierl]

Hi @nicholaszein , the following scenario:

1. Blog post A has a tag "no-toc"
2. Blog post B has no tag "no-toc"
3. In the "Single Post" template for the blog posts I want to hide a certain element if the tag "no-toc" is not set. (see https://cln.sh/7MBQdpW9 )
4. So Blog post A should show that element, Blog post B should not show it.

However the display conditions don't work, as they seem to match against the "Single post template" and not against the Blog posts.

[nicholaszein]

Thanks for explaining @mbaierl! 🙏

I see the problem here is that you are trying to hide something using a condition. For now, hiding is not an option. When you use the Display Conditions you are showing something based on the conditions you set. When you enable Display Conditions, an element will only APPEAR if the condition is met. So it's already hidden by default when using the Display Conditions, unless a condition is met.

So in your case, you need to do the opposite of what you are trying to do:

1. Instead of trying to hide an element if the Post > In Tags > Is Not > no-toc (hide is not an option);
2. Try setting the condition so an element can appear if the Post > In Tags > Is Not > no-toc.

Here's a video of it working as expected:

Posts.Elementor.Debug.WordPress.-.27.February.2024.mp4

We are researching the possibility to add an option to select if you want to Show or Hide, but for not, if you apply Display Conditions, an element will always be hidden unless a condition is met.

I hope this clarifies your question. 😉

[avivu]

Hi all,

We just released Elementor v3.20 Beta 2.

Font Awesome 6 update:
We are continuing to work on updating the FontAwesome library, a significant change impacting every part of Elementor elements and affecting all of our users. We are dedicating the time to continue development to ensure a seamless migration.

In the meantime, we've added the option to use the X and Threads icons across all Elementor elements in this version. Additionally, these icons have been integrated into the Share Buttons widget.

 

The versions include the following:

Free version

• Tweak: Added X icon to Font Awesome icon library
• Tweak: Added Threads icon to Font Awesome icon library
• Fix: Template is not importing when the Unfiltered File option is disabled

Pro version

• Tweak: Added X and Threads social networks to Share Buttons widget
• Security Fix: Addressed security weaknesses in Dynamic Tags
• Fix: Archive Title dynamic tag won't work properly when using the 'Is' operator in Display Conditions
• Fix: Dynamic tags operators are case sensitive in Display Conditions

–

Thank you!

[ayoubkhan558]

Dynamic Conditions lacks support for ACF fields 😔😕🥺

[nicholaszein]

Hi @ayoubkhan558!

We have plans to include support to ACF, but we haven't finished the integration yet. This is going to be released in a future version. 😉

Have you tested this beta yet? We would love to know your thoughts about it! Please, test it out and give us your feedback! 🙏 💪

[black-eye]

I haven't got much time to test the conditions yet, so I've got only one UX observation: please don't repeat the same mistake as with the theme templates conditions. Although, there's a plenty of free space in the popup box, there's a very little room for the last input, which can be tricky if the long names, or even multiple items, are involved.

The screenshot is from version 3.19. From the other screenshots here I can see there might be some UI tweaks in 3.20, but the main point stays the same - the available space is not fully utilized and I don't think there's a real reason for it.

I created an issue for the theme conditions more than 3 years ago, but it didn't get much attention: #13525

[toineenzo]

@nicholaszein Maybe it's good to add an alt-text to the dropdowns and pills? That way, by hovering over it, you can read the full text even when it doesn't with in the box

[nicholaszein]

Sorry to burst your bubble @lensbreak, I know you love to take a punch. It's not spaghetti code. It's simply a special field that handles multiple actions.

It has to show a pill, a space for you to type stuff, a space for the "clear all" button, and a space for the drop-down button. It's a multi-select, multi-purposed field that simplifies the UI. But when it has little space to breath, it can have a negative impact on UX.

We are talking about changing the behavior of the component. Not changing the styles. It's not something you do in a couple of minutes. It means yes, we need to improve the UX by changing the UI. Something like adding a title or alt attribute to the pills like @toineenzo suggested for example is a good way of an action that can be done in a small length of time. Anything else would require more time.

Your understanding and support would mean a lot. 👍

[black-eye]

@black-eye

It's not rocket science @black-eye ,its simply a change in a component that does a lot of things in a specific way right now. It's not like you change a couple of css rules and call it solved. If it was, I'd do it myself.

Well, since you mentioned it, I used to have a little hot fix for myself, when I needed it. It were these few lines of CSS:

#elementor-theme-builder-conditions #elementor-theme-builder-conditions-controls .elementor-repeater-fields-wrapper {
    max-width: 1000px;
}
/* this can do funky stuff on small screens, use it only when needed */
#elementor-theme-builder-conditions #elementor-theme-builder-conditions-controls .elementor-control-type-query {
    width: 350px
}

They were placed in CSS file added via this hook:

function my_plugin_editor_styles() {
	wp_register_style( 'elementor-editor-css-update', WPBF_CHILD_THEME_URI . '/elementor-editor-update.css' );
	wp_enqueue_style( 'elementor-editor-css-update' );
}
add_action( 'elementor/editor/after_enqueue_styles', 'my_plugin_editor_styles' );

It's been a while since I have used it, so I don't recall how I came up with the second rule. But the first rule simply widens the maxwidth from 800px to 1000px and is good enough for most cases. No big deal, but it can help with narrow space. This is what I meant by a small tweak, that can help and doesn't have any bad consequences.

I have tried it right now, just for a test and it still works, at least for the theme builder. Here is before and after:

Can you spot the diference? Feel free to try it yourself...

[nicholaszein]

@black-eye Yes, this would be great, however, if we are going to fix this, we might take another route, and change not only the UI, but the workflow a little. That's what I meant. The idea is not to "hack" something away, although your solution is awesome, no doubt about it. Much more legible!

Thanks for sharing it! 🙏

[perks98]

Just found a problem. It seems once the name of the post/page is stored in the condition it doesn't change. For example using the parent page display condition, if you select a parent page it works, but when you change the name of this parent page it doesn't change in the display conditions after reloading the editor which would confuse people as the condition is then not true, but it is still assigned to the correct page so the condition works as it technically should. See video below. Please fix so the title of the page in the condition gets the correct latest title.

2024-02-29.09-29-06.mp4

[nicholaszein]

Good catch @perks98! 💪

I can confirm the option doesn't update.

[avivu]

Hi all,

We just released Elementor v3.20 Beta 3.

The versions include the following:

Free version

• Fix: Widgets are not appearing in the widget panel when using various 3rd party plugins

Pro version

• Fix: Page Transitions not working inside the editor
• Fix: Page Transitions feature and Load Font Awesome 4 Support cause a console error

–

Thank you!

[DanielCyran]

@avivu Could you add an ajax product search to Elementor PRO?

[nicholaszein]

Hello @DanielCyran!

Thank you for joining the discussion. Please, for feature requests search for existing ones, or submit your own. We are here to discuss this beta, and we would love to know your feedback about this release. Thanks.

[DaNTaF]

#25204 UI bug still happens in v3.20.

Does Display Conditions work for Custom Code? for example, I want specific code for mobile users ?

Edit: Also the font color is still broken: https://i.imgur.com/t3rs32T.gif

[nicholaszein]

Hello @DaNTaF!

Welcome to the discussion!

Currently there is no official public API for Display Conditions, as this feature is still in development. However, we do plan to release a public API that can be used to extend this feature.

Please keep the conversation about this beta. Thanks

[m1ga]

Agree! Every merged PR builds a version: https://github.com/elementor/elementor/actions/workflows/latest-release.yml and releases it https://github.com/elementor/elementor/releases

There are ways around it but not sure what their workflow is. In a different project (Titanium SDK, mobile app framework) we build after every PR too but we just have an own release download page https://downloads.titaniumsdk.com/builds so we don't have a release on github all the time. That is only for real releases 😉

[nicholaszein]

Sorry @fabigrafo. This is part of our workflow.

[toineenzo]

Maybe a good idea to mark those releases with the "Pre-release" label? :)

[nicholaszein]

Unfortunately that's not possible.

[avivu]

Hi all,

We just released Elementor v3.20 Beta 4.

The versions include the following:

Free version

• Fix: Compatability issues with various 3rd party plugins when Optimize Image Loading feature is activated (✅ 🧩 🐞 Compatibility issue with FacetWP caused by Optimize Image Loading feature #24226)

Pro version

• Fix: Popups flicker when scrolling down on a page

–

Thank you!

[nicholaszein]

Hey everyone!

Elementor and Elementor Pro version 3.20.0 were released to the public! 🚀 🥳 🙌

We'd like to thank you all for contributing to this discussion, and for sharing such insightful feedback. It was a great discussion! We'll surely take all your suggestions into consideration. 🙏

Special thanks go to our contributors who helped make this release possible:

• @perks98
• @m1ga
• @hitsgee
• @portrayaloflife
• @Joliamendi
• @lensbreak
• @toineenzo
• @jlemonz
• @mbaierl
• @black-eye

Thank you! See you on the next one! 💪 😉

Cheers 🥂

Changelogs of Elementor Core and Pro
Elementor Core
Elementor Pro