By gisle on

I have created a custom module that creates a custom text field. The general idea is that site builders who install this module shall be able to use this custom field when creating a custom content type using the Drupal UI.

I have most of this working for me now, but it is not ready for others, for the following reasons:

  1. When creating a custom content type using the UI, you get to give it a name, e.g.: "mycontenttype".
  2. When adding a field to a content type using the UI, you get to give it a name, e.g.: "field_myfield".

At the moment, my custom module, works if, and only if, the site builder uses exactly the same name as those given in the examples above. The reason for this is that custom processing for the field in hook_node_presave is selected by:

switch ($entity->getType()) {
  case 'mycontenttype':
    // custom processing to normalize field
    $entity->field_myfield = $normalized_value;
    break;

… and if the content type is named something else, this custom processing will not happen.

Likewise, this line of code:

$value = $entity->field_myfield->getValue();

… will not work if the the field is named something else than field_myfield.

I am going to look at some contrib modules that create custom fields to see how they avoid locking the code to specific names that probably will not be used by someone who create a custom content type with a custom field, using the Drupal UI.

However, since this must be a fairly common problem, I ask here just in case somebody already know the answer.

⋅ Categories: Drupal 9.x

Comments

wombatbuddy’s picture

wombatbuddy commented

What about to do you processing in a custom field formatter instead?

gisle’s picture

gisle
he/him
Primary language Norwegian Bokmål
Location Norway
commented

A custom field formatter would be nice if I only want to change how the field/item is displayed on the website.

The reason I'm doing it in hook_node_presave() is because I want to alter how the field is saved prior to saving it, and when the field formatter sees and instance of the field, it has already been saved.

(I've edited the OP to make the use case clearer.)

- gisle

wombatbuddy’s picture

wombatbuddy commented

You can check a field type instead of field name, see the example below. But I still don't understand what do you need to do with a field value. 

use \Drupal\node\NodeInterface;
use \Drupal\field\FieldConfigInterface;

/**
 * Implements hook_ENTITY_TYPE_presave() for node.
 */
function my_module_node_presave(NodeInterface $node) {
  $field_definitions = $node->getFieldDefinitions();
  foreach ($field_definitions as $field_definition) {
    if (!$field_definition instanceof FieldConfigInterface) 
      continue;
    }
    elseif ($field_definition->getType() === 'my_field_type') {
      $field_name = $field_definition->getName();
      // Do something.
    }
  }
}
gisle’s picture

gisle
he/him
Primary language Norwegian Bokmål
Location Norway
commented

Time to wrap up and go home now – I'll check out your suggestion first thing tomorrow.

As for what I need to do with the field value, I need to be able to correct it. The whole point of this custom module is to create a custom field that improves the robustness of the code the UX by doing this:

  1. Only inserting data that's on canonical form into the database.
  2. If user input is not on canonical form (but recognizable), I make it canonical in hook_node_presave – instead of rejecting it as invalid.

Having data on canonical form in the database make all operations on the data more robust, since there is no need to check for alternative representations. Allowing the user to use alternative representations when typing in the the field's data, provides a better UX than badgering the users with error messages until they type in the data exactly right.

A typical example is a 10 digit phone number, such as "4155552671". The canonical form is s 10 letter string without any spaces or punctation or other symbols.  However people will probably not type the canonical form. They will type something like "(415) 555 2671" or "415 555 - 2671" or some other variations of this.  I want to allow all reasonable variations of how to type a 10 digit phone number, but store the canonical form (i.e. "4155552671") in the database.

- gisle

wombatbuddy’s picture

wombatbuddy commented

Got it, thanks. But I doubt that this solution will be more effective than your initial solution, which was posted here.