I just ran into an issue with the Kadence Advance Image Block. I used it in a custom post template, and it does not pick up the data of the selected preview post. That causes the block not to display all configuration options, so it can't be configured.
When I contacted Kadence about this, they responded with "Toolset support is very low on our list. If you want to use it I suggest using their own blocks which are built for their system."
That is a surprise and a worry. It looks like Toolset supports Kadence, but Kadence is not involved. A one way commitment. It feels risky to combine the products.
I would characterise the integrations with other block products as basic integrations, not complete integrations.
We have been down the integration route with page builders in the past, where an initial period of cooperation with more and more page builders then led to a situation where we were having to devote a bigger and bigger share of our development resources just to stand still, to fix things that broke as the page builders developed their products. That was unsustainable and part of the justification for switching our emphasis to support the block editor.
We don't want to find ourselves in the same situation with plugins that enhance the block editor; we aim to have basic interoperability with the core features of some of the more popular products without having an open-ended obligation to provide development resources to essentially enhance their products. In the case of Kadence they helped facilitate the work to integrate dynamic sources with their blocks, but the work was done by ourselves.
For a scenario where a Kadence block lacks the context needed to work (because you are editing a template, not a post), I'm not sure if it would work, but you could try adding the block to a post, applying the settings as required, and making it a re-usable block which you then insert into the template.
Thanks a lot. Yes, I'm talking about themes and block plugins here, not about page builders.
Meanwhile I received a more extensive reply from Kadence and they confirm what you're saying:
"You can use their settings in Kadence Blocks and we did a lot to make that happen. We will continue to support it.
You can use toolset and also use Kadence Blocks. The point there is that Toolset adds settings into Kadence Blocks and toolset adds their own blocks. If you feel you need Toolset on your site to do something that's perfectly fine. Their complex system for templates and dynamic sources will work with their settings which they add to Kadence Blocks and their own blocks.
Kadence also offers dynamic content. Our system is naturally different from theirs and our system doesn't connect or communicate with theirs. We will never support their complex templating sources in our dynamic content solutions because we don't intend to build some kind of communicator with their system. They built their system before WordPress Core had it's contextual api system in place and so they naturally have a different ways of doing things.
What we will eventually support is their metabox generators. Their tools that are similar to ACF for example. But that is totally different then building a system of dynamic content that works inside their custom dynamic content system.
In short if you are templating with Toolset then I strongly suggest using Toolset blocks and Toolset settings (that are added to Kadence) and not the Kadence built dynamic content settings."
My conclusion is that within Toolset templates, only supported blocks should be used when it comes to dynamic data: https://toolset.com/documentation/dynamic-sources-in-popular-blocks/. The Kadence Advance Image Block that made me aware of all of this is not supported (yet?) by Toolset.
Since templates are widely used, this limitation applies to the majority of the pages of the website I am creating.
I'm not familiar with the "contextual api system" that Kadence mentioned. Is that something Toolset is migrating to, and will that resolve the issue?
All of this is fairly complex for a non-coder 🙂 I'm trying to make good decisions and avoid creating something that will present itself as "not supported" down the line.
I don't envisage any changes to the implementation of Toolset dynamic sources.
What may happen is that it is obsoleted by a core WordPress dynamic sources implementation. (Currently there are various implementations from various providers, all bespoke regardless of the underlying APIs used, I think it is fair to say Toolset was the first.)
As WordPress fleshes out Full Site Editing, it will at some point likely need to come up with a dynamic sources implementation, and if and when it does that would be the time to review our own system and possibly migrate to it. In the meantime the sundry vendors will have their own implementations.
When we first integrated with Kadence blocks we added dynamic source support for all of the appropriate blocks available at the time. As Kadence—and others—add new blocks we won't drop everything to add support on a piecemeal basis, but it is possible that we will have periodic reviews where we assess what has been added and add additional support in one sweep. I'm not aware of any current plans for that, but it is something that may happen.
In the meantime where you find individual blocks that don't have such support, you will need to use the Toolset version if available.
