Quoting myself from https://www.drupal.org/project/commerce/issues/2921000#comment-12798574:

It's obvious from the discussion above that it makes more sense for a store to be enabled/disabled than published/unpublished.
This is already the case for Promotion, Coupon, ShippingMethod, PriceList, PriceListItem.

As a result of that, we should not be using EntityPublishedInterface and EntityPublishedTrait (just like the other entity types listed above don't).
It might make sense to introduce our own interface/trait, now that it's a common pattern.

So, let's introduce EntityEnabledInterface and EntityEnabledTrait, to parallel the published ones.
We can use them for generic actions and other purposes later on.

The methods are isEnabled() and setEnabled(), as currently defined on Promotion and Coupon.
Maybe EntityStatusInterface and EntityStatusTrait sounds better, but we don't actually use the word status in the method names, just in the property name, so I was unsure.

Comments

bojanz created an issue. See original summary.

bojanz’s picture

bojanz commented

Note how core provides an automatic index for the published field:

// Add an index for the 'published' entity key.
      if (is_subclass_of($entity_type->getClass(), EntityPublishedInterface::class)) {
        $published_key = $entity_type->getKey('published');
        if ($published_key && !$this->fieldStorageDefinitions[$published_key]->hasCustomStorage()) {
          $published_field_table = $table_mapping->getFieldTableName($published_key);
          $id_key = $entity_type->getKey('id');
          if ($bundle_key = $entity_type->getKey('bundle')) {
            $key = "{$published_key}_{$bundle_key}";
            $columns = [$published_key, $bundle_key, $id_key];
          }
          else {
            $key = $published_key;
            $columns = [$published_key, $id_key];
          }
          $schema[$published_field_table]['indexes'][$this->getEntityIndexName($entity_type, $key)] = $columns;
        }
      }

We should make sure we have our own index where needed.

bojanz’s picture

bojanz commented
Status: Active » Closed (won't fix)

We have decided not to do this.

Lots of code assumes EntityPublishedInterface (Entity API access/query access, Search API filters, Views, Content Moderation, etc). It is not feasible to reimplement all of it. We'll have to accept that content entities always implement EntityPublishedInterface, even if their UI labels don't match the code terminology. After all, we already do it with bundles/types and labels/names/titles.