[PP-2] Add revision support

I always thought that one of the niceties of entity embed was not having to embed the markup of the entity, making sure all updates to the embedded entity would be automatically reflected when the host entity is rendered. When embedding specific revisions we are "freezing" a specific state of the embedded entity, so kind of loosing a little bit the advantage of only having metadata in the tag...

FWIW I do understand that in certain scenarios the editor *might* want to tie revision X of the host entity with revision Y of the embedded entity, and move them (manually?) in sync as the editorial workflow advances, but I wonder if this is very common scenario. I admit I haven't a lot of experience working with entity_reference_revisions, so I may very well be missing something here.

That said, IMHO the easiest approach would be to strongly rely on core and postpone this on #1812202: Add UUID support for entity revisions, so when time comes we just need to integrate that support in the UI, instead of dealing with "how to manage revisions from UUIDs" or having to refactor to also include normal IDs in the tags.

When considering workflow, it would be nice to hold back a specific update of an embed, if wanted.

So if you have a node with a gallery embedded in it, and you want to hold back the new images, it would be nice to be able to update the gallery and create a new revision that doesn't affect the currently embedded gallery.

Right now the way to do that would be to create a copy of the gallery and embed that new one. Then you have a duplicate gallery with slightly different versions.

It would be nice if you could create a new revision of the embed that is tied to the parent node, and when you decide to publish the parent node, you could use the new revision.

If you are within the dialog and you make an edit, I could see two potential workflows:
1) become the default revision of the gallery
or
2) stay as a separate revision of the gallery embedded in this node, without affecting the gallery when embedded elsewhere.

When considering the diff module and viewing revisions, an entity reference leaves a lot to be desired.

It would be nice if you could view an old revision of the node, and revert to it, and the version of the gallery at that point would be retrievable.

Right now, if you view a diff, there's no difference unless you change the entity id, and that would require creating a copy.

If you had a small embed that you update regularly, especially if you're changing one field on it, it would be better to have revisions of that embed.

But for other use cases, such as an embed where you'd want to edit it and have it immediately update across all embedded instances, a non-revisionable embed would be better.

One approach would be to have entity embeds and revisionable entity embeds.

For anyone who's interested, based on a proof of concept by oknate I've uploaded the Media Reference Revisions module and have gotten it somewhat stable. It provides a method of shoehorning faux revision support into Entity Reference and Entity Embed without modifying the underlying data. There are additional use cases to work out, because this whole thing gets a little complicated and we need to clearly define exact use cases, but it may help some sites out there.

When considering workflow, it would be nice to hold back a specific update of an embed, if wanted.

Wouldn't it make more sense to then apply workflows to anything that's embeddable itself? Otherwise you'd have to not only the embeddee go through a workflow, but every single embedder, for every single update to the embeddee.

I think there are use cases where it's important that something is embedded in wysiwyg of a node, and you want the embed tied to that one node and you would want it revisionable. You'd want it to behave like a paragraph attached to an entity reference revisions field, but you'd want it in the wysiwyg for whatever reason.

We ran into issues on a project where, without a revision on the embed the diff module wouldn't work properly, since an update to the embedded media would update it through every revision of the parent node.

I think there should be a separate embed type, perhaps, which would be an entity embed that would not be portable, and only a id reference, but a type of embed that would be a revisionable entity that is tied to the entity with the wysiwyg. This would allow the diff module to show changes to the embeds, and allow it to inherit the workflow of the parent.

I think due to the issue you're mentioning above, these revisionable entity embeds should always be tied to one parent.

Another way to do it would be a short code to hold all the data within the wysiwyg. For smaller embeds this works better and the data model is smaller. The translations could be handled by the parent entity, and the revision would be handled by the wysiwyg field. But it would be nice if it were fieldable entity.

I think there should be a separate embed type, perhaps

That's also what I was thinking: for the small percentage of sites that need this, create a entity_revision_embed filter/module, that builds on top of the entity_embed filter, but layers on one additional attribute: data-entity-revision. That way the complexity remains isolated to that one module and to those sites that choose to use it.

Let's do new features after stabilizing Entity Embed; let's do it after #2577887: Entity Embed 8.x-1.0.0 release, which itself is postponed on #2577891: Entity Embed 8.x-1.0.0-rc1 release.

Workaround for revision support.