Provide alternatives to "[ENCRYPTED]" storage values for other field types. about field_encrypt HOT 3 CLOSED

This issue will be a critical blocker for sites that need to encrypt financial data, for example. It already is for me.

Drupal\Core\Entity\EntityStorageException: SQLSTATE[HY000]: General error: 1366 Incorrect decimal value: '[ENCRYPTED]' for column 'field_price_value' at row 1: INSERT INTO {node__field_price} (entity_id, revision_id, bundle, delta, langcode, field_price_value) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5); Array ( [:db_insert_placeholder_0] => 1165 [:db_insert_placeholder_1] => 1165 [:db_insert_placeholder_2] => example [:db_insert_placeholder_3] => 0 [:db_insert_placeholder_4] => en [:db_insert_placeholder_5] => [ENCRYPTED] ) in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 757 of core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).

from field_encrypt.

If I recall, we had to set values because the solution did not work without it. (e.g. something in core was expecting some value).

Theres two avenues here...

1. We keep this for strings and try just removing any value for numeric / date / or other core provided data types. We would need a hook for other custom field values to set their own value (or lack thereof)
2. We explore why we couldn't save nothing and try to submit a core patch or revisit alternatives so we have no default values - which is both confusing and clunky (misrepresenting the fact that the data value is stored altogether elsewhere)

from field_encrypt.

I have created a new PR that sets some sensible placeholder values, based on the property data type.

We should indeed probably explore how we can let Drupal core know that there is a particular value for the field (stored encrypted elsewhere), without having to provide a placeholder.

But until we've found a way to handle that (if possible at all), the PR at least makes sure that current core field types don't result in errors when trying to encrypt them.

from field_encrypt.