Field collection tokens don't work with Recurly's account syncing, as field collection updates it's entity before we can check the original value. This means that the "original" data always contains our updated data.

It's super annoying, and I think it would be a huge amount of (fragile) work to really work around. Instead, this patch just gives sites the option to disable checking for field changes and always push updates.

CommentFileSizeAuthor
#8 2232797.8-force-updates.patch3 KBdeviantintegral
#1 2232797.1-force-updates.patch3.5 KBdeviantintegral
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

deviantintegral’s picture

deviantintegral CreditAttribution: deviantintegral commented
Status: Active » Needs review
FileSize
2232797.1-force-updates.patch3.5 KB
quicksketch’s picture

quicksketch
he/him
CreditAttribution: quicksketch commented
Status: Needs review » Closed (won't fix)

I'd prefer not to add it to the module, this is a pretty big hack to accommodate for field collection. $entity->original is supposed to be the original before updating, and if it's not, it really needs to be fixed in field collection.

deviantintegral’s picture

deviantintegral CreditAttribution: deviantintegral commented

It's not $entity->original that's broken, but that field collections are a separate entity. When we look at the field in the user save hook, it's already been updated so entity_load() returns the updated field collection.

I originally took this approach as it also helped us with testing account sync. We could potentially look at field collection's revision ID in $entity->original to pull up the old revision, but I'm pretty sure that won't work for users (no revisions), which is probably what most are using for Recurly accounts.

So, any other ideas? It would be really good if we could support field collection given how common it is for user address and phone information.

quicksketch’s picture

quicksketch
he/him
CreditAttribution: quicksketch commented
Status: Closed (won't fix) » Active

Hm, okay back to active then. Maybe what we could do is assemble the list of "original" tokens in presave, store them somehow, then compare them against the new values in update? I'm not sure that would help because entities are probably saved sequentially, and the collections would still probably be saved before the parent entity's presave.

aburke626’s picture

aburke626
she/her
Primary language English
Location Harveys Lake, PA, US
CreditAttribution: aburke626 at Chromatic for TheaterMania.com, Inc. commented
Status: Active » Needs work
markdorison’s picture

markdorison
he/him
CreditAttribution: markdorison at Chromatic commented
Version: 7.x-1.x-dev » 7.x-3.x-dev
apotek’s picture

apotek CreditAttribution: apotek commented

This patch no longer applies cleanly.

deviantintegral’s picture

deviantintegral CreditAttribution: deviantintegral at Lullabot for TheaterMania.com, Inc. commented
FileSize
2232797.8-force-updates.patch3 KB

Here is a straight reroll.

colan’s picture

colan
he/him
Primary language English
Location Toronto 🇨🇦
CreditAttribution: colan at Consensus Enterprises, Colan Schwartz Consulting commented

Should we tag this for D8 forward porting? Is it an issue with D8 Paragraphs? It would make sense to support that as FC is deprecated in favour of that.