This is very frustrating because I know how to do both of these things with toolset but I can't because I need the legacy editor for one and the Block layout for the other.
I want to have a view list my posts in a CSS grid Masonary layout as per the Block editor allows me to do. But for my filters I need to add the category slug as a class on the radio button so I can style it without nth-of-types which I can do in the classic editor 🙁
So how can I pull off both of these things using either the legacy or the block editor? It's really going to become frustrating as more features are added to the block editor but that flexibility level only stays with the classic.
I kind of have a work around for my use case. However this is more part of a larger concern. I personally love the flexibility of the legacy editor. But I'd love to see the new layouts be ported over so I'm not forced to use the blocks editor because it's simply not as flexible for what can be done yet. It's also a lot slower on live servers especially for woocommerce.
Our legacy editor is much powerful and feature-rich than our offer for the blocks editor. You can also create grid-based views in the legacy editor, but that needs Bootstrap styles. Either by adding them through Toolset or within the theme and telling Toolset what version is used in Toolset->Settings->General(tab), so it can generate the correct CSS classes.
Please let me know if you still need assistance with this or something related.
Thank you Jamal, I understand all of this my concern is just in regards to the lack of the CSS Grid masonry layout in the legacy editor, as this is a more complex layout to manually add when using the Ajax query. I don't see why this layout couldn't be added to the legacy editor.
This is just the first thing that has not been easily reproducible. I'm worried that as you start to add more and more features to the block editor, that they will not be available in the legacy editor, however the legacy editor will still be more powerful and you are now forcing people to choose between the legacy editor or the block editor, and it will not be as simple as is this a simple view(blocks) or do I need a more complex query(legacy) . It is now becoming do I need feature set 1 or feature set 2, and sometimes you will find yourself having to pick even though you need a combination of both.
You can go ahead and close the ticket, just wanted to note my concerns on this matter, Thanks Jamal.
Thank you for your feedback. I understand your concerns. I just want to add, that even if we are pushing toward the new Blocks editor, we are still supporting the legacy Toolset Views. We will fix bugs on it, but we might not add more features. But all the features that you already use with Toolset Views will still be there and will still be supported.
You can keep using the legacy editor without any concerns about its future. We won't retire it any time soon, and we will keep all our users updated about our future decisions ahead of time.
Both views and blocks can work along, especially for features that are not yet available on the blocks editor. The Fields&Text block is, somehow, similar to a content template. You can use all the views shortcodes inside of it the same way you use them in the legacy editor.
We also working on integration with popular blocks plugins so you can use their blocks too, and pull the data from the database using Toolset. We'll see how that will go.
So, regarding the masonry layout on views, you can still generate an unformatted view, control its HTML markup, and use a 3rd party Javascript library to build a masonry layout. That's how much the legacy views are powerful, I know 🙂
Anyway, I'll set this ticket as resolved. Feel free to open a new ticket for any questions.
Hi Jamal, so I did decide to go with a 3rd party masonry layout, and I assume you were referring to hidden link as it is kind of the go to in this space, so I'm wondering if you guys have run into this before as you never used to have the css grid layout option in the past. It works perfectly, the only problem is that because the JS events for pagination in toolset only has "after pagination is complete" thats the only time I can run this event if using an Ajax pagination, which means I will get a Flash of the posts loaded in one column down the page before they get reshuffled by the Masonry script. I was going to try adding an event to the pagination button click to make the wrapper opacity 0 and then fade it back in after on your pagination completed trigger, but thought it was worth an ask to see if you guys have run into this and had a solution already.
Awesome!!! I am glad you could make it work. And thank you for sharing these details.
If you don't need further assistance with this request, I'll have to kindly ask you to mark this ticket as resolved. Feel free to open a new ticket for any other request, question, or issue.
This ticket is now closed. If you're a WPML client and need related help, please open a new support ticket.
