Taking control of cache_field - increasing performance

Created on 21 May 2020, almost 5 years ago
Updated 12 March 2025, 26 days ago

I've noticed that a simple refresh of a Content-Type (which has only 1 field marked to be encrypted) passes through encrypt / decrypt 23+ times. Because d7 has cache_field used for various reasons (field cache, field info cache, field info types cache, field group, etc) - this module hijacks the cache and forcefully encrypts absolutely everything (including HUGE JSON configs which have no sensitive data).

That's why we have issues like https://www.drupal.org/project/field_encrypt/issues/2972797 🐛 Warning: this module can break your site or cause major performance issues Closed: outdated

Because this module hijacks the caching - it would be nice to provide some control over what things we don't want to be encrypted. This issue would help - https://www.drupal.org/project/drupal/issues/2237187 - but it won't make it to d7, so we'll need to provide a why to whitelist certain CID patterns to skip encryption.

Why use a whitelist of cache id patterns instead of enforcing what we believe to be the 'right' ones - because there are a LOT of contrib modules, using the cache_field how they see fit - some might indeed have sensitive data, some might not.

This can provide considerable boost to website that use this module - I'm considering to use it, but as soon as I installed and configured just 1 field of 1 content-type, the whole website became much-much slower.

Feature request
Status

Closed: outdated

Component

Code

Created by

🇪🇸Spain Nikro Benalmadena, Malaga

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

Production build 0.71.5 2024