Open f-elix opened 1 week ago
That's a good point and is unique to extensions. Unlike buttons or commands that have a separate item in the field config, extensions are a free-for-all.
That's going to mean that we need to register the extension with our plugin. So the format for registering the extension will need to change. Fortunately, this isn't a breaking change, and is backward-compatible. You'll just continue to have your extension globally enabled.
Change your code to:
Craft.Vizy.Config.registerExtensions((extensions, vizyInput) => {
return [{ plugin: 'force-hard-break', extension: HardBreak }];
});
Notice the inclusion of the plugin the extension belongs to. I've also added vizyInput
in this callback to allow you access to the instance we're registering things on, for all sorts of handling.
Updated for the next release. To get this early, run composer require verbb/vizy:"dev-craft-5 as 3.0.3"
.
Works prefectly! Thank you so much for the quick response :) I'll let you close the issue once the change is officially released.
Describe the bug
The way we can extend Vizy is by registering custom extensions (or nodes, marks, etc.) on the global
Craft.Vizy.Config
, which seems to be shared by all Vizy fields in an entry form.The problem is that if one field registers a plugin and the other does not, the plugin is going to affect both of them because extensions are registered globally.
To give a specific example, I have the following plugin:
As you can see in the
Enter
function, I have to access some deeply nested prop to retrieve the current field config and check if the plugin is actually enabled. for that field.This is a pretty hacky workaround.
I was wondering if there was a way to scope registered plugins to their respective fields? If not, I believe this should be addressed.
Steps to reproduce
Craft CMS version
5.4.3
Plugin version
3.0.3
Multi-site?
Yes
Additional context
This might not be the case with ALL plugins, it depends on what they register.