Right now we're using a "status" entity key in annotations, and only for config entities.
However, users and nodes have their own concept of "status", and would benefit from the same methods.

This is needed to accomplish #2001190: Use derivatives for action plugins properly.

Postpone on this

#2001190: Use derivatives for action plugins

CommentFileSizeAuthor
#1 status-interface-2009958-1.patch23.73 KBtim.plunkett

Comments

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
commented
Status: Active » Needs review
StatusFileSize
new status-interface-2009958-1.patch23.73 KB

This seems to work pretty well.

Status: Needs review » Needs work

The last submitted patch, status-interface-2009958-1.patch, failed testing.

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
commented
Status: Needs work » Needs review

#1: status-interface-2009958-1.patch queued for re-testing.

Status: Needs review » Needs work

The last submitted patch, status-interface-2009958-1.patch, failed testing.

berdir’s picture

berdir
Primary language German
Location Switzerland
commented

One problem is that it's called status everywhere but actually has a different meaning for many entity types:
- Node/Comment: published/unpublished
- User: blocked/active
- File: temporary/permament
- Config entities: enabled/disabled

So changing $node->status = NODE_PUBLISHED to $node->enable() actually loses clarity of what we're doing, $node->publish() would make more sense (or something like that). Same for $user->enable()/$user->block().

This is similar to one of the main criticism of TypedData/EntityNG from the Sunday discussion before the DrupalCon, having too generic methods due to too generic interfaces.

A compromise could be, assuming we want to keep the unified ->status, just enforce setStatus() on the interface and leave it up to each entity type interface (or config entities in general) to define meaningful shortcuts?

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
commented

msonnabaum made similar points to me in IRC.
He suggested completely separate interfaces like PublishableInterface and BlockableInterface.
Those could either stand alone, or extend EntityStatusInterface (which would only contain setStatus() as you suggest).

berdir’s picture

berdir
Primary language German
Location Switzerland
commented

Note: The interface in #1818568: Convert files to the new Entity Field API follows that approach now, I have a getStatus() (which could be removed with an implements this) and specifc methods to check and set to temporary/permanent.

berdir’s picture

berdir
Primary language German
Location Switzerland
commented
Issue summary: View changes

Updated issue summary.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

catch’s picture

catch
he/him
Primary language English
commented
Issue summary: View changes
Status: Needs work » Closed (duplicate)

This is the older issue, but #2129953: Abstract entity status out to an interface has more discussion (some of which covers the same ground as here), so closing as duplicate of that.

catch’s picture

catch
he/him
Primary language English
commented
Version: 8.1.x-dev » 8.3.x-dev
Status: Closed (duplicate) » Needs work

I cross-posted with amateescu, moving this back to CNW and 8.3.x, let's do oldest wins after all.

timmillwood’s picture

timmillwood
Primary language English
Location 🏴󠁧󠁢󠁷󠁬󠁳󠁿 Wales, UK
commented

In #2810381: Add generic status field to ContentEntityBase I am proposing to move the status base field definition to ContentEntityBase, this would then get added to all entity types which define a 'status' entity key. Currently only Node does, but I am looking to add this key to Comment too. Only Node and Comment use status as a published state. This change will allow any other entity types to use status for other needs, but the status entity key will mean published/unpublished.

timmillwood’s picture

timmillwood
Primary language English
Location 🏴󠁧󠁢󠁷󠁬󠁳󠁿 Wales, UK
commented

This issues looks to specifically focus on config entities, where as what I am looking at in #2810381: Add generic status field to ContentEntityBase is specifically content entities. Therefore I will open a new issue for adding EntityPublishedInterface for content entities, then this issue can stay open to focus on an issue for config entities.

I think the config entity interface for the status field should be EntityEnabledInterface.

timmillwood’s picture

timmillwood
Primary language English
Location 🏴󠁧󠁢󠁷󠁬󠁳󠁿 Wales, UK
commented

#2811667: Introduce EntityPublishedInterface for content entities is for content entities.

Anonymous’s picture

Anonymous (not verified) commented

For what it's worth, the points made in #6 (3 years ago) are the best approach to take ideally as an API to the end user. The exception to the point is that the base EntityStatusInterface should not contain a setStatus(int $status); method, as it just exposes magic numbers/constants to the code base, which is the underlying problem that should really be fixed.

We need to expose the methods on the domain to completely abstract and invoke the expected changes underneath. For example: enable() and disable() - I raised a similar point regarding the interfaces in #2811667: Introduce EntityPublishedInterface for content entities for EntityPublishedInterface, suggesting publish() and retract(). The other interfaces (ie. BlockableInterface) should expose other methods (block()) to invoke semantic expected changes in the domain. The underlying statuses then become irrelevant and do not need to be exposed to the API at all, there is also then no need to worry about backwards compatibility. At the end of the day the domain will always be the same, and one day the status property might need to be ripped out entirely in favour of something better; the abstraction layer has failed to do it's job if it is not possible to do that.

Many interfaces that just allow you to pass in arbitrary values to set on the domain, isn't really an abstraction of anything, and just results in objects that are bags of setters and getters; this leads to anaemic domain design, which just leaves massive scope for error.

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.

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

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

Version: 8.5.x-dev » 8.6.x-dev

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

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

andypost’s picture

andypost
he/him
Primary language Russian
commented

It looks outdated

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.