Property Details

$decimals public property #

The number of digits allowed after the decimal point

public integer $decimals = 0

$max public property #

The maximum allowed number

public integer, float, null $max = null

$min public property #

The minimum allowed number

public integer, float $min = 0

$size public property #

The size of the field

public integer, null $size = null

Method Details

displayName() public static method #

Returns the display name of this class.

public static string displayName ( )

getContentColumnType() public method #

Returns the column type that this field should get within the content table.

This method will only be called if hasContentColumn() returns true.

public string getContentColumnType ( )

getElementValidationRules() public method #

Returns the validation rules for an element with this field.

Rules should be defined in the array syntax required by yii\base\Model::rules(), with one difference: you can skip the first argument (the attribute list). Below are some examples:

[
    // explicitly specify the field attribute
    [$this->handle, 'string', 'min' => 3, 'max' => 12],
    // skip the field attribute
    ['string', 'min' => 3, 'max' => 12],
    // you can only pass the validator class name/handle if not setting any params
    'bool',
];

public array getElementValidationRules ( )

getInputHtml() public method #

Returns the field’s input HTML.

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

return '<textarea name="'.$name.'">'.$value.'</textarea>';

For more complex inputs, 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 path/to/myplugin/templates/_fieldinput.html, passing the $name and $value variables to it:

return Craft::$app->view->renderTemplate('myplugin/_fieldinput', [
    'name'  => $name,
    'value' => $value
]);

If you need to tie any JavaScript code to your input, 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 getInputHtml() 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 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 getInputHtml() method that includes field-targeting JavaScript code might look like:

public function getInputHtml($value, $element)
{
    // Come up with an ID value based on $name
    $id = Craft::$app->view->formatInputId($name);
    // 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('myplugin/_fieldinput', [
        'name'         => $name,
        'id'           => $id,
        'namespacedId' => $namespacedId,
        'value'        => $value
    ]);
}

And the _fieldinput.html template might look like this:

<textarea id="{{ id }}" name="{{ name }}">{{ value }}</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 getInputHtml ( $value, craft\base\ElementInterface $element = null )

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 ( )

init() public method #

Initializes the object.

This method is invoked at the end of the constructor after the object is initialized with the given configuration.

public void init ( )

normalizeValue() public method #

Normalizes the field’s value for use.

This method is called when the field’s value is first accessed from the element. For example, the first time entry.myFieldHandle is called from a template, or right before getInputHtml() is called. Whatever this method returns is what entry.myFieldHandle will likewise return, and what getInputHtml()’s and serializeValue()’s $value arguments will be set to.

public mixed normalizeValue ( $value, craft\base\ElementInterface $element = null )

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\fields\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\fields\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\fields\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 ( )