JetEngine v3.3.0 Beta

[MjHead]

Hi,

We are almost getting ready to release JetEngine v3.3.0 and we would like to ask you to help us test JetEngine v3.3.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!

Location and Distance filter type for JetSmartFilters

General Terms

The new filter type works only in conjunction with Geo Search – https://tppr.me/HcQDe. To be specific, it can work only combined with a query by the JetEngine Query Builder, which uses Geo Search. This is a necessary limitation since the filter transmits the geo point and distance (search radius). A search by posts must occur in this given radius (the distance from the selected point).

It’s a very specific data format that needs to be somehow integrated into the query. Geo Search, in this case, acts as a gateway through which the filter data and the request to the database are connected. Currently, Geo Search is available for the following query types:

• Posts Query;
• Users Query;
• Terms Query;
• CCT Query.

UI

On the front end, the filter looks like a text input for location entry and a select field for choosing a distance (search radius).

When clicking on the icon (1), the search will be performed based on the current user’s location (if the user gives permission to use it – https://tppr.me/Jf7YU).

When entering a text address, a drop-down list will appear under the address entry field, showing the address options that the current Geocoding provider can find based on the entered text.

After clicking on one of the address options from the list, it will be set on the search field, and the geolocation icon will be replaced with the “clear the field” icon.

When a new address or search radius is selected, the filter will either work immediately or require a click on the “Apply” button, depending on the widget/block settings.

Widget/Block and Filter Settings

This filter type is being created the same way as the rest of JetSmartFilters: first, you create a new filter in the Dashboard and then display it using the corresponding widget/block.

The filter itself doesn’t have any settings, and even a query variable is not required there because it simply uses Geo Search.

Widget/Block Settings

Most of the settings are the same as for any other filter. Below, you can find a list of the unique settings and why you need them:

• Placeholder – a text for an address input placeholder;
• Text for user geolocation control – this text will be used for a tooltip that appears when clicking on the address field. It’s important for users to understand that they are using a search based on their current location (note that in this case, a Geocoding API fetches only the geo-coordinates, not the text address of the user, because it requires an additional request);
• Distance Units – distance units listed with distance (search radius) options – kilometers or miles;
• Distance List – the list of distance (search radius) options.

Other Specificities of Location & Distance Widget/Block

In the initial version, there is an option to select the type of widget triggered – by clicking on a button or by changing a value. Unlike most others, this widget does not have an option to display its own button; it can only use a third-party one (another widget/block). This is due to the fact that the button doesn’t actually fit into the given layout and its further styling settings. This widget/block doesn’t support the Indexer functionality because it doesn’t have visual options to index.

New Timber/Twig View Type for Listing Items

General Terms

This is a new view type for JetEngine Listings, along with the existing Elementor, Block Editor, and Bricks views. It works based on the Timber plugin https://wordpress.org/plugins/timber-library/; that’s why it becomes available only after this plugin is installed. For its part, Timber is a plugin for integrating Twig, the popular template engine, into WordPress.

A template engine is a library that provides a simplified syntax for writing PHP templates to make them as close as possible to pure HTML. This means that our new listing view type allows you to create listing templates using the Twig template engine (with the Timber plugin for integrating Twig into WordPress).

Before working with this new view type, it's important to understand the difference between Twig and Timber. Twig is a template engine that doesn’t have any connection with WordPress whatsoever and demonstrates the general logic of simplified work with PHP. Timber is a WordPress plugin that integrates Twig in WordPress and adds some tools for working with essential WordPress entities, such as posts, users, terms, metadata, etc. We use Timber as a basis, and that's why you can use the same tools as for any other WordPress templates based on Timber or Twig.

This view type has significant benefits because the templates made with Timber/Twig have the best possible performance due to the fact that they use pure HTML with some dynamic data only when needed.

The second advantage is that you are restricted only by the limits of HTML and CSS – there are no limitations from the visual builder or block editor side.

Finally, the third advantage is that you get the purest HTML possible without any nestings and clogging code. To be precise, it fully depends on how you write the code.

The downside of the Timber/Twig view is that you need to have some knowledge of HTML and CSS to create such templates.

How Does It Work?

It works using the same logic as any other view type integrated with JetEngine:

• First, install a Timber plugin;
• After that, the new “Timber/Twig” option will be added to JetEngine > Listings;
• If you choose this type when creating a new listing item, the Timber editor interface will open.

As of now, the editor fields are initially empty, and in the future, we will probably add some default content there, depending on the listing settings. For a quick start, you can use one of the ready presets – https://tppr.me/QIMKm. The presets have been created based on Post content, so they might show incorrect results if you use other content sources in a listing.

The editor has three main sections:

• HTML editor;
• CSS editor;
• The Preview area.

To avoid incorrect render results and not to overload your server, the Preview area doesn’t get refreshed automatically after each new line of HTML code. So, to see the results, you should press the “Reload” button in the Preview area – https://tppr.me/NEKqs.

However, CSS code takes effect immediately if the corresponding HTML code has already been rendered in the Preview section.

You can set the width of the Preview area by using controls on the right side of the editor, just above the Preview section – https://tppr.me/tEfcD.

The HTML editor supports any language structures of Twig, and if the developer is very knowledgeable about Twig, they can write the code the way they are used to. Other than that, we have integrated some native JetEngine components, as well as some from Timber and Twig, and added the UI for using them. Let’s have a closer look at them.

Dynamic data

https://tppr.me/i1JQk

It’s a simplified version of dynamic widgets that other listing views have. The reason why it’s simplified is not because of the editor’s restrictions but because since you write HTML manually, you only need dynamic data itself, without any additional HTML wrappers.

For example, when you output an image, you don’t need an entire tag but the URL of the image only, while you add all the necessary tags and attributes manually.

As of now, there’s just one exception to this logic, which is the Data Store Button, where the full markup is being rendered because you not only need to output certain HTML with data but also to check the status of this item, change the HTML markup after the button is triggered, and so on.

The UI offers two sets of functionality for Dynamic Data: “JetEngine” and “Default Data.” The “JetEngine” one represents the dynamic data specific to JetEngine. At the moment, there are Dynamic Data (similar to Dynamic Field in other views), Dynamic URL (a mix of Dynamic Image and Dynamic Link), and Data Store Button.

The “Default Data” set represents data specific to Timber.

“JetEngine” and “Default Data” differ in their operation logic and, accordingly, in their appearance in the editor. The “JetEngine” data would be something like this:

{{ jet_engine_data(args={key:'post_date'}) }}

This entry looks like a PHP function, and it is actually a function but wrapped in the Twig syntax.

The “Default Data” would be something like this: {{ post.author.name }}, which looks like accessing nested elements of a certain object in JavaScript. In fact, this is true because Post and User are objects available in this context, so you can access elements within these objects. These objects would not always be available, but only if it’s possible to set them. For example, the Post object will be available if the current listing object is a WordPress post (page, CPT). The User object will be available only if the current listing object is user or if the user is logged in (then the User object will contain the current user). In addition, there’s a jet-engine/twig-views/current-context hook, using which any object can be added to the context to get access to it afterward. For example:

add_filter( 'jet-engine/twig-views/current-context', function( $context ) {
    $context['myobject'] = $my_object;
    return $context;
} );

And the syntax to access this object in the editor would be {{ myobject.property }}.

Filter data

https://tppr.me/D4J2d

Filters allow you to change any dynamic data. According to their operation logic, they are very similar to callback functions for Dynamic Field. Actually, these callbacks migrated to filters, and there are a few native filters available in the UI. The main advantage of Twig is that you can combine any number of filters on one element by separating them with the “|” symbol, for example:

{{ post.date|jet_engine_callback(args={cb:'jet_engine_date'})|time_ago() }}

Conditional tags

https://tppr.me/YT7Ym

The “Conditional Tags” button appears in the UI only if the Dynamic Visibility module is activated and allows you to use the conditions that this module adds inside the Twig editor. But in general, conditional logic is available in Twig out of the box using such lines:

{% if statement_to_check %}
<!-- Paste your HTML here -->
{% endif %} }}

For more details, check the official documentation – https://twig.symfony.com/doc/2.x/tags/if.html.

Useful Links

• Timber Documentation: https://timber.github.io/docs/
• Twig Documentation: https://twig.symfony.com/doc/2.x/

The new UI/UX for setting options for Select, Radio, and Checkbox meta field types

We have completely redesigned the approach to the options for Select, Radio, and Checkbox meta field types. From now on, there will be a dedicated control to select a source for options, just like we have in Crocoblock filters and forms: https://tppr.me/8CcWq.

As of now, such sources are available:

• Manual Input – a default source, options can be added with a repeater logic, just like before.
• Bulk Manual Input – a fast way to add options using one text field where each option can be added on the new line.
• Glossary – options are fetched from Glossary. Before, there was a “Get Options from Glossary” toggle. If you had it activated in previous JetEngine versions, after the update to the JetEngine 3.3.0 version, this toggle will disappear, but the “Glossary” option will be selected in the Options Source control. The meta field itself will not be affected.
• Query – options will be fetched from the query results.

If you use the “Query” option, you should specify the fields for fetching the value and the label: https://tppr.me/qLIui. For the example depicted in the screenshot, there’s a post query, the option value is taken from the post ID, and the label is fetched from the post Title.

JetEngine Calendar module. The new “Advanced Date” meta field type + recurring events in the Calendar

To implement the recurring events for the Calendar, we have added a new meta field type – Advanced Date.

This field type allows us to organize the UI settings for recurrent event dates and the way they are stored in the database. Hence, such dates can be displayed in the Calendar. Because this field type can only be used in conjunction with Calendar, it appears only when the Calendar module is on.

Another limitation that it has as of now is that it’s available only for posts. In the future, we will consider which other objects to add it for.

Field Interface

To add a new Advanced Date field, just select this field type when creating a meta field: https://tppr.me/sp2zz.

After that, you will be able to see such an interface when creating a post: https://tppr.me/AZ2ab.

The date picker looks the same as for the standard Date field: https://tppr.me/Jo2g2. After selecting the initial date, you can specify the end date, if needed: https://tppr.me/Xvhpp, and add the settings for repeating: https://tppr.me/m6pEq.

Recurring dates are calculated based on the start date; if there is an end date, all recurring dates will have their own end date added after the same number of days as for the initial date.

Due to the fact that we use standard WordPress data processing methods, the recurring event must be limited, either by the number of repetitions or it should have an end date. The reason for this is that when the settings are updated, all the recurring dates are created in the database according to these settings. So, it’s a mandatory condition, and without it, there’s no way to fetch event posts from the database and display them on the corresponding dates on the Calendar. Therefore, an infinite number of dates for the future events cannot be created.

Using it in the Calendar

Nothing has been changed in the Calendar widget. If you want to display recurring events with dates set up using the Advanced Date field, just set a corresponding field name in the widget setting tab: https://tppr.me/bVNdY. If the event has a due date, you should activate the “Allow multi-day events” toggle, just like before, but you don’t have to specify the end date field. It will be fetched automatically based on the initial field: https://tppr.me/WrgZa.

Ability to disable query caching functionality for Query Builder

We have added an option to disable query caching in the Query Builder. In most cases, there’s no need to disable it. It can be useful in the rare cases when you need to get a random post order, etc.

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

[Daveden2]

For the twig/timber listing, would it be possible to give users the option to change the HTML tag for the listing wrapper from:

<div class="jet-listing-grid__items">
<div class="jet-listing-grid__item"></div>
<div class="jet-listing-grid__item"></div>
</div>

To a <ul> <li> structure or <ol> <li> structure depending on user preferences, similar to Bricks.

<ul class="jet-listing-grid__items">
<li class="jet-listing-grid__item"></li>
<li class="jet-listing-grid__items"></li>
</ul>

[Lonsdale201]

Very super update with lots of useful new features very many thanks for it. Regarding Twig, I'd like to ask if the latest element of the query you've chosen is currently loaded in preview. In the future will there be a way to select the preview source (not the scope, just the related entry?

One more small related question regarding this. Will the full listing click functionality available in normal e.g. Elementor be back here too, or do we have to implement it in code ? (Make Listing item Clickable) I mean this :)

[Daveden2]

I also noticed that when you inject a listing template into a listing grid in Elementor using the Twig Listing View

The CSS from the alternate loop template doesn't get loaded on the frontend

[cwinkler8]

@MjHead I'm attempting to use the Calendar recurrence, but it appears that the Advanced Date does not allow a time to be specified. Is there a way to set it as a timestamp? Without that ability the feature will be severely limited.

[machachen]

In 3.2.0 beta release there was a promise saying compatibility between Elementor Loop & Query Builder would be introduced in the 3.2.x. Is that still the case? or it would be move instead to 3.3

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

Thanks!

[oceandiveloper]

@MjHead I am currently testing the Location and Distance filter type using a website I am currently migrating to Bricks. The map listing works, the Geo Search filter and a GeoSearch Query are set up.

Unfortunately I only receive console errors:

[oceandiveloper]

@MjHead another problem I noticed is that custom text for geolocation control is not applied properly in the location & distance widget.

The desired text is displayed as tooltip, but the location input value is still set to "Your current location" instead of my own value "Dein aktueller Standort":

And a really minor thing is the label of the widget in the navigator:

[oceandiveloper]

I would also have a request for the location & distance widget: please allow us to use any unit for the gap between location and distance input. Right now it's limited to % without any good reason. I would personally never use percentages for these inputs. The default is set to 10px anyway for .jsf-location-distance.

[MjHead]

@Lonsdale201 Thanks for the feedback. As for Make clickable functionality - at the moment you can do this only by wrapping whole item into tag with appropriate link. But later we'll implement Elementor-like ligic.

As for you first question - could you please describe this case a bit more detailed, not sure I understand it correctly.

@Daveden2 Thanks for the feedback, we'll take a look into this. As for ul>li structure I'll make a bit research o this and get back later

[Lonsdale201]

@Lonsdale201 Thanks for the feedback. As for Make clickable functionality - at the moment you can do this only by wrapping whole item into tag with appropriate link. But later we'll implement Elementor-like ligic.

As for you first question - could you please describe this case a bit more detailed, not sure I understand it correctly.

Thank you for your reply. :)

I tried to describe it a bit complicated, but I mean the preview content switch. Like Elementor here:

Will such an option be available later? It's really just an interest, it might be useful in some cases, to see some differences, so that we'll be working in html.

Which reminds me, what about the jetpoup ajax data display?

Jetpoup can be given a selector-based trigger, so that's not the problem, but the fact that in the case of jetpoup, the combination with listing gird requires the inclusion of a switch, which obviously is not possible here. Will there be, or is there some way to use the ajax functionality of jetpoup here via Twig? For example when we would do a quick view function.

---

Something else I noticed. If you use the gallery viewers from the JetEngine built-in internal module (Slider gallery for Dynamic field), the preview doesn't load anything. Of course, on the frontend everything is displayed nicely. Obviously a preview doesn't need slider functionality, but won't there be some workaround in between? For example, just displaying the first image of the gallery without any other loading functionality?

---

Anyway, brilliant. How easy is it now to add a facebook share to a twig based listing? That's how easy... I love it :)

<a href="https://www.facebook.com/sharer/sharer.php?u={{post.link }}" target="_blank" class="facebook-share">Share on facebook</a>

[MjHead]

@cwinkler8 At the moment you can set the time if needed with separate field:

• https://tppr.me/3HD6F
• https://tppr.me/gH18N
• to make sure your results are sorted correctly, you can sort the initial query by this field - https://tppr.me/1KWsu

[Lonsdale201]

@MjHead Dear Andrew, when using the Dynamic data option in the Twig listing, the preview wont show anything. If using a basic method like : post.meta('ar') preview showing. If using filter:

{{ post.meta('ar')|jet_engine_callback(args={cb:'number_format',num_thousands_sep:'',num_decimals:'0'}) }} (number meta type) showing but not the filtered version.

If using the Dynamic data option: {{ jet_engine_data(args={source:'meta',meta_key:'ar'}) }} the preview wont show anything. Is this how it works on purpose? (number meta type)

Am I using it wrong, or will the specific jetengine methods not be available in the preview, only on the frontend?

[cwinkler8]

@cwinkler8 At the moment you can set the time if needed with separate field:

• https://tppr.me/3HD6F

• https://tppr.me/gH18N

• to make sure your results are sorted correctly, you can sort the initial query by this field - https://tppr.me/1KWsu

@MjHead I can make that work, but it's a bit cumbersome. Most APIs require RFC3339 format, so I'll have to combine the fields and then format accordingly. Also, to make an event listing page I'll have to query by both the date and time fields.

Are there plans to make "Advanced Date" include a datetime option?

[Joliamendi]

There is a very small problem that I hope can be solved in this version...

In the bricks builder, I added the data store widget on the portfolio single page. But by default, the data store widget is placed on the header. There seems to be a z-index problem. Please note that the header is in sticky mode.

[JuanCar29]

I can't select another month, January always comes out.

[cwinkler8]

Looks like there are some display overflow issues with the recurring date option.

[cwinkler8]

@MjHead "Advanced Dates" are not appearing in Bricks Builder dynamic data options. As you can see, my 'date' field is not show in the list. If I manually enter the dynamic value in the "Group by" field I'm not getting anything to show in my calendar, but if I group by the "post date" I only see the first event and not the recurring events.

[MjHead]

Hi all, yesterday we released beta2 with fixes for most of the mentioned issues, the others are in progress, hope next week we'll be ready for Release Candidate

[machachen]

@MjHead Hi Mj, could you give us timeline on the integration of Query Builder and Elementor Loop? Thank you!

[oceandiveloper]

Hi all, yesterday we released beta2 with fixes for most of the mentioned issues, the others are in progress, hope next week we'll be ready for Release Candidate

@MjHead the plugin file for "JetEngine 3.3.0-beta2" I just downloaded still says "3.3.0-beta1". Are you sure the beta2 is downloadable already?

What about the issues with the distance filter I reported last week? It doesn't seem to be resolved yet (I still only receive console errors)

[MjHead]

@oceandiveloper I'll check the version, maybe cache. As for console errors - it's still in progress. I write "most of issues", sorry not to mentioned all the list, but it was not some official changelog, just follow-up to show that we working on your feedback, not just watching :)

[MjHead]

@cwinkler8 Can't reproduce your last issue, works fine for me with meta field name entered manually

As for date field in the Dynamic Tokens list - we'll take a look, but this part added on the Bricks side, not sure if we could resolve it on our side. And anyway you can't use it here - dynamic data will return field value on the front, but you need field name, to group posts by this field in the calendar

[ImKareem]

Hello! "Location and Distance" Can "map circle" like this added to the map?

Also, We need Docs for it.

[cwinkler8]

@cwinkler8 Can't reproduce your last issue, works fine for me with meta field name entered manually

@MjHead is there some special syntax required to reference the Advanced Date? Manually entering the field name {je_events_event-date} does not work for me in Bricks. Also, what string should I reference to output the end date?

[MjHead]

@cwinkler8 As I said before {je_ ...} tokens added on the Bricks side, we'll take a look what we can do with. Dates are stored under raw field name. But it's stored in a bit specific way - all dates are stored under the same field name. Later we'll add instructions and/or more advanced tools how to work with such field types

[MjHead]

@oceandiveloper We just uploaded beta3 to account.crocoblock with other it includes also fixes for your issues

[oceandiveloper]

@oceandiveloper We just uploaded beta3 to account.crocoblock with other it includes also fixes for your issues

@MjHead thanks for the info. I can confirm that the console errors are gone. But it's still not working for me. When I type in the input field there is no dropdown with suggested locations. And when I use a VPN in Frankfurt Germany and search within 500km of my current location, then nothing is displayed in the map.

I might have some missing configuration. Do you wanna have credentials to my test site?

[naturalwebcl]

Hi @MjHead i'm testing the Beta 3 and i get an error trying to create a form (Jetformbuilder) with included option in the CCT to do that.

PHP 8.2.11 NGNIX Theme Astra Pro All plugins updated

Ps. With JetEngine 3.2.6 and with the same configuration this error don't occur...

2023/10/31 21:56:38 [error] 15484#15484: *36178 FastCGI sent in stderr: "PHP message: PHP Warning: Attempt to read property "fields" on bool in /www/XXXXXX/public/wp-content/plugins/jet-engine/includes/modules/custom-content-types/inc/forms/create-jfb-form.php on line 44; PHP message: PHP Warning: foreach() argument must be of type array|object, null given in /www/XXXXXX/public/wp-content/plugins/jet-engine/includes/modules/custom-content-types/inc/forms/converting-jfb-fields/convert-manager.php on line 60; PHP message: PHP Fatal error: Uncaught Error: Call to a member function get_arg() on bool in /www/XXXXXX/public/wp-content/plugins/jet-engine/includes/modules/custom-content-types/inc/forms/create-jfb-form.php:55 Stack trace:

0 /www/XXXXXX/public/wp-includes/class-wp-hook.php(310): Jet_Engine\Modules\Custom_Content_Types\Forms\Create_Jfb_Form->create_form('')

1 /www/XXXXXX/public/wp-includes/class-wp-hook.php(334): WP_Hook->apply_filters('', Array)

2 /www/XXXXXX/public/wp-includes/plugin.php(517): WP_Hook->do_action(Array)

3 /www/XXXXXX/public/wp-admin/admin.php(419): do_action('admin_action_je...')

4 {main}

thrown in /www/XXXXXX/public/wp-content/plugins/jet-engine/includes/modules/custom-content-types/inc/forms/create-jfb-form.php on line 55" while reading response header from upstream, client: 201.188.24.79, server: XXXXXX, request: "GET /wp-admin/admin.php?action=jet_form_builder_cct_create_form&_nonce=2863024d76&cct_id=28 HTTP/2.0", upstream: "fastcgi://unix:/var/run/php8.2-fpm-XXXXXX.sock:", host: "XXXXXX:20139", referrer: "https://XXXXXX/wp-admin/admin.php?page=jet-engine-cct&cct_action=edit&id=28"

[MjHead]

@oceandiveloper, yes, could you please send me an access details in FB to take a more detailed look

[MjHead]

@naturalwebcl Could you please also share a screenshot of your CCT setup?

UPD: Nevermind, the issue is reproduced on any CCT setup

[oceandiveloper]

@oceandiveloper, yes, could you please send me an access details in FB to take a more detailed look

@MjHead I messaged you on FB with details. Have a look at message requests because we are not friends anymore since my previous FB account was hacked and blocked

[PhasedReality]

Thank you for your great work to all the Crocoblock team. JetEngine continues to get better and better, however there is one small issue as below that I can't find a work-around.

@MjHead - I'm currently using the location search and it is working well and providing results based on location & distance as expected. However when I clear the current search location by clicking the x, the results do not reset back to the initial query state and instead reset to the home location + whatever is the currently selected distance in the drop-down. I've tried setting up a button to reset the filters and re-apply the query, but again it just resets the location, not the initial broad search distance (In my case 1,000km to cover the whole country)

[EDIT]

So I was able to achieve the reset with the following line of code added to the reset button script.

filterGroup.filters[2].locationData.distance = 1000;

Whilst this does work, it seems a bit hacky / akward as clicking the x in the location box still retains the distance from the drop-down. Would be great to have a full reset function to return to the original query state without any distance value applied when the user clears the location.

[cwinkler8]

Hi @MjHead, this may be related to the CCT issue reported above, but it appears the CCT tables are not being created in the DB.

[alexplex]

Great update! I'm in the process of building a Listing Grid with the new Advanced Date feature. Since the Advanced Date field only works with the Calendar out of the box, I built a SQL query. This works fine with the repeating dates but I can't quite figure out how to also add start times and end times. I have two meta fields for those but I'm not quite sure how I can add them into listing. Any suggestions?

This would not be an issue if the Advanced Date field also included a time selection and the date/time would be saved as a timestamp in the database. Perhaps this is something that could be added in the future?

Anyway, this is a really great update that I have waited a long time for. Keep up the good work!

[MjHead]

@alexplex Yes, you're not the first who asks about time. So we'll add this to roadmap to next major update

[MjHead]

@cwinkler8 Just tested it - works fine. Could you please check with 3.2.7 version - does it works there?