#We were here together autosave update

This way we keep the ability to mark specific fields and/or some of their properties as storage required, meaning that the system as a whole can't function without actual data for them in the database (for example: the bundle of an entity type), and the 'required for a published/default revision' would be just a presentation-level constraint, for example: the article content type needs some data in a summary field otherwise it can't be displayed in listings, or something like that :)Īside from the validation and entity system challenges, I think it would be a good idea to use multiple layers for storing auto-saved draft revisions, because we shouldn't store a draft revision in the database every 5 seconds or so, which would translate to every few characters typed in an entity form. Then we can decouple the two required and storage required concepts and make the first one only about 'required at the UI/presentation layer'. One possible solution is to extend the new 'storage required' concept used by base fields and make it available for the properties of a field as well.

Log in or register to post I also think that the NotNull constraint is the (first) critical piece of the puzzle and should be the main focus point at the beginning, at least for the technical aspect of this feature.

However, even if you chose a simple constraint like NotNull which is enforced when a field is marked required, disabling that would potentially cause db level constraint violations, resulting in data not being saved, since those fields can be marked as NOT NULL at the table level. So it seems validation shouldn't be enforced for some constraints for draft content, because the system as it stands is being used for a lot more than making sure user input is valid. I think there are also other examples where validations are in place to stop major usability headaches with regards to non-translatable fields across translations in pending revisions, ContentTranslationSynchronizedFieldsConstraintValidator comes to mind. A random example is: #2856363: Path alias changes for draft revisions immediately leak into live site.

One of the things to consider is, the validation system is used to protect the integrity of the published version of the content in some cases. This sounds like a great idea, but also quite tricky to implement. With the terminology stuff out of the way, I think it's a good idea to try and add the ability to not enforce entity validation when the entity will be saved as a pending revision, and only enforce it when we're saving a default revision. It is stored as a pending revision (draft), and it can get to a default revision state when the whole workspace is pushed/published to Live. stage) can be marked as published via the Publishing status field, however this doesn't mean that the content is 'published' and displayed to anonymous site visitors. Default revisions are what's displayed to anonymous site visitors, while pending revisions can be seen as drafts, usually displayed only to site editors, and which may or may not end up being 'promoted' to a default revision state.Īn example why this matters is to take the core Workspaces module as a concrete scenario: a piece of content edited (either created or updated) in a non-live workspace (e.g. 'outdated' in Drupal 8, and we should switch the terminology to be in terms of default and pending revisions. I'd like to point out that thinking in terms of published / unpublished as workflow states is a bit.

#We were here together autosave update

See Update issue summary task instructions. Issue summaries save everyone time if they are kept up-to-date. If an issue significantly affects the usability of Drupal, use Needs usability review instead (see the governance policy draft for more information).

It is used to alert the product manager core committer(s) that an issue represents a significant new feature, UI change, or change to the 'user experience' of Drupal, and their signoff is needed. If an issue significantly impacts only one subsystem, use Needs subsystem maintainer review instead, and make sure the issue component is set to the correct subsystem. It is used to alert the framework manager core committer(s) that an issue significantly impacts (or has the potential to impact) multiple subsystems or represents a significant change or addition in architecture or public APIs, and their signoff is needed (see the governance policy draft for more information).