Editor/publication improvements

[lenvanessen]

We use Craft extensively, and with many people (~50 authors) working in the CMS, we quite often run into some issues and chase unwanted changes. The purpose of this discussion is to provide some insights in to the some adverse effects that prpvisional drafts, automatic merges and some other features have on platforms where many authors collaborate. Hopefully, helping Craft to make the system even more awesome and manageable.

Overly sensitive change detection
Many of our editors use chrome extensions like Grammarly and some others as well. This means that the moment they open an article, too proofread for instance, Grammarly will touch the input field and Craft will create a new provisionary draft when actually no changes have been made. Not sure how to avoid this, maybe we can implement a different way of detecting changes here.

The proofreader will then tell the author what needs to be changes, and the author makes the changes. However, the proofreader often does not see the changes, because he/she/they/them will have to discard their changes (which where none) first, and they often fail to see that this is the case.

It's actually two problems I'm describing here:

1. The sensitivity of the change detection with common Chrome and other browser extensions
2. The fact that for many, the "discard changes" feature is not visible enough, they simply don't know nor understand that they are not looking at the most recent version of an article, causing them to not see the changes.

Field change detection not localized
If you change a drafts field, the blue bar that indicates a change will appear on all translations/sites, regardless of the fact if they field has actually been changed for that specific site. This makes it a bit difficult to see if fields where actually changed or not.

Independant drafts
For us, it doesn't necessarily make sense that drafts are always created for all sites. It affects performance a bit on saving, but also, from a real-world perspective, would you always want to make changes for all your sites if you create a draft?

Why, if you create a draft for the German site, is the Draft created for Spanish, Dutch etc. Even with the drafts updating themselves with canonical changes, we quite often by accident overwrite content on production. The scenario here is as follows:

1. An author on the English site is assigned to update an English article, localization will be done much later. He creates a draft for the English site (and therefore, for all sites, even though we don't need it).
2. Someone has by accident changes a draft for the one of the other sites
3. When the publisher comes in, reads the English article, and says, looks good, let's publish. There is no way to just publish the English Draft, all drafts are published, sometimes carrying unwanted changes.

Some good optimizations here would be:

1. Allow creation of drafts independently per site;
2. Allow publication of a single draft for one site, not auto-publish all drafts.

One additional note to make here, is that by doing this, the history that is listed for changes in an article will be more accurate. Because the person that publishes the draft wil automatically for all sites be listed as the person that made the latest changes, even though in a lot of scenario's he really didn't for most site

Localized publishing dates and authors
This relates to another ticker discussion that's open. But for more complex publishing platforms, the simple fact that post-dates and authors are not localizable creates many problems:

1. We cannot schedule content properly, all articles have to go live at the same time, where is usually the translations will have to wait.
2. If you update a article on site A, by default sorting, it will be listed in the top position on site B, even though it has not been updated there
3. We can't control Craft's awesome rights functions, because all sites have their own authors, and we can only assign one to an entry that is propagated trough all sites. So features like "only edit their own articles" cannot be used.

By some hack-ish solution we have just created a new table with:
siteId
authorId
postDate

To store these values localized, and we throw them into place in the beforePrepare and afterPrepare of the EntryQuery, but surely there is a nicer approach that can be taken from the Craft Core.

[brandonkelly]

Appreciate the feedback, however it is difficult for us to work with discussions like this that cover multiple areas. Can you please focus the discussion around a single requested improvement (e.g. single-site drafts) and post a new discussion(s) for other suggestions?

[lenvanessen]

Surely, I'll split them up, you can mark this one as answered