JetEngine v3.2.0 Beta

[MjHead]

Hi,

We are almost getting ready to release JetEngine v3.2.0 and we would like to ask you to help us test JetEngine v3.2.0 Beta.

You can download beta version from your Crocoblock account.

Please note that is a beta version, not stable release, so its not ready to use on production websites!

Generate Advanced SQL Queries with AI

For now, this functionality will be significantly limited and will run in Beta mode. As soon as we get feedback from users and understand whether they need this functionality at all, the limitations part can change greatly. Currently, the limitations include:

• AI functionality is only available after license activation.
• The functionality is available for those who bought the JetEngine plugin separately and those owning a Crocoblock subscription that includes JetEngine.
• AI functionality is only available for users owning the master key, not for subkeys.
• Currently, the usage limits are set to 30 AI requests per month for Lifetime subscribers and 5 for other license owners. These are temporary limits; we’ll reassess them in the future.

How it works

To make it easier for a JetEngine newbie to navigate and figure out that we actually have such functionality, the SQL Query type has been renamed into SQL/AI. For the same purpose, we moved the Advanced mode switcher to the first place in the options and renamed it into Advanced/AI mode – https://tppr.me/OmCOT.

When Advanced/AI mode is enabled, as before, the Query Builder UI switches to the manual input of the query. We have added a custom icon to the field for entering the main query, allowing users to open the UI for automatic query generation

When you click on the icon, you will see a pop-up for query generation

The pop-up includes:

• a field for entering a prompt (a text box describing the query);
• instructions on how to write a prompt;
• prompt examples.

The prompt examples are clickable. When you click on any given example, it will be added to the prompt field, and you will be able to generate a query based on it.

After you enter the prompt and click the “Generate query” button, the query generation will start. If successful, the generated query will be added to the same field instead of the prompt, where you can edit and use it or generate a new one.

Under the input field with the generated query, you’ll see a notice saying that the query is actually generated using AI, and there is no 100% guarantee that it will work exactly as the user needs. Hence, you need to review the query carefully before using it.

Performance Optimization Tweaks

This is the first iteration of adding options to the Performance section. More options will be added in the next releases. So far, it’s hard to name the entire list because it depends on our ability to implement some options and maintain at least partial backward compatibility.

DOM Optimization

This option applies to the Dynamic Field and Dynamic Link widgets in all supported page builders. With the rest of the widgets, there is no way to reduce the DOM size yet, because of backward compatibility issues related to functionality. As to Dynamic Field and Dynamic Link, there are compatibility issues too, but they are related to styling, not functionality. After you enable Optimize DOM, it will be necessary to restyle the Dynamic Field and Dynamic Link widgets everywhere you use them.

In each of the builders, this option works a little differently, which is due to the builders’ peculiarities.

Disable view for different builders

Options are displayed at all times, regardless of whether the given builder is installed. When one of the views is disabled, all the JetEngine logic will be completely eliminated from the corresponding builder.

• when disabling the Elementor view – widgets for Elementor and dynamic tags are disabled;
• when disabling the Block view – blocks for the Block editor and dynamic data are disabled;
• when disabling the Bricks view – widgets for the Bricks builder are disabled.

Moreover, if you disable all views at once, the Listings item will disappear from the WordPress admin panel – https://tppr.me/OVTDg – because there are no views left that could process Listing items.

New Query Type: Current WP Query

We have added a new query type called Current WP Query. This query type has no additional settings; it always returns data from the current global WP_Query. This query type returns only posts. Here are the possible return options:

• On any single page – it can output one post, which can be the page itself (post, CPT);
• On the CPT archive – the latest posts of this CPT. The number of returned posts is determined by the global setting Blog pages show at most – https://tppr.me/U5vju;
• On taxonomy archives – posts from the current taxonomy term;
• On the search results page – posts that match the search criteria.
• All these results can be returned by the same query. From a technical standpoint, it makes no sense to create more than one query of this type since all created queries will work the same way.

Because this query type always inherits the global $wp_query object, it has no other settings except for Posts per page – https://tppr.me/vdJsh (because the number of posts may vary for the same page type depending on design). For one query, you can set as many different Posts per page values as you like. It depends on the page type where the query will be used – https://tppr.me/pVsW7.

IMPORTANT The logic for this query type is tailored to always use the current global $wp_query object for the current page. Therefore, if we want to change the number of posts on the page when the JetEngine query is being executed, we will physically have to send another request to the database since the global $wp_query object is set way before the query execution. That’s why the only remaining option is to change the number of posts globally when the global $wp_query object is being received. What it means:

• Posts per page settings that you set for the Current WP Query apply to the global $wp_query object, regardless of whether the Current WP Query will be used on the page type for which you’ve assigned the number of posts;
• to clarify the previous point – if you’ve assigned the Posts per page setting in the Current WP Query, for example, for the Authors archive, and then used some widget that does not support Current WP Query to build the Authors archive page or did not change the author page template at all, the number of posts will still be fetched from the Current WP Query;
• if you have created several queries with the Current WP Query type and assigned Posts per page to each of them for the same page type, each query will apply its setting globally. On the front end, just one query will work – the last added one.

Listing Grid. Columns Number: Auto

We have added one more option to the Columns Number setting called Auto – https://tppr.me/GXQtv. After selecting it, you will see a new Column Min Width option – https://tppr.me/jARoO. It is not the exact width of the column; the option sets a minimum needed value for the column width. The actual width will slightly exceed the minimum value, and that width will be needed to fill up the selected container with columns.

This option is incompatible with the masonry grid layout because it needs a fixed width and a fixed number of columns. Therefore, the masonry grid toggle is hidden if the number of columns is set to Auto.

You can combine this option with the scroll slider but don’t forget it requires a fixed column width to work out. For the Block editor, we have three options regarding the number of columns. Three new options for the minimum width have been added accordingly – for desktop, tablet, and mobile devices.

JetEngine Meta Fields Displayed in Native Product Settings and WooCommerce Variations

We have added additional options to JetEngine’s core, which will appear at the stage of meta box creation in the Meta Box for field. These are WooCommerce Product Data and WooCommerce Product Variation options – https://tppr.me/wqjJH. Let’s dive in.

WooCommerce Product Data

This option will add meta fields to the Products settings panel – https://tppr.me/uQRal.

When selecting WooCommerce Product Data in the Visibility Conditions section, you will see an additional field for selecting the meta boxes display. If you leave these settings empty, a new tab will be created in the product panel. This tab will contain the name of this meta box and apply to all product types (https://tppr.me/cUseI). When clicking on this tab (by default, it will be the last one on the list – https://tppr.me/yGQjO), we will see the meta boxes’ content.

The Product Data field in the Visibility Conditions section has the following parameters – https://tppr.me/T345H. The first parameter, Custom, will be selected by default, as mentioned. Besides, this very parameter will create a separate tab for the meta box and store the fields in a separate panel. If you select the Custom option, there will be additional fields for configuring the meta box display.

• Exclude/Include https://tppr.me/37It2 – it is disabled by default, so the meta box will be shown for all product types. Using this option, you can include meta boxes and exclude them from certain product types. After picking an option in the Exclude/Include selector, the following control will appear;
• Exclude or Include Product Types https://tppr.me/Q0GwO – in this control, you can choose product types in which the meta boxes will be displayed or hidden, according to the option selected in the Exclude/Include field;
• Tab Priority https://tppr.me/Qk7Em – the last display parameter is responsible for the numeric priority of the meta box against other tabs and is set as an integer. The smaller the number, the higher the tab will be displayed in the list.

To make the setup clear, these settings – https://tppr.me/Qk7Em – will create a Custom tab, which will be displayed only for Simple and Variable product types, and the tab itself will be located high on the list – https://tppr.me/NEqux.

All other parameters are basically the already existing tabs in the product panel – https://tppr.me/xEajy. When choosing one of the existing standard tabs, the content of the meta box will be added to the end of the existing panel (settings – https://tppr.me/mphz6 and the result – https://tppr.me/QVp1O). In this case, it should be noted that not all of these tabs are displayed for all product types. For example, the General tab is not displayed for Grouped products, and the Shipping tab is displayed only for Simple and Variable products. You can find out more about standard tab settings by following the link: https://woocommerce.github.io/code-reference/files/woocommerce-includes-admin-meta-boxes-class-wc-meta-box-product-data.html#source-view.82. Also, follow the link – https://woocommerce.com/document/editing-product-data-tabs/ – to learn more about how you can use snippets to control the display of all other product panel tabs.

WooCommerce Product Variation

This option will add meta fields to the Variations settings panel – https://tppr.me/ehlX8.

When selecting the WooCommerce Product Variation option, one more additional field becomes available in the Visibility Conditions section. This field allows you to set the meta box’s display position and select in which part of the Variations panel the meta box will be displayed – https://tppr.me/dRqPD. For example, if we pick “Pricing” – https://tppr.me/wprNS – then it will be displayed immediately after the group of price fields.

In this case, it should be noted that some panels to which we can add fields are hidden by default and will be displayed only after some manipulations on the Variations panel itself. For example: if you choose the “Inventory” option (https://tppr.me/8XAkb), then initially, the meta boxes will not be displayed on the panel (https://tppr.me/1RZKm) despite the presence of some inventory settings. For that matter, you need to enable additional inventory settings (https://tppr.me/iXdAS), and right after, the fields will become available for editing.

Concerning Variations meta fields, there is a possibility to register and store variation data. This step was implemented for easier access to the data saved in the meta fields at the stage of variation selection on the product page (https://tppr.me/tRy8e). But since the variation selection process uses JavaScript to get the correct variation data, the only available way to display them is to modify the WooCommerce template file called variation.php, which can be found under woocommerce/templates/single-product/add- to-cart. For example, to display an additional custom field – https://tppr.me/9R0AZ.

Please note: at the time of display, {{{ data.variation.custom_field }}} there will always be data.variation, but customfield happens to be your meta field’s key – https://tppr.me/hqtp8. However, JavaScript is used for processing; for that matter, fields with a text-test-field key in the context of {{{data.variation.text-test-field}}} will show an error. We deem that when registering fields, the fields with a “-” sign will be transformed into the fields with a “” sign, meaning if the text-test-field field is submitted for registration, the result will be text_test_field. If we further need to refer to the field with a text-test-field key in the template, we need to remember that the key will be changed to text_test_field.

Another important thing: when editing a template, you should not do it in the main file because a) it's not a great idea, and b) the code will be removed the next time we update WooCommerce. Instead, to override this template, create a file called variation.php and place it in the woocommerce/single-product/add-to-cart folder of the child theme. If the folder doesn’t exist, create it via FTP or another available method.

It should also be noted that during registration, we do not process the field values in no other way. If we simply display them as they were registered in the database, the display of some fields will be quite poor, especially if we are talking about Checkbox or Media type fields. In this case, you should use the woocommerce_available_variation hook, which is described in detail here – https://woocommerce.github.io/code-reference/files/woocommerce-includes-class-wc-product-variable.html#source-view.364. In addition, we have added several modifications to both options’ field settings. For instance, we eliminated the possibility of selecting anything else but Field in the Object type setting – https://tppr.me/CVovO. Also, the Field width control has been hidden – https://tppr.me/3YdRL. In the Field type field, we have hidden the following fields – 'html', 'repeater', 'wysiwyg’ (https://tppr.me/e663J). In this case, although these fields work in the panel, they differ in their type from standard fields. To eliminate possible problems in the future, we will exclude them immediately. For WooCommerce Product Variation, we also hid the Conditional Logic control – https://tppr.me/ZShtd.

The meta boxes were implemented on the basis of the builder interface, which does not correspond to the look of the standard panel fields. Therefore, we changed the fields template and styled the fields themselves as native so they do not stand out – https://tppr.me/FaDwh. Certainly, there are some exceptions, such as Switcher, Checkbox, as well as post selection fields, Select2 and Color. For WooCommerce Product Data, there is also a repeater with a hybrid field display, taking something from the builder interface, something from styles written to resemble native fields.

Please leave your feedback and any found bugs or issues in the comments below

[oceandiveloper]

Finally we talk DOM. Thank you so much. Will test tomorrow. Just one thought:

This option applies to the Dynamic Field and Dynamic Link widgets in all supported page builders. With the rest of the widgets, there is no way to reduce the DOM size yet, because of backward compatibility issues related to functionality.

If backwards compatibility is such a big issue then why don't you add the optimized versions of the dynamic widgets as a new widget? Like “Dynamic Field 2.0“ or "Dynamic Image NEW“. Then users can choose which version they want to use. New projects can utilize the new versions whereas existing ones can keep the bloated legacy widgets or replace them successively as they see fit. No compatibility issues there. Legacy widgets wouldn't get new features but that's probably not an issue for those users who don't want optimize anyway. I've seen other Elementor Addons do that and find it a smart approach.

Love the AI functionality btw. It makes me wonder when we can use AI to build custom JetSmartFilters with SQL/AI queries.

[naturalwebcl]

Hi @MjHead

We have known that at present with Custom SQL query is not possible to use JSF to filter or paginate the results in a listing, it will be possible with the new release?

Thks. :)

[MjHead]

@oceandiveloper This is planned as next step, at the moment we still investigating how optimize not only output DOM size but also rendering itself. As for now it is just removing as much HTML wrappers as we can to keep functionality. Next steps will be:

• new element Dynamic Data or something like this. At the moment main problem here - to understand how we can speed up rendering of this element
• new way of rendering whole Listing Item. At the moment the problem here - each item in the listing has limited number of data which changed from item to item. But anyway each next item repeat some things related to chosen builder logic. We already experimented with caching of these things, but this could break compatibility with 3rd party widgets used in the listing item. So we still researching this issue.

When we resolve this problem - it also will resolve filtering speed problem. Because we already made tons of tests and all the tests shows the main problem with filtering response time - it is rendering of the results, not filtering process itself.

[MjHead]

@naturalwebcl I hope some solution will be added with one of 3.2.x updates, unfortunately can't give more exact ETA at the moment

[pauserratgutierrez]

@oceandiveloper This is planned as next step, at the moment we still investigating how optimize not only output DOM size but also rendering itself. As for now it is just removing as much HTML wrappers as we can to keep functionality. Next steps will be:

• new element Dynamic Data or something like this. At the moment main problem here - to understand how we can speed up rendering of this element
• new way of rendering whole Listing Item. At the moment the problem here - each item in the listing has limited number of data which changed from item to item. But anyway each next item repeat some things related to chosen builder logic. We already experimented with caching of these things, but this could break compatibility with 3rd party widgets used in the listing item. So we still researching this issue.

When we resolve this problem - it also will resolve filtering speed problem. Because we already made tons of tests and all the tests shows the main problem with filtering response time - it is rendering of the results, not filtering process itself.

Would bee cool to have only one Dynamic Widget (NEW) with a dropdown to choose whether we want to use it as Image, Field, Link... Like containers in Elementor, where we can choose Flex and Grid layouts. And add the ability to choose every source and data type in any Dynamic Widget mode.

[Joliamendi]

With the release of this version, query builder will become very attractive. So I wanted to request, please make query builder compatible with elementor loop builder. Currently, elementor has Query ID option in its loop builder, but we cannot use Jet Engine queries in elementor loop builder. I hope that compatibility with elementor loop builder will be provided in this version if possible.

[MjHead]

@Joliamendi Yes, we have this in the roadmap for 3.2.x branch

[pauserratgutierrez]

@Joliamendi Yes, we have this in the roadmap for 3.2.x branch

Is the roadmap public? Would be cool to see it!

[medienstuermer]

It would be so cool if we could use all functions of JetSmartFilters also with a Rest API Listing Grid. And also all the standard functions of a normal CPT listing grid: Quantity - Load More - Pagination etc.

[Michaelgimii]

A great update but unfortunately I can't test the beta version due to busy work. But I have two questions about this version.

Do we have to buy a subscription to use AI more than 30 times in a month?

Is AI just for building SQL queries, or can it build any query? For example, can we create a query using AI to only display products in category X?

[MjHead]

@Joliamendi Yes, we have this in the roadmap for 3.2.x branch

Is the roadmap public? Would be cool to see it!

At the moment there is no public version. We discussed this issue inside a team, but still not sure about public roadmap, because we often move some issues between versions, depends on users request or other reasons

[MjHead]

@Michaelgimii Yes, you can complete such request with AI query. You just need to use option Cast result to instance of object to Post or WC Product option to use all possibilities of Dynamic widgets and tags

[Joliamendi]

Does Sql AI support different languages? Or should we only communicate with it in English?

[Cosirax]

Hey there, nice to see, that JE v3.2 is on its way. Could you consider to add this verry important and needed fixes / requests:

https://github.com/Crocoblock/suggestions/issues/5639#issuecomment-1556133692 ( Open since Jul 13, 2022 )

It's literaly a bug which makes pages unusable.

[MjHead]

Does Sql AI support different languages? Or should we only communicate with it in English?

If you confident with English - better to use it, because it gives more precise results. But you can use any language recognized by Open AI (because under the hood it uses models from the Open AI API)

[Louisjdv]

Hello,

Isn't there a compatibility problem between JetFormBuilder (3.0.7) and JetEngine?

In my case, it's impossible to update user information in a meta box using a form.

Thanks for your help!

[Louisjdv]

As for WooCommerce, it's working perfectly, so we're really pleased with this new possibility.

I haven't seen any other bugs for the moment.

[Lonsdale201]

@oceandiveloper This is planned as next step, at the moment we still investigating how optimize not only output DOM size but also rendering itself. As for now it is just removing as much HTML wrappers as we can to keep functionality. Next steps will be:

• new element Dynamic Data or something like this. At the moment main problem here - to understand how we can speed up rendering of this element
• new way of rendering whole Listing Item. At the moment the problem here - each item in the listing has limited number of data which changed from item to item. But anyway each next item repeat some things related to chosen builder logic. We already experimented with caching of these things, but this could break compatibility with 3rd party widgets used in the listing item. So we still researching this issue.

When we resolve this problem - it also will resolve filtering speed problem. Because we already made tons of tests and all the tests shows the main problem with filtering response time - it is rendering of the results, not filtering process itself.

This is of course a personal opinion, but I very rarely use widgets from other developers. What's in Crocoblock is plenty. What JetEngine gives you is enough. I for one wouldn't mind an optimized new Listing with only in-house compatible widgets. To me, speed means more than a few fancy, cute, widgets. Thanks for telling us a bit more detail about this, by the way, and it's good to know you're working on finding a solution. :)

[SolunaCG]

@oceandiveloper This is planned as next step, at the moment we still investigating how optimize not only output DOM size but also rendering itself. As for now it is just removing as much HTML wrappers as we can to keep functionality. Next steps will be:

• new element Dynamic Data or something like this. At the moment main problem here - to understand how we can speed up rendering of this element
• new way of rendering whole Listing Item. At the moment the problem here - each item in the listing has limited number of data which changed from item to item. But anyway each next item repeat some things related to chosen builder logic. We already experimented with caching of these things, but this could break compatibility with 3rd party widgets used in the listing item. So we still researching this issue.

When we resolve this problem - it also will resolve filtering speed problem. Because we already made tons of tests and all the tests shows the main problem with filtering response time - it is rendering of the results, not filtering process itself.

Would bee cool to have only one Dynamic Widget (NEW) with a dropdown to choose whether we want to use it as Image, Field, Link... Like containers in Elementor, where we can choose Flex and Grid layouts. And add the ability to choose every source and data type in any Dynamic Widget mode.

I fully agree! Plus imo it´d be very handy if we could use multiple dynamic fields within one widget. Cause that´d then solve another problem that Elementor (and as far as I know Crocoblock?!) has. The problem for Elementor is mentioned here: https://github.com/elementor/elementor/issues/19402#issuecomment-1565692924

I´m currently working on a website for renting apartments and there are many situations where I have one textblock where I need to call multiple dynamic fields. Sentences be like:

"Our apartment {variable-of-apartment-name} is {variable-of-apartment-size} big and offers room for up to {variable-of-max-amount-of-people}."

[MjHead]

@SolunaCG For your case you can use JetEngine shortcodes inside Text editor widget:

• Generate shortcode - https://tppr.me/nbef9
• Use generated shortcodes inside Text editor widget - https://tppr.me/rF7Jf
• Get the result on the front - https://tppr.me/cxaAb

Shortcode uses the same render class as Dynamic Field widget, so it has the same possibilities. Even more - in shortcode you can combine multiple callbacks inside single shortcode

[MjHead]

@Lonsdale201 The single problem - it will be not so fast as we want. But I'll keep the community updated in Facebook. It was our mistake - we waited with this to long, trying to resolve the problem without radical methods. But performance problem at the moment became most important and bootle neck for the potential growth and adding any other features, so the work is started. And as I said - we'll keep community updated when get any results to share

[SolunaCG]

@SolunaCG For your case you can use JetEngine shortcodes inside Text editor widget:

• Generate shortcode - https://tppr.me/nbef9
• Use generated shortcodes inside Text editor widget - https://tppr.me/rF7Jf
• Get the result on the front - https://tppr.me/cxaAb

Shortcode uses the same render class as Dynamic Field widget, so it has the same possibilities. Even more - in shortcode you can combine multiple callbacks inside single shortcode

Thank you so much!! That´s what I was looking for! Sorry the offtopic since this was already implemented and I just didn´t know how it worked... 🤦‍♀️

[oceandiveloper]

OK, I finally found the time to test a bit. The first issue I have is with the dynamic link icon after turning on Optimized DOM. When uploading an SVG and choosing "Icon Position" as "Before Label", the icon still shows up after the label.

Also the icon gap is not applied properly because of that (both horizontal and vertical icon position).

[MjHead]

@oceandiveloper Thanks for the report. We also found this problem during testing few days ago. And just uploaded 3.2.0-beta2 version with fix for this issue and couple more. It already available in you account for download. Could you please download and test it when have time to confirm the issue is gone.

[MjHead]

Hello,

Isn't there a compatibility problem between JetFormBuilder (3.0.7) and JetEngine?

In my case, it's impossible to update user information in a meta box using a form.

Thanks for your help!

Hi @Louisjdv! Thanks for the report. Could you please describe your set up a bit more detailed? Or maybe export your form and attach it there (export file doesn't contain any sensitive data so it's safe to attach it) Because I just tested basic form to update single meta field of current user and works fine for me.

[Louisjdv]

Hello, Isn't there a compatibility problem between JetFormBuilder (3.0.7) and JetEngine? In my case, it's impossible to update user information in a meta box using a form. Thanks for your help!

Hi @Louisjdv! Thanks for the report. Could you please describe your set up a bit more detailed? Or maybe export your form and attach it there (export file doesn't contain any sensitive data so it's safe to attach it) Because I just tested basic form to update single meta field of current user and works fine for me.

Hello,

The problem has been solved. It was an internal problem with JetFormBuilder and has been fixed with support.

Have a nice day

[Michaelgimii]

Hi

Glossaries support for Admin Columns

I apologize for asking this question here, but This feature was added in version 3.1.6 but I can't find it. Am I wrong?

[MjHead]

@Michaelgimii If you are using Glossary as source for select, radio, checkbox meta field, and want to show this meta field value in admin column (I mean not value but appropriate label from Glossary) - you can use one of this custom callbacks:

[befox-design]

Bricks Builder still getting Fatal error:

Full error with listing grid is here: Fatal error: Uncaught Error: Call to undefined method Bricks\Helpers::get_file_contents() in /data/web/virtuals/302605/virtual/www/domains/trade-skipper.cz/wp-content/plugins/jet-engine/includes/components/bricks-views/listing/assets.php:226 Stack trace: #0 /data/web/virtuals/302605/virtual/www/domains/trade-skipper.cz/wp-content/plugins/jet-engine/includes/components/bricks-views/listing/assets.php(95): Jet_Engine\Bricks_Views\Listing\Assets::jet_load_webfonts('\n/* GLOBAL CLAS...', '1542') #1 /data/web/virtuals/302605/virtual/www/domains/trade-skipper.cz/wp-content/plugins/jet-engine/includes/components/bricks-views/listing/manager.php(184): Jet_Engine\Bricks_Views\Listing\Assets::generate_inline_css('1542') #2 /data/web/virtuals/302605/virtual/www/domains/trade-skipper.cz/wp-content/plugins/jet-engine/includes/components/bricks-views/elements/listing-grid.php(1378): Jet_Engine\Bricks_Views\Listing\Manager->render_assets('1542') #3 /data/web/virtuals/302605/virtual/www/domains/trade-skipper.cz/wp-content/themes/bricks/includes/elements/base.php(2158): Jet_Engine\Bricks_Views\Elements\Listing_Grid->render() #4 /data/web/virtuals/302605/virtual/www/domains/trade-skipper.cz/wp-content/themes/bricks/includes/ajax.php(309): Bricks\Element->init() #5 /data/web/virtuals/302605/virtual/www/domains/trade-skipper.cz/wp-content/themes/bricks/includes/builder.php(1994): Bricks\Ajax::render_element(Array) #6 /data/web/virtuals/302605/virtual/www/domains/trade-skipper.cz/wp-content/themes/bricks/includes/builder.php(1900): Bricks\Builder::query_content_type_for_elements_html(Array, 1374) #7 /data/web/virtuals/302605/virtual/www/domains/trade-skipper.cz/wp-content/themes/bricks/includes/builder.php(254): Bricks\Builder::builder_data(1374) #8 /data/web/virtuals/302605/virtual/www/domains/trade-skipper.cz/wp-includes/class-wp-hook.php(308): Bricks\Builder->enqueue_scripts('') #9 /data/web/virtuals/302605/virtual/www/domains/trade-skipper.cz/wp-includes/class-wp-hook.php(332): WP_Hook->apply_filters(NULL, Array) #10 /data/web/virtuals/302605/virtual/www/domains/trade-skipper.cz/wp-includes/plugin.php(517): WP_Hook->do_action(Array) #11 /data/web/virtuals/302605/virtual/www/domains/trade-skipper.cz/wp-includes/script-loader.php(2194): do_action('wp_enqueue_scri...') #12 /data/web/virtuals/302605/virtual/www/domains/trade-skipper.cz/wp-includes/class-wp-hook.php(308): wp_enqueue_scripts('') #13 /data/web/virtuals/302605/virtual/www/domains/trade-skipper.cz/wp-includes/class-wp-hook.php(332): WP_Hook->apply_filters(NULL, Array) #14 /data/web/virtuals/302605/virtual/www/domains/trade-skipper.cz/wp-includes/plugin.php(517): WP_Hook->do_action(Array) #15 /data/web/virtuals/302605/virtual/www/domains/trade-skipper.cz/wp-includes/general-template.php(3049): do_action('wp_head') #16 /data/web/virtuals/302605/virtual/www/domains/trade-skipper.cz/wp-content/themes/bricks/header.php(7): wp_head() #17 /data/web/virtuals/302605/virtual/www/domains/trade-skipper.cz/wp-includes/template.php(783): require_once('/data/web/virtu...') #18 /data/web/virtuals/302605/virtual/www/domains/trade-skipper.cz/wp-includes/template.php(718): load_template('/data/web/virtu...', true, Array) #19 /data/web/virtuals/302605/virtual/www/domains/trade-skipper.cz/wp-includes/general-template.php(48): locate_template(Array, true, true, Array) #20 /data/web/virtuals/302605/virtual/www/domains/trade-skipper.cz/wp-content/themes/bricks/template-parts/builder.php(2): get_header() #21 /data/web/virtuals/302605/virtual/www/domains/trade-skipper.cz/wp-includes/template-loader.php(106): include('/data/web/virtu...') #22 /data/web/virtuals/302605/virtual/www/domains/trade-skipper.cz/wp-blog-header.php(19): require_once('/data/web/virtu...') #23 /data/web/virtuals/302605/virtual/www/domains/trade-skipper.cz/index.php(17): require('/data/web/virtu...') #24 {main} thrown in /data/web/virtuals/302605/virtual/www/domains/trade-skipper.cz/wp-content/plugins/jet-engine/includes/components/bricks-views/listing/assets.php on line 226

[sheraz73427]

I have used a complex Advanced SQL query but the problem I am facing with that is that the Jet Smart Filters are not working with that queried results. But the results are pretty fine and accurate I am happy with that but I want that filters to be worked with Advance SQL too.

[machachen]

@Joliamendi Yes, we have this in the roadmap for 3.2.x branch

Now the Croco team is rolling out the v3.3.0 Does that mean there won't be such feature going forward?

https://github.com/Crocoblock/suggestions/issues/6738

Thanks!

[atiqsamtia]

Why would you remove WYSIWYG field type in WooCommerce? I have a legit usecase and I can't select WYSIWYG because you simply removed that option—no valid explanation.