Closed MjHead closed 1 year ago
Thanks this option too :P
Btw so at the moment, Custom control for connecting query to any widget containing a repeater Can't try it yet? :) I'm just asking because I've thrown in some native Elementor widgets (e.g. tab, or toggle), but I don't see the option.
@Lonsdale201 It requires 2-way comaptibility, so at the moment we added it only for widgets from our plugins (JetElements and JetTabs) We'll release these plugins with apporopriate updates in a few days, than I'll add a comment here a full list of supported widgets
Great job and thank you I have some questions or suggestions 1- As long as bricks builder has its own native loop builder and also css grid will be released soon, I think no one will use the listing grid widget of JE! 2- maybe its better to make jetsmartfilters adaptable with brick's loop builder, so its a good way to not waste the time on listing grid
I agree with @mehdimoradi1500 hardly anyone gonna use Listing Grid, once someone understands how Bricks Loop Builder works - it's sooo efficient.
What I wish would work, would be macros along with regular loop builder. There was a custom integration available for JE Query Builder, while it worked at the Posts and Taxonomies level, macros didn't.
But I got a custom code for %queried_item% macro so I solved my issue
Hi guys, thank you for ur hard works. I have gathered some of the ideas about JetEngine and other CB plugins, hope it helps the progress of developing:
1- With Elementor, their Dynamic Field widget create a massive 5 DOM elements. It shouldn't be more than 2. So if you have a listing with with 60 elements (for example Pricing for services in a beauty salon or restaurant menu) and you need 3 dynamic fields in each. That's 60 elements x 3 dynamic fields x 3 uncesseary DOM elements per item = 540 of useless DOM elements.
2- One of the reasons for me to give a try to Bricks (I bought Ltd) were Performance issues with Elementor & JetEngine if the pages couldn't be cached.
3- Unfortunately, Crocoblock staff is very arrogant, not really helpful, but the most important - they hardly listen to the users. I recommended them to implement voting tool like Bricks, Breakdance and many other SaaS companies. They spend a lot of time on useless tools, create products, which can't really be used in 95% business cases ( like JetAppointment or JetBooking).
4- Two years ago I had high hopes, got myself LTd like 15 months ago... but evert single quarter I've started using fewer and fewer of their plugins, because we reported bugs and suggestions to improve the performance for free! But it takes 8-12 months to just fix one simple bug
5- There are so many basic things they could implement:
6- So many users asked for Custom database table for metabox/CPT features of JE for better performance for almost a quite long time! but no one listen
7- they have a tutorial on creating events calendar and some things related to events. They even allow connecting JetForms to CPTs so you can register for events. What's more - there is an addon to connect forms with WooCommerce, so you can even take payments. However, pretty much every single event has a capacity, whether it's 10 or 10,000 - there are always some limits. So all they would have to do is to create another type of meta-field "capacity", which could be connected to forms to so you could set a max capacity. But such field could have a much wider use case - if you sell a few physical products, like 3-4 different products, not necessary I would like to have all the bloat coming from WooCommerce. So again, you could assign a stock.
Those two things don't seem to be complicated to be done. They have custom requests option now, will see if they can make it if I pay for it.
8- It had a great potential, they have significantly raised prices (like 3 x in the least 2 years), and I don't see much progress. Instead of making their products better, they started creating more and more, I think they simply lost focus and I had already happened before the current circumstances in Ukraine, so you can't really connect those two events.
9- Don't start complaining about performance issues with bricks after using jet plug-ins. They don't have good optimizations.
In jet theme core 2.0.5 if you have woo shop with many products, everywhere in the backend or front, in every page was doing a select of all products attributes etc and was slowing the whole site down. They fixed it in 2.0.7. Don't tell me the have good code. That was one example. Clearly you haven't took a good look.
There is no way to set pagination. The Bricks pagination element does not work with the listing, not even with the "Use as archive template" option when in an archive template.
Any way to paginate the listing grid?
We just released JetElements and JetTabs plugins. Now its compatible with JetEngine 3.1.0 Query conteol. Full list of compatible widgets:
JetElements
JetTabs
How To Test it
Will JetTabs albo have JetEngine Query support? When enabled, Tabs = Custom Taxonomies or Woo categories, Content to be loaded based on template. An ability to enable slider to scroll taxonomies when too many tabs or on mobile
Is this something in your backlog?
@ConsultMePL
Will JetTabs albo have JetEngine Query support? When enabled, Tabs = Custom Taxonomies or Woo categories, Content to be loaded based on template. An ability to enable slider to scroll taxonomies when too many tabs or on mobile
Is this something in your backlog?
What you mean scroll? Are you about horizontal scroll the tabs?
or vertical depending on placement.
Yes, I have a custom css code to have a vertical scroll bar. On mobile scroll is touch enabled, so it's intuitive. For desktop, it's better to have a slider with arrows with onclick or hover options. JetEngine listings already support it, so the core fucntionality is there, just a matter of integrating this into JetTabs
Andrey - So if someone adds a taxonomy assigned to given CPT, adds some items, then this Taxonomy will autopopulate as next Tab? Because that's a core functionality missing in JetTabs, when you don't want to force your client to play in Elementor Editor when they add / edit taxonomies
I'll test it out tomorrow
@ConsultMePL If I understand you correctly - yes, after you connecting tabs to Query from Query Builder it starts to work in the same way like Listing Grid. If user will add some term and this term will match query conditions - approprite tab will automatically appear in the connected Tabs widget. In the same way you can use query for Accordion and all other widgets listed there - https://github.com/Crocoblock/suggestions/issues/6181#issuecomment-1322212958
@ConsultMePL If I understand you correctly - yes, after you connecting tabs to Query from Query Builder it starts to work in the same way like Listing Grid. If user will add some term and this term will match query conditions - approprite tab will automatically appear in the connected Tabs widget. In the same way you can use query for Accordion and all other widgets listed there - #6181 (comment)
I can't test it for now, as I hade to do a Repeater First. It's actually quite complicated to display reperater fields. Basically I wanted to do a Slider for a client, which they could edit. In order to do so, I had to create:
Very complicated, time consuming and a lot of bloat - this itself, a slider with 4 images and overlaping text results in almost 60 DOM elements. Are you guys planning to simplify it? This is Query control supposed to do?
Anyway - since I had to do it, I needed Repeaters to work. Unfortunately, they don't in JE 3.1 beta.
When I created a Repeater listing template, repeater fields were not loading. When I tried to save it anyway, I would get 503 error. When I left Elementor editor and wanted to go back, I'd get 503 error again.
@ConsultMePL
@Lonsdale201 It requires 2-way comaptibility, so at the moment we added it only for widgets from our plugins (JetElements and JetTabs) We'll release these plugins with apporopriate updates in a few days, than I'll add a comment here a full list of supported widgets
Thank you for your reply. :) Which is related here as a question. Now that the Query builder handles repeater I assume for compatible widgets the repeater query will be usable in the same way, so, by default we don't need the "Dynamic Data Addon" addon anymore?
I assume these elements will not be filtered by JSF?
Related question, sorry, just now that Query Builder has become compatible with Repeater, maybe sometime in the near future, is it expected that JSF will also be able to filter in Repeater? I know it's JSF issue, I just assume the Repeater Query builder comaptible may be a developer milestone, and I assume Query Builder helps with a lot of solutions that would have been difficult to implement for native versions (e.g. chart, table).
@ConsultMePL
- Query, meta fields, CPT etc are required to simplify processing dynamic data. When you have for example 100 posts with gallery filled by repeater field in each of them. If you just need 4 images slider - just add slider widget into the page content and add 4 images into this slider.
- If you want client edit these images not from the Elementor editor, but from some simplified UI - use Options pages. With Options pages you can create 1 page in the admin area and add repeater field for your gallery into this page, without any additional CPT. Than create Repeater query based on this repeter field and then use this query for Slider widget from JetElements (like I descibed in the example for Price list here - JetEngine v3.1.0 Beta #6181 (comment)) The only note here - you need to use Array value format for the image control inside repeater field, to make it compatible with Elementor Dynamic Tags - https://i.imgur.com/IxMFIlh.png
- If you'll use Slider widget from JetElements, connecting it to Repeater Query will not add any extra DOM elements, it will be the same as using it with static images. Its one of the most reasons of adding this feature (I mean ability to connect Query to some static widgets from JetElements/JetTabs)
- It's beta version, so bugs may appear. We'll try to recreate your problem with 503 error based on your notes, but if you can provide step by step screens of your set up it will help us a lot
- If I corretly understand - you created Repeater query based on some CPT. In this case at the moment - yes there is a problems with preview and this problems are related to dynamic part of this query. It requires a post where selected repeater field already filled in (I mean repeater field you select in the query settings when set up it) In preview context global post object - is a listing grid item post itself, so query tries to get the data from this post and it can't because there is no appropriate repeater meta field exists. We have an idea how to solve this problem, in a few days we'll release beta2 with appropriate fix.
Since Ive started playing more with Options Pages and Repeaters. I started seeing some possibilities to improve performance - I assume Repeaters are within one db entry and can load much faster than CPTs and taxonomies?
I came across two major issues:
Dynamic Tags and Reperaters (I guess the same issue is with Bricks, which I'm exploring now) - repeaters are not available. You gave one example that a media could be set as array and work. But how about other elements? Very often, I don't need a dynamic field widget - I prefer using Heading and text editor (fewer DOM elements). For now, it seems not to be compatible with repeater fields. Is there any workaround? Is it on the roadmap, if yes - then is it rather a matter of 1-2 months or 6 ?
Nested repeaters / repeaters within repeaters. In many cases like Option Pages, you could make it way easier for a client, if they can edit their menu or gallery within one place. With CPTs and Custom taxonomies - it's not intuitive, time consuming as every dish/pricing element is a separate post. On top of that, you can't manually sort them without 3rd party plugins (those plugins though, are not compatible with CCTs unfortunately). So it could be great if I could create a Tab Menu, then Repeater with a meta field - text, for dish category and another repeater with dish details/meta-fields like name, price, description. When trying to pick a meta-field under repeater there are two fields missing: repeater and html. Apparently (croco chat) ability to create nested repeaters is in your roadmap? whats the ETA?
I think this could significantly improve the experience. What's more - I really do hope that this will come with appropriate code improvements to Bricks. Their Query builder is out of the league (perhaps also because of Elementor structure and limitations). The fact that you can do query there within a page without multiple templates is absolutely amazing - on the one hand improves performance, on the other - development process.
@Lonsdale201
@Lonsdale201
- As for Dynamic Data Addon - yes, in fact you don't need it anymore, Repeater query replaces it
- Repeater query should be already filtered by JSF. It has some limitiations, for example pagination will not work at the moment, because paging navigtion not available for the Repeater query at the moment, but Query arguments already in, so you also can filter Repeater query items by some field values with JSF. It works in the same way like filtering by Meta Fields for Posts queries
Ohh, okay, Thank your to the answer. :)
@ConsultMePL
- Query, meta fields, CPT etc are required to simplify processing dynamic data. When you have for example 100 posts with gallery filled by repeater field in each of them. If you just need 4 images slider - just add slider widget into the page content and add 4 images into this slider.
- If you want client edit these images not from the Elementor editor, but from some simplified UI - use Options pages. With Options pages you can create 1 page in the admin area and add repeater field for your gallery into this page, without any additional CPT. Than create Repeater query based on this repeter field and then use this query for Slider widget from JetElements (like I descibed in the example for Price list here - JetEngine v3.1.0 Beta #6181 (comment)) The only note here - you need to use Array value format for the image control inside repeater field, to make it compatible with Elementor Dynamic Tags - https://i.imgur.com/IxMFIlh.png
- If you'll use Slider widget from JetElements, connecting it to Repeater Query will not add any extra DOM elements, it will be the same as using it with static images. Its one of the most reasons of adding this feature (I mean ability to connect Query to some static widgets from JetElements/JetTabs)
- It's beta version, so bugs may appear. We'll try to recreate your problem with 503 error based on your notes, but if you can provide step by step screens of your set up it will help us a lot
- If I corretly understand - you created Repeater query based on some CPT. In this case at the moment - yes there is a problems with preview and this problems are related to dynamic part of this query. It requires a post where selected repeater field already filled in (I mean repeater field you select in the query settings when set up it) In preview context global post object - is a listing grid item post itself, so query tries to get the data from this post and it can't because there is no appropriate repeater meta field exists. We have an idea how to solve this problem, in a few days we'll release beta2 with appropriate fix.
- I'd like to have custom view, but most importantly, I'd like a client to be able to edit it.
- Actually, Ive heard of Options Pages, but never really tried it. In fact it does solve some issues and makes client dashboard quite clean, though I'm still to check whether it would be possible to recreate in sort of profile builder - so create frontend dashboard outside of wp admin
- OK
- Problem is definitely there, I used clean WP installation with very few plugins. Just to check whether already created repeaters will work
- Ok, I guess you are on the right track - because when i created a template for CPT as well, it worked. But with your solution, one less template will have to be created
Since Ive started playing more with Options Pages and Repeaters. I started seeing some possibilities to improve performance - I assume Repeaters are within one db entry and can load much faster than CPTs and taxonomies?
I came across two major issues:
- Dynamic Tags and Reperaters (I guess the same issue is with Bricks, which I'm exploring now) - repeaters are not available. You gave one example that a media could be set as array and work. But how about other elements? Very often, I don't need a dynamic field widget - I prefer using Heading and text editor (fewer DOM elements). For now, it seems not to be compatible with repeater fields. Is there any workaround? Is it on the roadmap, if yes - then is it rather a matter of 1-2 months or 6 ?
- Nested repeaters / repeaters within repeaters. In many cases like Option Pages, you could make it way easier for a client, if they can edit their menu or gallery within one place. With CPTs and Custom taxonomies - it's not intuitive, time consuming as every dish/pricing element is a separate post. On top of that, you can't manually sort them without 3rd party plugins (those plugins though, are not compatible with CCTs unfortunately). So it could be great if I could create a Tab Menu, then Repeater with a meta field - text, for dish category and another repeater with dish details/meta-fields like name, price, description. When trying to pick a meta-field under repeater there are two fields missing: repeater and html. Apparently (croco chat) ability to create nested repeaters is in your roadmap? whats the ETA?
I think this could significantly improve the experience. What's more - I really do hope that this will come with appropriate code improvements to Bricks. Their Query builder is out of the league (perhaps also because of Elementor structure and limitations). The fact that you can do query there within a page without multiple templates is absolutely amazing - on the one hand improves performance, on the other - development process.
@MjHead any chance to get a reply? I posted this here, on FB group, Croco chat - you have guys released this beta which is not compatible with repeater.... always getting 503 error
@MjHead what's the point of creating a thread on Beta, if there no replies? It's not possible to use this beta along with repeaters....
@MjHead what's the point of creating a thread on Beta, if there no replies? It's not possible to use this beta along with repeaters....
We working on fixes for issues we already received in this thread
Hi Andrew, any news for beta 2? I need the Time Period of the Dynamic Visibility for my projects. but will not use it before Release candidate.
@kochhase
RC will be added into account tomorrow
Hoy es mañana ¿Donde lo podemos descargar? Gracias
@MjHead donde podemos ver información sobre los cambios de la RC o Beta2. Gracias
@kochhase
RC will be added into account tomorrow
It's there.
But what's been added? What's been changed?
Please add compatibility with Redis object caching and SQL queries in jetengine. Lots of servers run on redis and memcached. Right now custom SQL queries only show up on the front page when you flush redis.
Lightbox not working in Bricks
Dynamic Field -> Image gallery grid -> set lightbox toggle on
When testing, the image opens without controls. You need to go back with browser to see the other images and so on.
Moreover, the hover icon shows as an empty square, and adding this css code don't fix it either (it does on elementor websites).
.jet-engine-gallery-grid__item-wrap.is-lightbox:before { font-family: "Font Awesome 5 Free"; font-weight: 900; }
Meta boxes for Users in Bricks
When in editor or live, no data is shown. Either using the CB Dynamic Filed widget or a regular header widget. No matter if the meta filed is text, date, checkbox, select...
Lightbox not working in Bricks
Dynamic Field -> Image gallery grid -> set lightbox toggle on
When testing, the image opens without controls. You need to go back with browser to see the other images and so on.
Moreover, the hover icon shows as an empty square, and adding this css code don't fix it either (it does on elementor websites).
.jet-engine-gallery-grid__item-wrap.is-lightbox:before { font-family: "Font Awesome 5 Free"; font-weight: 900; }
the issue with empty squares has been there forever
Please add compatibility with Redis object caching and SQL queries in jetengine. Lots of servers run on redis and memcached. Right now custom SQL queries only show up on the front page when you flush redis.
they won't, they'll rather waste time on things like charts that hardly anyone is using lol
@MjHead Have you guys experienced that the Jetengine Query builder + JetFormbuilder query date sorting appears in descending order (I made a simple activity log for users), I have thrown in the listing on one side of the JE profile builder and the Query on is just set to Forms and to take the queried user id as a base. Looks like it's backwards ordering.
@Lonsdale201 Not sure I'm correctly understand you. Could you please send a screen with an example?
Is it possible to use a repeater query to dynamically generate multi-select options in JetForm Builder? It doesn't seem to be working but not exactly sure how to configure.
Is it possible to use a repeater query to dynamically generate multi-select options in JetForm Builder? It doesn't seem to be working but not exactly sure how to configure.
I was able to get this to work with a select field using these parameters query_id|prop_for_value|prop_for_label|prop_for_calculated. However, using the exact same parameters did not work for a radio button field.
@Lonsdale201 Not sure I'm correctly understand you. Could you please send a screen with an example? @MjHead
Yes of course.
So, I noticed that I have done a JetFormbuilder records query in Query Builder, and it looks like it returns the values in descending order. The image shows the dates. And it should be the other way round. At the moment the Query for some reason shows the oldest ones as a start and not the newest ones. The second picture is the setup. There is no order setup option. So I suppose the basic ordering of this would be that the newest form records are first (like in the posts, the newest is first), the preview shows it that way, but the output in the lisitng grid doesn't show it that way anymore.
So I am trying this new feature "Use JetEngine Query" for repeaters. I was excited about the performance benefits of this versus using a listing grid with dynamic widget - but I can't seem to get it to work with Repeater Fields?
I have a CPT with Repeater Field for Before and After photos for example.
I want to use Image Comparison widget to show these Repeater Images as Before and After Carousel.
However, I do not see how I can select these Repeater Fields as a Dynamic Tag?
I tried Current Object Field to select the same Repeater Query results, but also not working?
So how am I meant to take advantage of this new implementation for Dynamic Repeaters and Repeater Query type if I can't select repeaters? Seems kind of ironic doesn't it?
Hi,
We are almost getting ready to release JetEngine v3.1.0 and we would like to ask you to help us test JetEngine v3.1.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!
Bricks Builder сompatibility
Here is the thing: one of the main factors why users switch to Bricks and ask for Bricks compatibility is speed. Therefore, compatibility is being implemented from smallest to largest. For now, we have added the minimum required set of widgets and will add more upon request. It does not mean that Elementor is very slow because of our widgets. It means that if something is not in the code, then this code will be executed faster than that with something in it. Whatever the case, our widgets somehow affect the site’s performance, so if you can do without something, it’s better not to add it. We tried to follow the same approach when adding style options, having covered the required minimum for now, and would implement more upon request.
At the moment, the following JetEngine widgets are compatible with Bricks.
Core:
Modules:
We will add support for Tables and Charts and Filters a bit later.
The working logic of our elements in Bricks is the same as in Elementor. You create a listing grid item using the Bricks Builder (a corresponding option has been added) and use Dynamic Widgets to add content to the listing item. Then the listing based on this item is outputted using the Listing Grid widget.
In terms of functionality, everything is the same as in Elementor. However, styling options and some options’ UI/UX may differ because not all controls from Bricks match with Elementor.
So far, we haven’t added any custom options, possibly analogous to Dynamic Tags in the Bricks Builder. In Bricks, this functionality is implemented in a more primitive way compared to Elementor, so it will not be possible to replicate any of our Dynamic Tags for Elementor.
Custom control for connecting query to any widget containing a repeater
Ability to use the query from Query Builder as a content source instead of static data. This functionality works best for widgets where content is added with a repeater – Slider, Timeline, Testimonials, Tabs, etc.
Work logic:
Benefits for users compared to a standard listing:
This feature will be fully available after next JetElements update in a few days. I'll notify here when it will be released and attach full list of supported widgets
UPD We just released JetElements and JetTabs, so you can fully test this feature. Details in the comment below - https://github.com/Crocoblock/suggestions/issues/6181#issuecomment-1322212958
Repeater Query Type
We added a new Query type – Repeater. It allows you to get data from the Repeater meta fields and Repeater options in the format of JetEngine Query Builder. This means that listings and all our dynamic widgets and tags will work with this query. We also consider adding support for filters in the future. This is when you can spot one of the Query Builder’s advantages – a unified approach to obtaining data from the database. This means one can receive and then use completely different data types through the same UI. That’s why we root for everyone to switch to Query Builder.
Options (https://i.imgur.com/MOR9R7F.png):
New conditions for Dynamic Visibility
We added two new groups and five separate conditions for the Dynamic Visibility module. Briefly about each:
Listing-specific conditions perform the same function as the Listing Injections module but allow you to make changes within a single listing item without creating additional items. This is convenient and useful when you need to make small changes in the layout. In this way, there will be less setup work and more optimized performance.
Ability to choose the options storage type
Before JetEngine 3.1.0, the Options page data was stored in the database as one option (if you look at the default work logic for options in WordPress). The option name would be the Options page slug. The value would be an array with all options that the users added for this page – https://i.imgur.com/UeaLrBT.png, https://i.imgur.com/miyFaK7.png. If working with options through JetEngine only, the user won’t see the difference. For other options for working with data, this creates additional problems in getting these options’ values.
In version 3.1.0, we added the ability to select the Options storage type – https://i.imgur.com/lOecpsE.png. The Default (as array) type is what we have now. The Separate type means each page option will be stored as a separate option in the database – https://i.imgur.com/Qo6215l.png. Add prefix for separate options is an additional setting that allows you to add or remove the page slug from the option name. If activated, the page slug will be added at the beginning of the option field name – https://i.imgur.com/LWcQ9OD.png. We do it to avoid interfering with some core or third-party plugin options. If the option is disabled, the field name in the page settings will match the key under which this option is stored in the database.
Pros of storing options separately:
Quick search in Troubleshooting and Knowledge Base from the admin panel
We added a button to JetEngine pages in the admin panel, allowing users to call the documentation search form directly from the client’s website – https://i.imgur.com/QEr3DKD.png, https://i.imgur.com/oyMzmCc.png, https://i.imgur.com/94gyUFr.png.
In the future, similar functionality will appear on all Crocoblock-related admin pages.
Shortcode Generator update
Starting from v3.1.0, the shortcode generator will work the same way as the Dynamic Field widget – https://i.imgur.com/WOgjv7P.png. The only fundamental difference that makes the shortcode generator even more versatile is the ability to apply multiple callbacks on the same shortcode – https://i.imgur.com/z9wY2oB.png, whereas to the Dynamic Field widget, it is possible to apply only one callback.
What opportunities users get:
Macros Generator
A visual UI for generating a macro with the needed settings – https://i.imgur.com/A4GPLsD.png. A macro generated here can be further used everywhere where JetEngine macros are supported. So far, these are only separate options for our own widgets. In the future, we will add support for macros in more places.