Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
According to #2346261: Deprecate entity_create() in favor of a <EntityType>::create($values) or \Drupal::entityManager()->getStorage($entity_type)->create($values), entity_create() function is going to be deprecated so we shouldn't use it anymore. When the entity type is known we should directly call <EntityType>::create()
. What to do when the entity type is not known or is variable is upon discussions.
Beta phase evaluation
Issue category | Task |
---|---|
Issue priority | Normal because it's just about code cleanup and good practices |
Prioritized changes | The main goal of this issue is DX, performance and removing code already deprecated for 8.0.0. (Direct calls to EntityType::create are better than generic calls to entity_create for readability) |
Disruption | This change is not disruptive at all as it only replaces deprecated functions call by their exact equivalent. |
Proposed resolution
Replace the deprecated call to entity_create()
by a proper call to <EntityType>::create()
.
Before:
entity_create('field_config', $field_values)->save();
After:
use Drupal\field\Entity\FieldConfig;
FieldConfig::create($field_values)->save();
Remaining tasks
Task | Novice task? | Contributor instructions | Complete? |
---|---|---|---|
Create a patch | Instructions | Done | |
Manually test the patch | Novice | Instructions | |
Review patch to ensure that it fixes the issue, stays within scope, is properly documented, and follows coding standards | Instructions |
User interface changes
None.
API changes
None.
Comment | File | Size | Author |
---|---|---|---|
#6 | interdiff-2to6.txt | 560 bytes | Mac_Weber |
#6 | date_format-2641522-6.patch | 1.32 KB | Mac_Weber |
#2 | date_format-2641522-2.patch | 1.36 KB | Mac_Weber |
Comments
Comment #2
Mac_Weber CreditAttribution: Mac_Weber as a volunteer commentedComment #3
mpdonadioThanks for the patch.
Normally, we just do a `git diff origin/8.1.x` instead of `git patch` when working with core patches.
Should be in alphabetical order.
Otherwise, I think this is fine. This is the only usage, and it is in a test already (and it still passes), so I don't think we need more test coverage. Per the allowed changes during the Drupal 8 release cycle, this doesn't qualify for patch release, but 8.1.x is OK.
Setting NW for the nit in the `use` section.
Comment #4
Mac_Weber CreditAttribution: Mac_Weber as a volunteer commented@mpdonadio regarding item
2
once I had pointed the same mistake made by another developer, but other people said it does not need to be in alphabetical order. On that time I'd looked for the coding standard about this rule, but I could not find anything. Please post a link for this rule if it really exists so I could also point people in the other issue.regarding item
1
I got used to always use git-format =PComment #5
mpdonadio@Mac_Weber, ordering the `use` section isn't explicitly in the coding standards right now and I can't raise anyone on IRC right now. I have had core patches pushed back for this before, and every single core file that I have examined has them ordered. Speaking as the maintainer of this subsystem, I would like to keep this usage (get it? :) for all patches that get committed. I did ping one of the doc maintainers to see if she recalls a discussion about this.
Comment #6
Mac_Weber CreditAttribution: Mac_Weber as a volunteer commentedComment #7
mpdonadioAssuming this comes back green...
Comment #8
catchCommitted/pushed to 8.1.x, thanks!