Problem/Motivation

In https://www.drupal.org/core/deprecation#how-class we recommend adding the @trigger_error to the MAIN part of the PHP file outside of the class. This has several problems.

  • For unit tests if they are run altogether the code is only loaded once so you have different results if the test is executed on its own or if the test is executed along side all the other tests and one of the other tests includes the same deprecated code
  • Sometimes in core we check if a class exists but that in and of itself does not mean the the class is actually used. eg. plugins and route controllers - see #2935610-19: Remove or deprecate MediaDeleteMultipleConfirmForm and it's route definition for example.

Proposed resolution

Change the advice to move the @trigger_error() into the constructor to over come this and move all the deprecations in core to be consistent.

Proposed update to docs

Abstract classes, interfaces and traits

Add @trigger_error('...', E_USER_DEPRECATED) under the namespace declaration. Add an @deprecated and @see phpdoc annotations to the class docblock. For example:

<?php

namespace Drupal\datetime\Tests\Views;
	
@trigger_error('The ' . __NAMESPACE__ . '\DateTimeHandlerTestBase is deprecated in Drupal 8.4.0 and will be removed before Drupal 9.0.0. Instead, use \Drupal\Tests\BrowserTestBase. See http://drupal.org/node/the-change-notice-nid.', E_USER_DEPRECATED);

/**
 * Base class for testing datetime handlers.
 *
 * @deprecated in Drupal 8.4.0 and will be removed before Drupal 9.0.0. Use
 *  \Drupal\Tests\BrowserTestBase.
 *
 * @see http://drupal.org/node/the-change-notice-nid
 */
abstract class DateTimeHandlerTestBase extends HandlerTestBase {

Concrete classes

Concrete, instantiated classes
Add @trigger_error('...', E_USER_DEPRECATED) to the constructor. If there is no constructor, add one and ensure it calls the parent constructor. Add an @deprecated and @see phpdoc annotations to the class docblock. For example:

<?php

namespace Drupal\taxonomy;

use Drupal\Core\Entity\EntityManagerInterface;
use Drupal\Core\Entity\EntityTypeInterface;
use Drupal\Core\Entity\EntityViewBuilder;
use Drupal\Core\Language\LanguageManagerInterface;
use Drupal\Core\Theme\Registry;

/**
 * View builder handler for taxonomy terms.
 *
 * @deprecated in drupal:8.4.0 and is removed from drupal:9.0.0. Use
 * \Drupal\Core\Entity\EntityViewBuilder instead.
 *
 * @see https://www.drupal.org/node/2924233
 */
class TermViewBuilder extends EntityViewBuilder {

  /**
   * {@inheritdoc}
   */
  public function __construct(EntityTypeInterface $entity_type, EntityManagerInterface $entity_manager, LanguageManagerInterface $language_manager, Registry $theme_registry = NULL) {
    @trigger_error(__NAMESPACE__ . '\TermViewBuilder is deprecated in drupal:8.4.0 and is removed from drupal:9.0.0. Use \Drupal\Core\Entity\EntityViewBuilder instead. See https://www.drupal.org/node/2924233.', E_USER_DEPRECATED);
    parent::__construct($entity_type, $entity_manager, $language_manager, $theme_registry);
  }

}

Remaining tasks

None. The policy docs are updated and there is a followup to implement this in core.

User interface changes

None

API changes

None

Data model changes

None

CommentFileSizeAuthor
#4 2935897-4.patch37.29 KBalexpott

Issue fork drupal-2935897

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

alexpott created an issue. See original summary.

alexpott’s picture

Issue summary: View changes
Status: Active » Needs review
Issue tags: +Needs release manager review

As a proposed change to https://www.drupal.org/core/deprecation#how-class this should have release manager review.

alexpott’s picture

Issue summary: View changes
alexpott’s picture

Issue summary: View changes
StatusFileSize
new37.29 KB

So Traits and Interfaces still need to be deprecated using @trigger in the MAIN so they are still going to have the autoload issues. I guess the main problem is when we have some form of discovery like plugins and controllers. So this recommendation should only be for concrete classes and not abstract classes / interfaces / traits. Updated suggested docs changes to reflect that.

Most of the patch attached is moving migration plugin deprecations to the constructor which is as per the updated plugin deprecation suggestion anyway as discovering plugins is definitely not the same as using them.

larowlan’s picture

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.

catch’s picture

I think this is reasonable, and the docs haven't changed in five years, main question is why we haven't run into more issues with this in the past five years but maybe we just don't deprecate entire classes very often?

smustgrave’s picture

Status: Needs review » Needs work
Issue tags: +Needs Review Queue Initiative

This issue is being reviewed by the kind folks in Slack, #need-reveiw-queue. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge require as a guide.

@catch can say in the limited time I've been involved in core I haven't seen a deprecated class.

Please IS is still good

Will need an update to the patch for 10.1

xjm’s picture

Title: Change how we deprecate classes » [policy, then docs, then patch?] Change how we deprecate classes
Status: Needs work » Active

I think we should document the pattern in the handbook first, then come up with a new patch for 10.1.x. (It'd have to be new, because anything deprecated in Drupal 8 is long gone by now.)

xjm’s picture

Status: Active » Needs review

Added the below section to the policy:
https://www.drupal.org/about/core/policies/core-change-policies/drupal-d...

The one change I made is specifying that the "deprecate below the namespace" pattern also applies to classes with a private constructor that are intended for static use only (since the class is not instantiated, the constructor won't ever be called).

https://www.drupal.org/node/2856615/revisions/view/12898137/12939350

smustgrave’s picture

Status: Needs review » Reviewed & tested by the community

Not sure if this is the right status

But reading the section Concrete, instantiated classes and Abstract classes, interfaces, traits, and classes with a private constructor
makes sense to me.

quietone’s picture

Issue summary: View changes

Update Issue Summary to use current deprecation message format and @see format.

quietone’s picture

Issue summary: View changes

Oh, I updated the policy page as well.

So, we have agreement and the policy page is now up to date.

The last piece is to change core to follow this new policy.

quietone’s picture

Title: [policy, then docs, then patch?] Change how we deprecate classes » [policy, then docs] Change how we deprecate classes
Issue summary: View changes

Discussed with xjm and we both agree to move the work to implement this to a followup, #3335966: Update class deprecations to implement "Concrete, instantiated classes" policy.

I think we are done here.

xjm’s picture

Status: Reviewed & tested by the community » Fixed

Agreed!

Status: Fixed » Closed (fixed)

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

meeni_dhobale made their first commit to this issue’s fork.

xjm’s picture

Adding lots of missing credits for the discussion.

xjm changed the visibility of the branch 2935897-policy-then-docs to hidden.