Closed (fixed)
Project:
Drupal core
Version:
8.7.x-dev
Component:
entity system
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
3 May 2018 at 06:15 UTC
Updated:
24 Mar 2019 at 07:39 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
berdirDeprecated most of the easy cases, a bunch of usages left that need other services that aren't already injected.
Comment #5
kaythay commentedRerolling with some test fixes.
Comment #6
berdirthis seems to be some kind of leftover that's not actually injected or used here as far as I see?
Also not sure why the changes to BlockContentTypeTest were added, that's not a form?
Comment #7
martin107 commentedI am looking at this now.
Comment #8
martin107 commenteda) entityFieldManager - "not actually injected or used". Confirmed .. a good reason to remove it
b) BlockContentTypeTest - although the work looks good we do need to deconflict to prevent overlap
Just as a mini review - I have visually scanned the patch all changes look good.
Comment #9
berdir"The entity type manager"
This is also not complete yet, there are a few more. I'm expanding it to all form classes, sincde there aren't many more.
Some are already being updated in #3025427: Add @trigger_error() to deprecated EntityManager->EntityTypeBundleInfo methods, you might want to skip those or wait on that to get in.
Comment #10
berdirThat issue landed, so this could use a reroll, happy to do reviews here.
Comment #11
martin107 commentedso after a git pull I am one commit ahead ...
2969109-8.patch still applies so no reroll is needed.
Comment #12
berdirOk, still a bunch of forms left however that need to be updated :)
Comment #13
alexpottAlso can we use the deprecated property trait so we can prove we've removed all usages in core?
Comment #14
berdirThe thing is that forms and some other entity handlers are different and get the entity (type) manager injected through setter methods, so we can't remove the property as it would always be triggered. And I'd rather not remove that method/call.
Doing a grep on all *Form.php files is pretty easy as I did in #9 and we will catch anything we missed as soon as we deprecate the methods entirely.
Comment #15
martin107 commentedI am going to chew on this awhile.
Comment #16
martin107 commentedOk progress, not ready for human review yet.. BUT testbot should return a list of broken test for me to address.
So in this patch
a) Fixed the "The entity type manager" change form #9
b) Regarding the question
and the "injected through setter method" response in #14
In the last batch of changes there were only two such classes EntityViewDisplayEditForm and EntityFormDisplayEditForm both derived from a FormBase class
So that prompted the query against both
find core/ -name "*Form.php" | xargs grep "entityManager-"
and
find core/ -name "*FormBase.php" | xargs grep "entityManager-"
I have made lots of little changes so the potential for err is large. All I can say is that site install works.
Comment #18
martin107 commentedThis should have fewer errors.
Note to self.
So at least some of the entity_type method calls need to be made to the other services formed when it was broken up. ( I used this change record as a reference https://www.drupal.org/node/2549139 )
Additionally I need to write a change record as the end.
[
a) EntityFormInterface was given an additional setter
b) I add the EntityFIeldManagerInterface and the EntityDisplayRepositoryInterface to a few constructors
]
I will work on the remaining failures tomorrow.
Comment #20
berdirwe should not do this. Instead inject this service to teh specific forms that need it, should only be a few.
this is on the entity display repository, again something that you need to inject through the constructor.
wrong service.
Comment #21
martin107 commented1) implemented the setEntityFieldManager() suggestion -- after seeing the new implementation I am happy enough that the one in a hundred contrib module affected by this will "feel" guided by core to the correct alteration.
2, 3 fixed.
Comment #23
martin107 commentedOk so just cleaning up unforced errors on my part ... as clear sign I should spent the rest of the weekend doing something relaxing.
It is not reasonable that others fix my mistakes .. so more from me Monday night.
Comment #25
berdirnot entity field manager, entity display repository :)
that's why we shouldn't add a setEntityFieldManager(), there are several new services and each form that used entity manager is likely going to need a different set of replacement services.
Comment #26
martin107 commenteda) #25 -- I have fix up the code in this area. Thanks for the rapid review.
b) The changes made to NodePreviewForm are questionable - I expect to undo them ... but they may be useful for a conversation.
The argument signature of
NodePreviewForm::create()
NodePreviewFrom::constructor()
have changed so what I have done will be a breaking change, as if contrib has done any dependency injection then this will spawn errors.
If contrib has only extended buildFrom() then this would be a inconsequential change.
Alternately what I am trying to say is that following the pattern of :-
leaving a entityManagerInterface as the first parameter and adding
a optional EntityDisplayRepositoryInterface to the end of the constructor with the appropriate trigger warning -
is not going to cut it here as we are just making work for ourself and contrib. In D9 we would have to come back and adjust the signatures to remove the entityManger parameter.
Comment #27
berdirThe format for these messages has changed a few times and is pretty inconsistent but I'd suggest to follow the format that I've used in the last few issues, see for example \Drupal\Core\Entity\Sql\SqlContentEntityStorage::__construct()
Here you correctly still use $this->entityFieldManager, but you removed that now. So that's going to fail. You need to inject both services for it to work.
This should check for $entity_field_manager, not $this->entity_field_manager because that will always be NULL at this point.
looks like you're not yet injecting the new entity_field.manager dependency, so that should result in a deprecation messages.
This is perfectly fine, actually. The trick here is that EntityManagerInterface/$entity_manager also includes EntityDisplayRepositoryInterface, so if someone still passes in $entity_manager, that will not cause any issues, other than triggering some deprecation messages later on when we finally have @trigger_error()'s in all entity manager methods.
This is the same as switching entityManager to entityTypeManager, which we also do in a few places.
$this->entityTypeManager is already set 2 levels up on EntityForm and injected through setEntityTypeManager(), that means you can instead only pass in entity_field.manager as a replacement for entity_manager, like above.
this is most likely unnecessary at this point, but we might not want to change that here.
this one is tricky. same as above, injecting entity type manager here is pointless because it has it already due to being an entity form.
However, we don't need something else here and it is not the last argument, so removing the argument requires some pretty weird trickery.
What you'd need to do is remove the argument and remove the type hint from $temp_store_factory, and if that is actaully not a SharedTEmpStorageFactory that means someone passed in an entity manager and we'd need to do a @trigger_error(). Maybe just leave it like this for now...
Comment #28
andypostBetter use https://www.drupal.org/node/2549139 as CR, working on it
Comment #29
andypostFirst round of clean-up - address #27 1-3
Comment #30
andypostone more fix
Comment #31
martin107 commented@andypost ... thanks I was going to have to wait for the weekend
Comment #32
andypostFix
core/tests/Drupal/KernelTests/Core/Entity/EntityDisplayFormBaseTest.phpFeedback on remains of #27
4.
NodePreviewFormmarked internal so I think it's fine here5. fixed
6. looks out of scope - needs follow-up
7. Removing type-hinting was unliked in other issues so I left it as is
looking through core for (7) I found only bad examples - they use type hint but checking for the same interface
-
core/lib/Drupal/Core/Config/ConfigManager.php-
core/lib/Drupal/Core/Menu/MenuParentFormSelector.php-
core/lib/Drupal/Core/ParamConverter/EntityConverter.phpComment #33
andypostpatch itself
Comment #34
andypostsomehow patch is not attached again
Comment #36
andypostFix last test
Comment #38
andypostFix cs
Comment #39
berdirthe new arguments should use = NULL
same
that looks wrong.
BC here shouldn't be necessary, as not a new argument.
we should be able to remove the setEntityManager line below, one thing less to update then for 9.x
Comment #40
andypostAddressed #39 feedback
Comment #41
martin107 commentedWe are aiming from 8.8.0 now.
Contrib modules are going to get hit with @trigger warnings 6 months later that planned.
Such is the cruelty and glory of the periodic release window... Oh well
Comment #42
berdirAccording to https://drupal.slack.com/archives/C1BMUQ9U6/p1551867778326000 and the reply from @alexpott, we might still be able to get this in with a deprecation message for 8.7, we're only talking about a bunch of constructors here, not a major new deprecation.
But we have no definitive feedback yet from a release manager. Either way, I think it is RTBC, either #40 or #41 can be committed. #40 to 8.7 + 8.8, #41 only to 8.8.
Comment #43
berdirFrom slack https://drupal.slack.com/archives/CDDD98AMN/p1552125380214700:
Comment #44
alexpottCommitted and pushed 2c166a50a6 to 8.8.x and 12af1077e5 to 8.7.x. Thanks!