Property Details

$entryType public property #

The ID of the entry type that the widget should create

public integer, null $entryType = null

$fields public property #

The IDs of the fields that the widget should show

public integer[], null $fields = null

$section public property #

The ID of the section that the widget should post to

public integer, null $section = null

Method Details

__construct() public method #

Constructor.

The default implementation does two things:

• Initializes the object with the given configuration $config.
• Call init().

If this method is overridden in a child class, it is recommended that

• the last parameter of the constructor is a configuration array, like $config here.
• call the parent implementation at the end of the constructor.

public void __construct ( $config = [] )

displayName() public static method #

Returns the display name of this class.

public static string displayName ( )

getBodyHtml() public method #

Returns the widget's body HTML.

public string, false getBodyHtml ( )

getSettingsHtml() public method #

Returns the component’s settings HTML.

An extremely simple implementation would be to directly return some HTML:

return '<textarea name="foo">'.$this->foo.'</textarea>';

For more complex settings, you might prefer to create a template, and render it via craft\web\View::renderTemplate(). For example, the following code would render a template located at src/templates/_settings.html, passing the settings to it:

return Craft::$app->view->renderTemplate('plugin-handle/_widget-settings', [
    'widget' => $this
]);

If you need to tie any JavaScript code to your settings, it’s important to know that any name= and id= attributes within the returned HTML will probably get namespaced, however your JavaScript code will be left untouched. For example, if getSettingsHtml() returns the following HTML:

<textarea id="foo" name="foo"></textarea>
<script type="text/javascript">
    var textarea = document.getElementById('foo');
</script>

…then it might actually look like this before getting output to the browser:

<textarea id="namespace-foo" name="namespace[foo]"></textarea>
<script type="text/javascript">
    var textarea = document.getElementById('foo');
</script>

As you can see, that JavaScript code will not be able to find the textarea, because the textarea’s id= attribute was changed from foo to namespace-foo. Before you start adding namespace- to the beginning of your element ID selectors, keep in mind that the actual namespace is going to change depending on the context. Often they are randomly generated. So it’s not quite that simple.

Thankfully, craft\web\View service provides a couple handy methods that can help you deal with this:

• craft\web\View::namespaceInputId() will give you the namespaced version of a given ID.
• craft\web\View::namespaceInputName() will give you the namespaced version of a given input name.
• craft\web\View::formatInputId() will format an input name to look more like an ID attribute value.

So here’s what a getSettingsHtml() method that includes field-targeting JavaScript code might look like:

public function getSettingsHtml()
{
    // Come up with an ID value for 'foo'
    $id = Craft::$app->getView()->formatInputId('foo');
    // Figure out what that ID is going to be namespaced into
    $namespacedId = Craft::$app->view->namespaceInputId($id);
    // Render and return the input template
    return Craft::$app->view->renderTemplate('plugin-handle/_widget-settings', [
        'id'           => $id,
        'namespacedId' => $namespacedId,
        'widget'       => $this
    ]);
}

And the _widget-settings.twig template might look like this:

<textarea id="{{ id }}" name="foo">{{ widget.foo }}</textarea>
<script type="text/javascript">
    var textarea = document.getElementById('{{ namespacedId }}');
</script>

The same principles also apply if you’re including your JavaScript code with craft\web\View::registerJs().

public string, null getSettingsHtml ( )

getTitle() public method #

Returns the widget’s title.

public string getTitle ( )

iconPath() public static method #

Returns the path to the widget’s SVG icon.

public static string, null iconPath ( )

rules() public method #

Returns the validation rules for attributes.

Validation rules are used by validate() to check if attribute values are valid. Child classes may override this method to declare different validation rules.

Each rule is an array with the following structure:

[
    ['attribute1', 'attribute2'],
    'validator type',
    'on' => ['scenario1', 'scenario2'],
    //...other parameters...
]

where

• attribute list: required, specifies the attributes array to be validated, for single attribute you can pass a string;
• validator type: required, specifies the validator to be used. It can be a built-in validator name, a method name of the model class, an anonymous function, or a validator class name.
• on: optional, specifies the \craft\widgets\scenario array in which the validation rule can be applied. If this option is not set, the rule will apply to all scenarios.
• additional name-value pairs can be specified to initialize the corresponding validator properties. Please refer to individual validator class API for possible properties.

A validator can be either an object of a class extending \craft\widgets\Validator, or a model class method (called inline validator) that has the following signature:

// $params refers to validation parameters given in the rule
function validatorName($attribute, $params)

In the above $attribute refers to the attribute currently being validated while $params contains an array of validator configuration options such as max in case of string validator. The value of the attribute currently being validated can be accessed as $this->$attribute. Note the $ before attribute; this is taking the value of the variable $attribute and using it as the name of the property to access.

Yii also provides a set of \craft\widgets\Validator::builtInValidators. Each one has an alias name which can be used when specifying a validation rule.

Below are some examples:

[
    // built-in "required" validator
    [['username', 'password'], 'required'],
    // built-in "string" validator customized with "min" and "max" properties
    ['username', 'string', 'min' => 3, 'max' => 12],
    // built-in "compare" validator that is used in "register" scenario only
    ['password', 'compare', 'compareAttribute' => 'password2', 'on' => 'register'],
    // an inline validator defined via the "authenticate()" method in the model class
    ['password', 'authenticate', 'on' => 'login'],
    // a validator of class "DateRangeValidator"
    ['dateRange', 'DateRangeValidator'],
];

Note, in order to inherit rules defined in the parent class, a child class needs to merge the parent rules with child rules using functions such as array_merge().

public array rules ( )