Jump to content

Fieldtype modules


MarkE
 Share

Recommended Posts

Fieldtype modules

Not really a tutorial, but a bunch of stuff I learnt in building a fieldtype module (FieldtypeMeasurement). That module is used as a starting point for many of the examples.

Happy to take corrections and improvements 😃

Basics

For a (full-featured) module, you actually need two module files:

  • FieldtypeModuleName.module; and

  • InputfieldModuleName.module

The Fieldtype module defines the general settings for the fieldtype (how it appears in the setup->field page), together with how it interacts with the database, while the Inputfield module defines how the field appears when editing it in a page.

In addition, for complex fields, you can define a class to hold your field values in an object. This allows you to provide custom methods for use in the API. Otherwise you can store field values as any existing type or ProcessWire object

The chart below summarises the interactions of these elements and the subsequent sections describe the methods in more detail.

178210595_Fieldtypemodulechart.jpg.1a7e6db0bcf528207898344ab59baa91.jpg

Fieldtype Module

The important methods are described below.

__construct()

Generally not much is required here (apart from parent::__construct();). If you have a php script with the field object then include it (require_once() ).

SQL database interaction

getDatabaseSchema(Field $field)

This is essential. It states what data will be saved to the SQL database (via the sleepValue function - see below). An example is:

public function getDatabaseSchema(Field $field) {

    $schema = parent::getDatabaseSchema($field);

    $schema['data'] = 'double NOT NULL';  // value in base units
    $schema['magnitude'] = 'varchar(64)'; // value in current units - needs to be text to store composite values
    $schema['unit'] = 'text NOT NULL';
    $schema['quantity'] = 'text NOT NULL';


   return $schema;
}

'data' is required and is a primary key field which means that 'text' cannot be used, although varchar(64) is OK. Often (as here) it would be a numeric field of some type. Other items can be defined as required.

___sleepValue(Page $page, Field $field, $value)

This determines how the ProcesssWire field object is mapped to the SQL schema. You need to return an array where the keys are the elements defined in the schema, e.g.:

    $sleepValue = array(
        'data' => $data,
        'magnitude' => $magnitude,
        'unit' => $value->unit,
        'quantity' => $value->quantity
    );
    return $sleepValue;

___wakeupValue(Page $page, Field $field, $value)

This is basically the inverse of sleepValue - mapping the array from the database into the field object. In the example below, the field object (Measurement) extends WireData. Properties in WireData objects can be stored in the 'data' property via 'get' and 'set' methods. getBlankValue() (see next section) performs the initial setting of these - config values for the field (see below) can be set, but otherwise the settings are just placeholders. Properties set to a WireData object can also be set or accessed directly, like $item->property or using array access like $item[$property]

public function ___wakeupValue(Page $page, Field $field, $value) {
        // if for some reason we already get a valid value, then just return it
        if($value instanceof Measurement) return $value;
        // start a blank value to be populated
        $measurement = $this->getBlankValue($page, $field);
        // if we were given a blank value, then we've got nothing to do: just return a blank Measurement object
        if(empty($value) || !is_array($value)) return $measurement;
        // create new Measurement object
        $measurement->quantity = $value['quantity'];
        // ... custom processing ...
        $measurement->baseMagnitude = $value['data'];
        if($value['unit']) {
            $measurement->unit = $value['unit'];
            $units = $measurement->getUnits();
            if(array_key_exists($value['unit'], $units) && isset($value['magnitude'])) {
                $measurement->magnitude = explode('|', $value['magnitude']);
            } else {
                $measurement->magnitude = $measurement->baseMagnitude;
                $measurement->unit = $measurement->units->base;
                $this->error('... error msg ...');
            }
        } else {
            //... 
        }
        if(!is_array($measurement->magnitude)) $measurement->magnitude = [$measurement->magnitude];
        return $measurement;
    }

getBlankValue(Page $page, Field $field)

This should return an empty item of the appropriate type. For instance, if your field object is an array, just return array(); If the field type is an object then you will need to return a 'new ObjectClassName()'. Pre-fill any config values from the Fieldtype settings but leave blank those which are set in the Inputfield,

In the above example, the field object data was set as follows:

    public function getBlankValue(Page $page, Field $field) {
        /* @var $field FieldtypeMeasurement */
        $measurement = new Measurement($field->quantity, null, []);
        if ($field->quantity) $measurement->set('quantity', $field->quantity);
        $measurement->set('magnitude', []);
        $measurement->set('shortLabel', null);
        $measurement->set('plural', null);
        return $measurement;
    }

Configuration

___getConfigInputfields(Field $field)

This defines how the Details tab in the field setup page will look. The best thing to do here is to find a fieldtype module that is similar to the one you want if you are uncertain. Broadly the process is:

  • define the config object - $inputfields = parent::___getConfigInputfields($field);

  • for each config item, use the appropriate input field, e.g . $f = $this->modules->get("InputfieldSelect");

  • assign the relevant attributes. $f->name = $f_name; is important as it enables the item to be subsequently referred to as $field->f_name in, for example, getBlankValue().

  • append each item ($inputfields->append($f);) and return $inputfields;

___getConfigAllowContext(Field $field)

This determines if the above input fields are allowed to have unique values per Fieldgroup assignment enabling the user to configure them independently per template in the admin, rather than sharing the same setting globally. E.g.

public function ___getConfigAllowContext(Field $field) {
   $a = array('quantity', 'units', 'hide_quantity', 'show_update');
   return array_merge(parent::___getConfigAllowContext($field), $a);
}

In this example the settings 'quantity', 'units', 'hide_quantity' and 'show_update' can be varied in different template contexts.

 

Important If you are allowing your config fields to vary between templates then in wakeupValue() you must call getBlankValue() using the context not the field - e.g.

public function ___wakeupValue(Page $page, Field $field, $value) {

   $context = $field->getContext($page->template);
   $measurement = $this->getBlankValue($page, $context);

Link with the Inputfield module

This is done with

getInputfield(Page $page, Field $field)

e.g.:

public function getInputfield(Page $page, Field $field) {
   $inputfield = $this->wire('modules')->get('InputfieldMeasurement');
   $inputfield->setField($field);
   return $inputfield;
}

If you want to reference the current page in the inputfield, you will also need to include $inputfield->setPage($page);

Inputfield Module

__construct()

Generally not much is required here (apart from parent::__construct();). If you have a php script with the field object then include it (require_once() ).

Configuration

___getConfigInputfields()

This is pretty much exactly the same construction as the similar method in the Fieldtype class. The only difference is that these settings will appear in the 'input' tab of the fieldtype settings, rather than the 'details' tab.

 

___getConfigAllowContext(Field $field)

This is the equivalent to the Fieldtype::getConfigAllowContext() method, but for the "Input" tab rather than the "Details" tab.

Input and output

The key methods for this module are to render it from the fieldtype and database and to process the user inputs.

___render()

$field = $this->field will have the field config settings from the fieldtype module. $this->attr('value') will have the current values for the field. If there is no current values then, if using a field object, you will need to create a new object, e.g.:

if($this->attr('value')) $value = $this->attr('value'); // Measurement object
else {
   $value = new Measurement();
}

You can then use $field and $value to display the inputfield (which might be a fieldset) as required using the appropriate pre-existing inputfield modules. (Again, find an existing module that is similar, if you are uncertain).

___processInput(WireInputData $input)

Here you take the inputs and update the field values. As in render(), set $value = $this->attr('value') ; and then modify $value for the inputs.

For example, set $name = $this->attr('name'); and then assign the inputs thus:

$input_names = array(
   'magnitude' => "{$name}_magnitude",
   'unit' => "{$name}_unit",
   'quantity' => "{$name}_quantity",
   'update' => "{$name}_update"
);

You can then loop through the inputs and carry out the required updates. The example below is slightly convoluted but illustrates this:

        foreach($input_names as $key => $name) {
            if(isset($input->$name) && $value->$key != $input->$name) {
                if($key == 'magnitude') {
                    $input->$name = trim($input->$name);
                    if(!is_numeric($input->$name)) {
                        $magnitude = explode('|', $input->$name);
                        $magnitude = array_filter($magnitude, 'is_numeric');
                        $value->set($key, $magnitude);
                    } else {
                        $value->set($key, [$input->$name]);
                    }
                } else {
                    $value->set($key, $input->$name);
                }
                $this->trackChange('value');
            }
        }

When all is done, return $this;

Custom classes

As mentioned earlier, for complex field types it may be useful to set up custom classes to hold the data. Typically a custom class would extend WireData, which is ProcessWire's class designed for runtime data storage. It provides this primarily through the built-in get() and set() methods for getting and setting named properties to WireData objects. The most common example of a WireData object is Page, the type used for all pages in ProcessWire.

Properties set to a WireData object can also be set or accessed directly, like $item->property or using array access like $item[$property]. If you foreach() a WireData object, the default behaviour is to iterate all of the properties/values present within it. Do not declare any such properties in your class (or declare properties with the same name) otherwise you will end up with two properties, one in the 'data' array and one outside it and endless confusion will result.

It is advisable to put any such classes in your own namespace. In that case, you will need to include 'use' statements in your script - e.g.

use ProcessWire\{FieldtypeMeasurement, WireData};
use function ProcessWire\{wire, __};

and also include use statements in your module scripts, e.g.

use MetaTunes\MeasurementClasses\Measurement;
  • Like 10
Link to comment
Share on other sites

Nice overview!

For full fledged field types, you'll often also want to implement Fieldtype::getConfigAllowContext and Inputfield::getConfigAllowContext. They return an array with the names of those config fields defined in their respective getConfigInputfields method that may be overridden in template or fieldgroup context.

The Inputfield class by default returns these config fields:

		return array(
			'visibility', 
			'collapsed', 
			'columnWidth', 
			'required', 
			'requiredIf', 
			'requiredAttr',
			'showIf'
		);

So make sure to call parent::getConfigInputfields first, then add your own config inputs. A good example is how InputfieldText does this:

	public function ___getConfigAllowContext($field) {
		$a = array('initValue', 'pattern', 'placeholder', 'maxlength', 'minlength', 'required', 'requiredAttr'); 
		return array_merge(parent::___getConfigAllowContext($field), $a); 
	}
	

Now the initValue, pattern, placeholder, maxlength, required and requiredAttr settings can be overridden in each template the field is used in.

  • Like 4
Link to comment
Share on other sites

On 11/22/2021 at 5:44 AM, BitPoet said:

For full fledged field types, you'll often also want to implement Fieldtype::getConfigAllowContext and Inputfield::getConfigAllowContext. They return an array with the names of those config fields defined in their respective getConfigInputfields method that may be overridden in template or fieldgroup context.

I have updated the post to reflect this and also added the following:

Important If you are allowing your config fields to vary between templates then in wakeupValue() you must call getBlankValue() using the context not the field - e.g.

public function ___wakeupValue(Page $page, Field $field, $value) {

   $context = $field->getContext($page->template);
   $measurement = $this->getBlankValue($page, $context);
  • Like 2
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...