Draft "Update Entry" opaque behavior in multi site setup (Could lead to unexpected content changes)

[christianruhstaller]

Description

If you have a multisite Craft installation and you want to work with drafts the behavior when updating an entry from a draft is not what a normal user would expect and could lead to changed content on the entry on a different site.

If you create a draft for an entry this draft will be created for all the sites (If configured) and this is expected. Now you want to use this draft only for the english site. This draft is scheduled to be published in 3 days. In the meantime you fix an error on the german site of the same entry (not via the draft) und save the entry.

After 3 days you will publish the draft from the english site. The english sites draft is published and works perfectly. But what you do not know is that your fix on the german site was overwritten by the german sites draft entry which was not updated by the fix you made on the german entry which is in my opinion a valid and practical workflow.

Steps to reproduce

1. Create an entry on a multisite instance (english + german)
2. Create a draft on the english site (Will create also a draft for the german site)
3. Edit entry for the german site
4. Publish draft on english site

Observed behavior

After you publish the draft your changes on the german sites are overwritten by the state of the german draft

Expected behavior

You only want to publish the draft for the english site and not the german site.
Actually it could be quite confusing that a draft will get automatically created for another site.

A typical use case could be a promo action only for the us site and not the german site.
I think this "feature" needs some refinement.

Additional info

• Craft version: 3.2.5.1

[brandonkelly]

Quick update – this is marked as an enhancement because it is currently working as intended. Drafts in Craft 3.2+ now store content for all sites, as opposed to just the site the draft was created from. When you apply a draft, it is expected that all sites’ content would be updated because each of those sites could contain changes within the draft.

That said it is clearly leading to unexpected consequences, so it’s worth revisiting.

[ifrimere]

@brandonkelly - Thank you for considering bumping this issue up in priority.

Unfortunately, the way "Drafts" has been designed for Craft 3.2 breaks the basic translation workflow model for any content managers who want to update and manage their Target Entries and Sites on an individual basis.

We will put together some generic professional translation workflow details further explaining the need for a solution to this issue and will share with you soon.

We look forward to discussing this further, but we think one potential option for Craft to fix this issue would be to allow for single Drafts to be updated independently from each other across multi-sites.

---

Reference 'closed' ticket: #4811
Reference screencast video: https://imgur.com/8mZ7iBg

[sidedwards]

@brandonkelly - Do you think it could make sense to add a default $propagate = true parameter to the createDraft() method in craft\services\Drafts that can be switched off directly or via a Section setting if needed?

I see how draft propagation can be useful in certain workflows but compared to previous versions of Craft, I think it can be confusing when a user creates a draft that auto-propagates when expecting it to be site-specific. Thoughts?

[matthewmrotter]

Ditto what @ifrimere said.

Am I correct in thinking that content managers in different languages have to work off the same draft or else they run the risk of overwriting each other's content?

[rhoffmann]

I would just like to add more priority to this.
Currently we have an issue regarding multiple languages with drafts. When an editor creates a draft in one language (which automatically happens when you open the preview), and then applies that draft, all the other Languages/Sites are overwritten with the content of that language. Is that an issue that is specific to our setup in the structure? That is really a major issue for us (our customers) and i cannot really see how this can be called working as intended.

When the editor saves the entry without creating a draft, saving only the language works well.

[ctmaloney]

There should be a config option to go between the current functionality (versions and drafts and propagate across sites) and the functionality that sparked the change here: #2669

[ctmaloney]

I'll also add that switching section settings back to "Only save entries to the site they were created in" shouldn't automatically delete all entries in the other sites as that creates a whole different set of issues.

[mdominguez]

Unfortunately, the way "Drafts" has been designed for Craft 3.2 breaks the basic translation workflow model for any content managers who want to update and manage their Target Entries and Sites on an individual basis.

Very true. Have been hammering my head on this when a client told us their translations got overwritten every time they modified an entry, apparently after they previewed it first (which automatically creates a draft), only to find out this is default behaviour...

Is there any short-term solution on how this can be avoided? We can't afford having this client lose their translated content every couple of days by just previewing and updating an entry..

[ifrimere]

• Great news from P&T that this issue is being addressed in next release (3.4). Looking forward to hearing more details about what the fix will entail and its ETA for readiness.
• For any devs posting or viewing this issue thread and anxiously awaiting the 3.4 release, just a quick note that in our latest 1.2.5 Translations Plugin we introduced a revised 'publishing' workflow that bypasses applying 'Drafts' in order to go live with new translations, without negatively impacting other language's/site's content.
• The fully functional Translations Plugin may not be a cost effective workaround in the short term for your sites if the 'Draft publishing' issue is the only thing needing to be fixed, but if you or your clients' can't wait for 3.4 to be launched, or your Translation Workflows could benefit from the full suite of order management and content export/import features, then combined with it's short term fix for translations publishing, it could be good translation site management solution option to explore.

[mdominguez]

I would just like to add more priority to this.
Currently we have an issue regarding multiple languages with drafts. When an editor creates a draft in one language (which automatically happens when you open the preview), and then applies that draft, all the other Languages/Sites are overwritten with the content of that language. Is that an issue that is specific to our setup in the structure? That is really a major issue for us (our customers) and i cannot really see how this can be called working as intended.

When the editor saves the entry without creating a draft, saving only the language works well.

@brandonkelly I too believe this needs more priority than an enhancement for a next release. It currently breaks our clients content-editing workflow as they are losing already translated content. Unless there is a way that I'm not aware of right now in that we can change something in our structure / field settings that could prevent this from happening? Thanks a lot for looking into this!

[mdominguez]

Hmm apparently I now only experience this issue in Neo fields.. Of which I've created an issue here => link

[brandonkelly]

This is now resolved for Craft 3.4!

• Now when editing a draft, fields and attributes reveal whether their values have been modified within the draft, modified in the source entry, or both (conflicting).
• When a draft is out-of-date with the source entry, it’s now possible to merge the latest entry changes into the draft, from a button in the sidebar. And even if you don’t, the latest entry changes will be automatically merged in when you click “Publish changes”.

Change tracking is built on top of delta update support (#5146), so these features will only be available to drafts that were created after updating to Craft 3.4.

To help test, change your craftcms/cms requirement in composer.json to:

"require": {
  "craftcms/cms": "3.4.x-dev",
  "...": "..."
}

Then run composer update.

[huelabs]

@christianruhstaller and @ifrimere, did this update resolve your issues? If I understood Christian's initial request, this is still a major unresolved issue if multiple site authors are working on the same entry.

Screenshare example: https://download.hamiltonsupport.com/wl/?id=DNEmxczbYGZA0kIzcf42asHvQ1LLOhtu

This is the dilemma as I understand and experience it:

1. For this example, let's say we have two sites: EN and DE. We also have two users: User1 and User2.
2. User1 creates a new draft for an EN entry; we'll call this EN-Draft.
3. DE version automatically gets assigned a new draft by Craft; we'll call this DE-Draft.
4. User1 makes changes to EN-Draft.
5. User2 makes changes to DE-Draft. User2 is not ready to publish their DE-Draft changes.
6. User1 is ready to publish their EN-Draft changes and clicks the "Publish changes" button.
7. EN entry now reflects EN-Draft. User1 is 🥳
8. DE entry now reflects DE-Draft. User2 is totally 🤬

I guess my question is has anyone figured out an acceptable procedure for their users to work on the same entry and not accidentally publish each others drafts?

[sidedwards]

@huelabs in the scenario you describe above, the draft changes get applied simultaneously because you are working within the same "EN Draft." Ideally, you should be able to create multiple drafts, merge content updates that have occurred since draft creation, and publish them asynchronously. However, Craft still has issues with merging localized content into drafts, particularly Matrix fields #5503, so that may not be a viable option.

... did this update resolve your issues?

If you're referring to the https://github.com/AcclaroInc/craft-translations plugin, we have a solution to support asynchronous draft publishing while avoiding the content overwrite issues. As long your "nested" block types (i.e., Matrix, SuperTable, Neo, etc.) are localized (stored on a per-site/language) basis, you can publish drafts created through the plugin on a per-site/language basis without content getting reverted or overwritten.

[huelabs]

I believe we still have some serious issues when creating multiple drafts by multiple authors. I could be totally off here, but any clarification would be super useful. Here's a new screen share with 3 scenarios: https://download.hamiltonsupport.com/wl/?id=nWwwOiTDNwiwWH8OreZ5NUvloahfpQ8N

[ifrimere]

@huelabs - scenarios 2 & 3 are a tough challenge to watch in your shared video b/c putting myself in the shoes of a content manager, source content should never unexpectedly revert to a previous version just b/c target content changes in any way. But maybe there's something in the Craft internal loc workflow I'm not aware of.

@sidedwards - do you have any recommendations for @huelabs to better enable simultaneous content (not structure) updates to source/target entries whereby the source entry won't get changed in an undesirable way?

[JamesNock]

Has there been any updates on this because as far as I can see this is still a major issue in CraftCMS version 3.7.13 and is causing us headaches. Our use case is:

Site A
Site B

Are both sites in English, in different groups and hosted on different domains. Reverting the content to an earlier version on Site A also changes the content for Site B and vice versa.

Any help would be massively appreciated.

[brandonkelly]

@JamesNock It’s not possible to revert an entry’s content in just one site. When you revert a prior revision, all of that revision’s content across all sites will be reverted, not just whatever site you are looking at.

[JamesNock]

Thank you very much for confirming this to be the case @brandonkelly. As far as I can tell, it doesn't actually revert the other sites to the earlier version that they were on but actually replaces their content with that which is in the revisiion you just chose. i.e.

Site A in January had an entry with a title of 'TITLE A Jan'
Site B in January had an entry with a title of 'TITLE B Jan'

Site A in February had an entry with a title of 'TITLE A Feb'
Site B in February had an entry with a title of 'TITLE B Feb'

If, in March, I change the revision of Site B to be that of January's then I thought the expected behaviour would be:

Site A title stays as 'TITLE A Feb'

Your comment suggests that it will actually be 'TITLE A Jan'.

But in fact it will actually be 'TITLE B Jan'.

I hope that helps in some way and that my contrived example makes some kind of sense because something feels off here.

[brandonkelly]

@JamesNock Just tested this, and both sites’ titles are getting reverted to their prior versions as expected on my end.

Make sure you’re running the latest version of Craft, and go to Settings → Sections and edit the entry type you’re working with, and ensure that its Title Translation Method is set to “Translate for each site”, if that’s the behavior you want.