Hi @jamminjames
It seems we have, unintentionally, create some confusion here, mostly due to wording used.
Let me sort that out a bit:
1. the article is referring to “add-ons” but it only means a “custom code or plugin that extends Forminator or interacts with it”.
It doesn’t mean an add-on that is actually “registered” with the plugin and used “inside” it (as “add-on” barebone example that you can find inside plugin files – that’s internal)
2. The API can actually be used in your plugins – what Kasia meant is that it’s not created as tool to create add-ons entirely; it’s just a set of API functions that can be used in our own plugins or custom code; it’s mostly used in codes that are created for custom integrations but it’s not restricted to that.
However, there are no functions to register an add-on in that meaning that it becomes “integratl part of Forminator”. We don’t have such features/functions and we don’t use that kind of add-ons (except ones created by us/internally).
You are free to create your own plugins that work using Forminator API or data and interact with it (using Forminator API and/or filter/action hooks available) but those need to be separate plugins.
3. What you can do, however, is
– to check if Forminator is active in your own plugin (see: is_plugin_active()), to avoid your plugin execution if Forminator is not there
– and you can place your plugin menu as a submenu under “Forminator” menu – that doesn’t require Forminator API, it’s only a matter of how you add your menu (see: add_submenu_page())
Kind regards,
Adam
