Problem/Motivation

Currently we have the abstract classes Entity, ContentEntityBase and ConfigEntityBase. Both ContentEntityBase and ConfigEntityBase extend from Entity. The naming of the abstract class Entity is inconsistent with the naming of the other classes.

We use the *Base naming convention at many places - for example WidgetBase, EntityDisplayBase, EntityReferenceFormatterBase, FormatterBase and many others ...

Proposed resolution

  1. Rename Entity to EntityBase.
  2. Provide a class Entity in the same namespace for backwards compatibility, but flag it as deprecated.

Remaining tasks

Review.

User interface changes

API changes

Data model changes

Release notes snippet

Comments

tim.plunkett’s picture

Yes.

However, by our coding standard, we'd have to rename it EntityBase.

xjm’s picture

See title. :)

tim.plunkett’s picture

Right. Also, half of our entity types inherit from ConfigEntityBase anyway, which is properly abstract.

berdir’s picture

Issue summary: View changes

It is abstract now, but hasn't been renamed. No idea if we still want to do that?

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.

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

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.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.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should 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.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should 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.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should 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.

hchonov’s picture

Version: 8.5.x-dev » 8.7.x-dev
Status: Active » Needs review
StatusFileSize
new43.68 KB

I think that it still makes sense doing this as we have ContentEntityBase and ConfigEntityBase both extending from the abstract class Entity. I've done this in the attached patch.

hchonov’s picture

Title: Should Entity be converted to an abstract EntityBase? » Convert Entity to EntityBase for consistency with ContentEntityBase and ConfigEntityBase
Issue tags: +consistency

Status: Needs review » Needs work

The last submitted patch, 10: 1883744-10.patch, failed testing. View results

Status: Needs review » Needs work

The last submitted patch, 10: 1883744-10.patch, failed testing. View results

hchonov’s picture

Status: Needs work » Needs review
StatusFileSize
new53.13 KB
new8.39 KB

Status: Needs review » Needs work

The last submitted patch, 14: 1883744-14.patch, failed testing. View results

hchonov’s picture

Status: Needs work » Needs review
StatusFileSize
new57.51 KB
new4.16 KB

That should be it.

borisson_’s picture

We should probably add a change notice as well?

joachim’s picture

Status: Needs review » Needs work
Issue tags: +Needs issue summary update, +Needs change record

The IS doesn't seem related to the issue title.

+1 on the change record.

hchonov’s picture

Issue summary: View changes
Status: Needs work » Needs review
Issue tags: -Needs issue summary update, -Needs change record

I've updated the issue summary and created a draft change record - https://www.drupal.org/node/3021808

hchonov’s picture

Issue summary: View changes
borisson_’s picture

Status: Needs review » Reviewed & tested by the community

Looks done, the tests all pass and we have a cr that explains why and how. Great work!

tim.plunkett’s picture

Status: Reviewed & tested by the community » Needs work
Issue tags: +Needs tests

As per https://www.drupal.org/core/deprecation#how this needs a @trigger_error to fire when a class extends Entity instead of EntityBase

hchonov’s picture

Status: Needs work » Needs review
StatusFileSize
new60.54 KB

I've added the @trigger_error. No other changes beside that. There is no diff, as I had to re-roll the patch.

tstoeckler’s picture

Status: Needs review » Needs work
Issue tags: -Needs tests
+++ b/core/lib/Drupal/Core/Entity/Entity.php
@@ -2,668 +2,12 @@
+ * \Drupal\Core\Entity\EntityBase instead.

I think this should be intended two spaces.

Also if the patch were rolled with -C I think it would be quite a bit smaller.

Also still needs a test for the deprecation per #22.

hchonov’s picture

Status: Needs work » Needs review
StatusFileSize
new40.88 KB
new485 bytes

I wasn't sure about how to prepare a test and what I've tried didn't worked, because if we create a new class that extends from the deprecated class Entity then the deprecation will be triggered by the autoloader before the test itself.

I've talked with @tstoeckler and he found a solution by using an anonymous class. However anonymous classes are supported only in PHP 7. As we still support PHP 5.6. we both agreed that a test case isn't necessary in this case.

P.S: I wasn't able to find any similar test in core as well, so it looks like we don't offer tests for deprecated classes.

I've prepared the new patch with the -C option. Thank you, @tstoeckler for the suggestion!

tstoeckler’s picture

Status: Needs review » Reviewed & tested by the community

Thanks, this looks good to me!

As is mentioned in #25 I really don't see a way for us to test this using our standard mechanisms.

it looks like we don't offer tests for deprecated classes

I think that is supposed to say "tests for deprecated abstract classes", as that is what is causing the problem here. Most of the deprecated abstract classes are tests themselves, for which we generally don't add tests, and I couldn't find any deprecation test for any other abstract class either. For example \Drupal\migrate\Plugin\migrate\process\DedupeBase, doesn't have a corresponding deprecation test.

hchonov’s picture

it looks like we don't offer tests for deprecated classes

I think that is supposed to say "tests for deprecated abstract classes", as that is what is causing the problem here.

Yes, this is what I've meant. Thank you for correcting me and explaining it further! :).

alexpott’s picture

Status: Reviewed & tested by the community » Fixed
diff --git a/core/lib/Drupal/Core/Entity/Entity.php b/core/lib/Drupal/Core/Entity/Entity.php
index 3ffa411f9c..610b239c8e 100644
--- a/core/lib/Drupal/Core/Entity/Entity.php
+++ b/core/lib/Drupal/Core/Entity/Entity.php
@@ -2,12 +2,14 @@
 
 namespace Drupal\Core\Entity;
 
-@trigger_error('The ' . __NAMESPACE__ . '\Entity is deprecated in Drupal 8.7.x and will be removed before Drupal 9.0.x. Instead, use ' . __NAMESPACE__ . '\EntityBase. See https://www.drupal.org/node/3021808.', E_USER_DEPRECATED);
+@trigger_error('The ' . __NAMESPACE__ . '\Entity is deprecated in Drupal 8.7.0 and will be removed before Drupal 9.0.0. Instead, use ' . __NAMESPACE__ . '\EntityBase. See https://www.drupal.org/node/3021808', E_USER_DEPRECATED);
 
 /**
  * Defines a base entity class.
  *
- * @deprecated in Drupal 8.7.x and will be removed in Drupal 9.0.x. Use
+ * @deprecated in Drupal 8.7.0 and will be removed in Drupal 9.0.0. Use
  *   \Drupal\Core\Entity\EntityBase instead.
+ *
+ * @see https://www.drupal.org/node/3021808
  */
 abstract class Entity extends EntityBase {}

Deprecation messages should refer to git tags and real releases not branches. And we need to add an @see to the change record. Fixed on commit.

alexpott’s picture

Committed 47dab9a and pushed to 8.7.x. Thanks!

  • alexpott committed 47dab9a on 8.7.x
    Issue #1883744 by hchonov, tim.plunkett, borisson_, xjm, tstoeckler,...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

quietone’s picture

publish the change record