I encountered a fatal error when trying to add a new plaintext field to an entity type using the Drupal GDPR module. The issue appears when I add the plaintext field to a basic page node as an example, but it seems to occur with any entity type.

Steps to reproduce:

  • Navigate to the 'Manage fields' configuration page of any entity type (e.g., basic page node) with the GDPR module enabled.
  • Try adding a new plaintext field to the content type.
  • Save the field settings.
  • Actual result: After saving the field settings, the following error is displayed:

The website encountered an unexpected error. Please try again later.

Error: Call to a member function getType() on null in Drupal\gdpr_fields\Form\GdprFieldSettingsForm::buildFormFields() (line 281 of modules/contrib/gdpr/modules/gdpr_fields/src/Form/GdprFieldSettingsForm.php).
Expected result: The new plaintext field should be added to the entity type without any errors.

Environment:
Drupal version: 10.2.1
PHP version: 8.3.0
GDPR module version: 3.0.0

Issue fork gdpr-3414301

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

rbosscher created an issue. See original summary.

keshavv’s picture

Status: Active » Needs review
StatusFileSize
new700 bytes

Created patch. Please test.

rbosscher’s picture

Hi thanks for the patch, it seems to fix it at line 281, but now raises a new error:

TypeError: Drupal\gdpr_fields\Entity\GdprField::propertyCanBeRemoved(): Argument #1 ($field_definition) must be of type Drupal\Core\Field\FieldDefinitionInterface, null given, called in /var/www/public_html/modules/contrib/gdpr/modules/gdpr_fields/src/Form/GdprFieldSettingsForm.php on line 378 in Drupal\gdpr_fields\Entity\GdprField->propertyCanBeRemoved() (line 369 of modules/contrib/gdpr/modules/gdpr_fields/src/Entity/GdprField.php).

rbosscher’s picture

It appears that:

`$fieldDefinition = $fieldManager->getFieldDefinitions($entity_type, $bundle_name)[$field_name]` returns `null`.

On the other hand, `$fieldDefinition = $fieldManager->getFieldDefinitions($entity_type, $bundle_name)` returns the current entity without the field that is yet to be created. So it returns null because the new field is not in the fieldDefinition.

I think it has to do that the field add process has changed in 10.2. Where it was a two step process it is now combined in one step.

rbosscher’s picture

StatusFileSize
new1.93 KB

This patch restores the functionality for creating new fields, thus enabling the site to operate correctly. However, I suspect it may affect the GDPR module's operation, since it essentially bypasses the expected presence of the newly added field.

ezkg’s picture

Any update on this issue ?

In my D10.2 application , For the patch #2 it is still raising this error

TypeError: Drupal\gdpr_fields\Entity\GdprField::propertyCanBeRemoved(): Argument #1 ($field_definition) must be of type Drupal\Core\Field\FieldDefinitionInterface, null

Using the #5 seems to bypass the error and let user create fields but it still throws this warning when I am trying.

Warning: Undefined array key "field_x" in Drupal\gdpr_fields\Form\GdprFieldSettingsForm::buildFormFields()

This is quite a major issue hope it can be resolved quickly.

bart lambert’s picture

I'm having the same issue.
Applied patch issue_3414301.patch but i'm now getting following error:

Warning: Undefined array key "field_url_van_de_video" in Drupal\gdpr_fields\Form\GdprFieldSettingsForm::buildFormFields() (line 263 of modules/contrib/gdpr/modules/gdpr_fields/src/Form/GdprFieldSettingsForm.php).

So I think somewhere there is still something missing....

Any Idea's how To fix this?

Rajeshreeputra made their first commit to this issue’s fork.

efes’s picture

I've the same situation as EZKG. Neither patch #2, nor #5 solved the initial problem under Drupal 10.2.5, PHP8.1.27

ahmetburkan’s picture

After some detective work and debugging i think that we need to think about how we approach this issue. See 3383986

Current situation:
There is a workaround patch at comment #5. This will disable the functionality to be able to configure GDPR fields while creating the new field. After saving the field editing the GDPR settings is possible. This requires an extra step for now.

Future:
We need to make a discission how we continue because it is not possible anymore to load the newly created field because it hasn't been saved until the last step in the field creation flow. That makes the function getFieldDefinitions() obsolete when calling it from the 'gdpr_fields.module' but not when you go directly to the route after saving the new field.

ahmetburkan’s picture

Status: Needs review » Needs work

Update status.

eelkeblok’s picture

I think the information that is being pulled from the field config should also be available in the form state for the form when first creating the field. We should probably make a change such that the code can get the required information from there too, if it needs to. [The mechanism making use of the field config should still keep working, ] Both for the standalone GDPR config form as well as the previous core version.

ahmetburkan changed the visibility of the branch 3414301-fatal-error-when to hidden.

ahmetburkan changed the visibility of the branch 3414301-fatal-error-when to hidden.

ahmetburkan’s picture

Status: Needs work » Needs review
StatusFileSize
new3.92 KB
eelkeblok’s picture

Status: Needs review » Needs work
eelkeblok’s picture

As a generic comment, in addition to the detailed comments in the MR, I wonder whether the buildFormFields() method could be simplified. The buildForm, which is the other place that calls this, is already checking if the field config exists, so it would be a small change to have it pass that into the buildFormFields(). If we can move the burden of getting the proper field config to the calling code (either pulling it from field storage, or from the form state when in the field creation flow), that could simplify the buildFormFields method a great deal. One consideration is that that would be a BC-breaking change, which would warrant a major version number increase.

Maybe this should become a follow-up, since the module is actually actively braking Drupal 10.2 sites.

Must-fix changes:

efes’s picture

Is there any progress with this?

rajeshreeputra’s picture

changes seems working, agree with @eelkeblok that this change might break with lower drupal version. To avoid this we should add test to create content type and add field to it.

ankitv18 made their first commit to this issue’s fork.

ankitv18’s picture

Status: Needs work » Needs review
deepakkm’s picture

Status: Needs review » Reviewed & tested by the community

Verified changes locally its working fine.

rajeshreeputra’s picture

Status: Reviewed & tested by the community » Fixed

Merged release to follow shortly.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

henk’s picture

Fatal error problem is fixed, but warring still appears when adding new field argument is not proper set, Field definition not have new field key.
/modules/gdpr_fields/src/Form/GdprFieldSettingsForm.php 269 Line:

$fieldDefinition = $fieldManager->getFieldDefinitions($entity_type, $bundle_name)[$field_name];

Should be:

$fieldDefinition = $fieldManager->getFieldDefinitions($entity_type, $bundle_name)[$field_name] ?? FALSE;
scampbell1’s picture

For anyone who is encountering the same issue that @henk and I are and needs the patch, please see attached.