-
Notifications
You must be signed in to change notification settings - Fork 638
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make plugin settings consistent with component settings #1989
Comments
As of Craft 3.4 it will be possible to configure plugins from return [
'components' => [
'plugins' => [
'pluginConfigs' => [
'plugin-handle' => [
'...' => '...',
],
],
],
],
]; Not exactly what I was thinking when I created this issue, but it makes more sense to think of plugins as part of the application than user-definable components like custom fields / widgets / etc. |
@brandonkelly |
@piotrpog Yeah this just adds another option, for when it makes sense to modify the plugin’s module config directly. |
…r overriding via plugin config ([#1989](craftcms/cms#1989)) ([#11039](craftcms/cms#11039))
…r overriding via plugin config ([#1989](craftcms/cms#1989))
I haven't been able to find any documentation or blogs on how to set this up. I've gotten something working by looking into how other plugins do it, but I'm curious if there is a standard recommended way. |
It’s documented here: https://craftcms.com/docs/4.x/extend/plugin-settings.html (see Overriding Setting Values specifically for info on how the config files work). |
Should this approach work for non-plugin modules as well? |
Modules don’t have a dedicated settings concept. You can make a module configurable by adding public properties to the return [
'modules' => [
'my-module' => [
'class' => MyModule::class,
'propertyName' => 'override value',
// ...
],
],
// ...
]; |
It is weird how everything in Craft 3 that has settings implements the settings as public properties on the model, except for plugins, which must define settings on a separate model.
The reason is because plugins are modules, not models, and currently models are the only thing that support validation.
We could possibly hack something together using Yii’s DynamicModel class, but that would add additional complexity, because setting values, validation rules, and errors would need to be transferred between the plugin and the model when running validation. Ideally Yii 2.1 will implement yiisoft/yii2#11884, and we’ll be able to implement validation support consistently across plugins and other components.
The text was updated successfully, but these errors were encountered: