Problem/Motivation

As part of #2721129: Workflow Initiative, we want to improve revision metadata and publishing state capabilities for content entity types, in order to allow them to be used in the following contexts:

Proposed resolution

Introduce a new base class for content entities which supports extended revision and publishing state capabilities by default, through RevisionLogInterface / RevisionLogEntityTrait and \Drupal\Core\Entity\EntityPublishedInterface / EntityPublishedTrait.

The list of core entity types which will implement the new base class is being discussed in #2745619: [policy, no patch] Which core entities get revisions?.

Remaining tasks

User interface changes

Nope.

API changes

API addition: a new content entity base class is available.

Data model changes

Nope.

Comments

amateescu created an issue. See original summary.

amateescu’s picture

Status: Needs review » Needs work

The last submitted patch, 2: 2825973-combined.patch, failed testing.

amateescu’s picture

Status: Needs work » Needs review
FileSize
5.26 KB
252.52 KB

Ok, BlockContent needs the status field first so it will require it's own issue, so let's try to convert only nodes here.

timmillwood’s picture

The status field is added to BlockContent in #2820848: Add a publishing status field to BlockContent

Berdir’s picture

+++ b/core/modules/node/src/Entity/Node.php
@@ -466,31 +400,9 @@ public static function baseFieldDefinitions(EntityTypeInterface $entity_type) {
+    $fields['revision_timestamp']->setQueryable(FALSE);

I have no idea what this is supposed to be. And why this field on node wouldn't be "queryable" while it would be on the trait/default definition. Either both shouldnt' be queryable or neither?

Should we also use this for some test entity types? One that does nothing but extend from this, to make sure that this works out of the box on its own?

dawehner’s picture

I have no idea what this is supposed to be. And why this field on node wouldn't be "queryable" while it would be on the trait/default definition. Either both shouldnt' be queryable or neither?

Making them not queryable seems to be just a pure historical effect. If you are honest, there is a big value in a complex moderation workflow, in which people want to know which particular revisions they have touched for example. Enabling queryability, is IMHO not some sort of BC break.

timmillwood’s picture

If I understand right setting it as not queryable is just to not break BC, maybe we can look in a follow up about resolving this.

dawehner’s picture

@timmillwood
Sure, but we could enable it for new entity types and then just override it in node ... even I still don't see how it should be a BC break :)

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.