[jacksleight]

This PR fixes an issue where after publishing a revision the parent set on the blueprint and field objects will still refer to the previous version of the entry.

This can cause issues during the preProcess calls fired by PublishedEntriesController::extractFromFields if you're using the parent. The issue we had is that we do something in preProcess that depends on the value of another field. We fetch the value of that field from the parent data, but if the parent is the previous version the value might be wrong.

The reason updating the parent isn't done just after clone (which would be the obvious place) is that the save calls further up in publishWorkingCopy/unpublishWorkingCopy can also result in the associated blueprint/parent objects getting out of sync, so the same issue persists, although I think that's unique to the eloquent driver.

[simonworkhouse]

@jacksleight Is there a test that you provide or perhaps an example of how I could reproduce this issue? This PR has caused an issue where the stache is taking a very long time to warm, see #11189.

[jacksleight]

@simonworkhouse I don't have a specific test no, this was an issue we were having in an addon that depends on the field parent data (as described above).

@jasonvarga If this is affecting stache performance perhaps the changes to setParent should be reverted, and the revisable class should use a new setNewParent method instead? The reason resetBlueprintCache was added was because if it's not called then resetFieldsCache exits early, since the blueprint hasn't changed, even though the parent has. This is probably only an issue when publishing revisions. Will do a PR if you agree.