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
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | 2935897-4.patch | 37.29 KB | alexpott |
Issue fork drupal-2935897
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:
- 2935897-policy-then-docs
compare
Comments
Comment #2
alexpottAs a proposed change to https://www.drupal.org/core/deprecation#how-class this should have release manager review.
Comment #3
alexpottComment #4
alexpottSo 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.
Comment #5
larowlanThis looks good to me
#2935610-19: Remove or deprecate MediaDeleteMultipleConfirmForm and it's route definition demonstrates why its needed
Comment #16
catchI 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?
Comment #17
smustgrave commentedThis 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
Comment #18
xjmI 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.)
Comment #19
xjmAdded 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
Comment #20
smustgrave commentedNot 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.
Comment #21
quietone commentedUpdate Issue Summary to use current deprecation message format and @see format.
Comment #22
quietone commentedOh, 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.
Comment #23
quietone commentedDiscussed 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.
Comment #24
xjmAgreed!
Comment #27
xjmAdding lots of missing credits for the discussion.