Problem/Motivation
The ability to mark entities uncacheable is broken ^8.7 and tests are broken.
Currently there are two tests failing on HEAD:
\Drupal\Tests\field_encrypt\Unit\EncryptedFieldValueManagerTest\Drupal\Tests\field_encrypt\Functional\FieldEncryptCacheTest
This prevents contributors and maintainers from benefiting of existing tests until we get the branch passing.
Proposed resolution
Identify if the failures are correct, and if so fix the bugs, otherwise fix the tests.
Remaining tasks
Do it.
User interface changes
None.
API changes
None.
Data model changes
None.
Release notes snippet
None.
| Comment | File | Size | Author |
|---|---|---|---|
| #24 | 3124830-24.patch | 17.13 KB | alexpott |
| #24 | 20-24-interdiff.txt | 8.47 KB | alexpott |
| #20 | interdiff-3124830-13-20.txt | 361 bytes | suzymasri |
| #20 | 3124830-20.patch | 14.4 KB | suzymasri |
| #13 | 3124830-13.patch | 14.73 KB | manuel garcia |
Comments
Comment #2
manuel garcia commentedThis should get
EncryptedFieldValueManagerTestpassing again.As far as
FieldEncryptCacheTestgoes I fear it may be a legitimate failure. In any case I've not been able to figure it out, and would love some help on it :)Comment #4
manuel garcia commentedI've spent some time trying to figure out why
FieldEncryptCacheTestis failing, but I cant figure out why.Perhaps this is expected behaviour? The
testDynamicPageCacheis passing which is great.the node entity type
isPersistentlyCacheablereturns false, yet\Drupal::cache('entity')->get($cid)does return the test node entity in it.I have also noticed that when we set the node to be uncacheable it was failing as well, and managed to fix that by saving the node after changing its field storage settings.
Took the liberty of improving the base test class:
EncryptTestBase.NodeCreationTrait.EntityTypeManagerinstead of the deprecated entity manager.And removing
setFieldStorageSettings()fromFieldEncryptCacheTestsince we have a better version onFieldEncryptTestBase.Comment #5
manuel garcia commentedMeaning we need to pull in Encrypt module for the test bot, so adding it to composer.json as requirement.
Comment #6
manuel garcia commentedArgh wrong patch! Please ignore the files on #5.
multitasking--
Comment #7
manuel garcia commentedDocs for this: https://www.drupal.org/docs/develop/using-composer/managing-dependencies...
Let's see if it works this time...
Comment #8
manuel garcia commentedOK, its not finding the encrypt base class because it needs this patch to be applied, which i had on my machine from working on it yesterday.
#3124749: Convert simpletests to PHPUnit
I'd say lets wait for that to get in before working more on this.
Comment #9
manuel garcia commentedComment #10
manuel garcia commented#3124749: Convert simpletests to PHPUnit got in, so this is now unblocked :)
Comment #11
manuel garcia commentedOK its now failing because the base test class is only available on the latest tarball of Encrypt. I believe for tests there is benefit in testing against Encrypt HEAD so we can identify issues before a release is cut, in theory catching bugs before they hit sites.
Comment #13
manuel garcia commentedOK, great to see the tests running now.
About the last failing test, I've come to the conclusion that we should only be testing what the module does, which is altering the entity type definition on
field_encrypt_entity_type_alter()to mark them as not cacheable. We're already testing this which should be enough imho:In other words, testing core's caching mechanism is out of scope, so I'm removing that part of the test.
Also removing an unused use statement.
Comment #14
vijaycs85I don't think we could do require-dev here and make encrypt as a dependency in the info file. Either we should move to `require` or make it test_dependecies in info file?
mocking more methods since they are not relevant?
Comment #15
vijaycs85I also agree on on #13 on testing only what is updated by this module.
Comment #16
manuel garcia commentedThanks @vijaycs85 for the review!
Re #14.1:
The reason for that is that since #3124749: Convert simpletests to PHPUnit got in 9 days ago, the
EncryptTestBaseclass we're extending is only available on Encrypt dev until they make a release. I explained this on #11 also noting that there could be benefits of testing against dev, up to the maintainers of course.Re #14.2:
Not a Unit tests expert here... I added these because otherwise there are failures on
testGetEncryptedFieldValue()like:Trying to configure method "setEncryptedValue" which cannot be configured because it does not exist, has not been specified, is final, or is staticIf it's not the right fix then please let me know - happy to learn :)Re #15: 👍
Comment #17
jeroentI postponed #3111904: Drupal 9 deprecated code report on this issue, since this issue already fixes some deprecations and it makes it easier to test Drupal 9 compatibility once the tests are fixed.
Comment #18
nerdsteinI'm coordinating with @rlhawk to get a release of encrypt out for Drupal 9 support. I believe this would help address the concern in #16.
Comment #19
rlhawkThe new version of Encrypt has been released.
Comment #20
suzymasriUpdated patch to remove Encrypt dependency from composer.
Comment #21
manuel garcia commentedThanks @suzymasri, great to see we can now just depend on the latest encrypt module release.
I think think this is ready to go :)
Comment #22
vijaycs85Looks good. I tried to see if we could clean up drupal ci related files, it seems we are not there yet.
Comment #23
tame4tex commentedI do have some concern regarding the changes to
FieldEncryptCacheTest::testEntityCache. Part of the reason that test was failing was because this module no longer prevents the entity from being cached. I think this is something we need to be concerned with because of the security implications.Sure, the changes are testing the entity definition is correctly set but are we not just perpetuating the false assumption that this module prevents entities with encrypted fields from being cached when it doesn't.
In a nutshell
field_encrypt_entity_type_alter()is no longer doing what it is expected to do, so is it not correct that the test fails?If we fix this issue Drupal Core 8.7 compability then I am assuming this test will pass.
This issue provides more explanation as to why changes to the entity cache settings are no longer working:
Unable to turn off entity caching since 8.7.0 release
Thoughts?
Comment #24
alexpott@tame4tex that's a great point. I've merged in #3081143: Drupal Core 8.7 compability and fixed it so that entity definitions are maintained as entity types become cacheable or uncacheable according to field_encrypt.
Also these changes have the added benefit of not needing a cache clear if field encrypt cacheability changes.
Comment #25
alexpottMarked #3107865: Unable to turn off entity caching since 8.7.0 release as a duplicate - @mdolink should get credit here.
Marked #3081143: Drupal Core 8.7 compability as a duplicate - @ytsurk should get credit here.
Comment #26
vijaycs85Thanks @alexpott. It looks much better and seems cleaned other issues as well. I think we are good to go.
Comment #28
alexpottCrediting people as per #25
Comment #29
alexpottCrediting all the contributors and committing - thanks!
Comment #31
manuel garcia commentedFantastic, thanks so much @alexpott for that!
Comment #32
tame4tex commentedExcellent @alexpott and very happy to hear you are on board as a new maintainer of this module. Thank you to everyone for the efforts on this. It is fantastic to have passing tests again!
There is still an issue with caching though on existing sites. The current code doesn't update the last installed definition of existing entity types that are already listed in
uncacheable_entity_types. We need an update script to do that.I am also thinking we need to ensure the cache properties are set correctly on any entity type definition update.
I have created a new issue for this:
Cache issue persists after update to 8.x-2.0-alpha2