Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
Since #2478507: Schema configs missing dependencies to property and processor providers, the processing form is broken. After adding at least one processor, adding an Activity Creator processor does not work. It breaks in ProcessorBase::getPropertyDefinitions() where $this->propertyDefinitions seems to be wrongly initialized by deserialization. Not sure why.
Proposed resolution
Remaining tasks
User interface changes
API changes
Comment | File | Size | Author |
---|---|---|---|
#8 | broken-processing-2495039-8.patch | 3.64 KB | Arla |
#8 | broken-processing-2495039-8.interdiff.txt | 1.16 KB | Arla |
#7 | broken-processing-2495039-7.patch | 3.42 KB | Arla |
#6 | broken-processing-2495039-6.patch | 1.93 KB | Arla |
#4 | Screen Shot 2015-05-28 at 13.28.30.png | 255.18 KB | Arla |
Comments
Comment #1
ArlaQuick fix: remove the lazy loading
Comment #2
ArlaSorry, no tests needed. They already exist and are failing, but of course they are in #2430111: Re-add tests when CRM Core is on drupal.org, not committed. I say let's test this manually and commit it, then update the CRM tests separately.
Comment #3
mbovan CreditAttribution: mbovan at MD Systems GmbH commentedI applied the patch attached to the #26 in #2476539: Extend contact matcher and contact creation to support user URIs and the patch 1 from this issue, but still having troubles to add 2 contact matcher processors and 1 activity creator (like in the tests). Contact matcher processors are added and then when I try to add activity creator (or to remove those 2) I get
400 Bad Request
.Comment #4
ArlaTrying to debug this. Seems like a bug with serialization/unserialization, not sure exactly where or what. The screenshot shows the state at a breakpoint in __wakeup for a schema plugin, where the elements in $this->propertyDefinitions are incorrectly unserialized: The 'uid' property is a PropertyDefinition (correct), the 'uuid' property is a FieldItemDataDefinition (wrong) and the rest of the properties are just TRUE (wrong). The correct PropertyDefinition objects have instead ended up as an array in $this->propertyDefinitions['uid']->dataDefinition->itemDefinition->fieldDefinition.
This is a bit tricky to debug further, as the object in its serialized form is 80 KB of text (gist).
Hoping that @Berdir has got something to add.
Comment #5
ArlaUsed ser-pretty to pretty-print the serialized object, got this: gist. Interesting part:
I guess that means references to already printed objects, but those numbers do not occur elsewhere so I cannot tell.
Edit: Also in the serialized-and-then-pretty-printed gist, the PropertyDefinition objects are inside uid->dataDefinition->itemDefinition->fieldDefinition.
Comment #6
ArlaTook a break from trying to find the exact problem, and instead found another "quick fix" that doesn't solve but rather avoids it. The patch just removes the static caching of propertyDefinitions from SchemaBase.
Also tried to write a test for this, but I cannot make it fail without the fix :)
Comment #7
ArlaActually I had to combine the two fixes to get this working well enough. That is, removing static caching of property definitions from two different classes. That kind of narrows it down a bit.
Comment #8
ArlaLet's commit this for now, to enable us to proceed with other issues, and turn this issue into restoring the removed caching.
Comment #10
ArlaCommitted and pushed.
Changing title to reflect the new goal.