Original summary
The Drupal\layout_builder\Entity\LayoutBuilderEntityViewDisplay class does not correspond to an entity type.
Purpose:
1. To fix the custom field weight on the bottom of the page that is in the field manage page at 'admin/structure/types/manage/page/fields'
Sometimes, use add some custom fields at above page, some string fields, some table fields, and so on. Then we want to order the big fields on the bottom of page and the light weight fields like string fields on the top of page in the view page.
Then, I would like to add a alter method, as below; override some function in the base class.
reproduce steps:
1. Add a hook in module, as below:
2. drush en any other module.
/**
* Implements hook_entity_type_alter().
*/
function custom_module_entity_type_alter(array &$entity_types) {
/** @var \Drupal\Core\Entity\EntityTypeInterface[] $entity_types */
if (\Drupal::moduleHandler()->moduleExists('layout_builder')) {
$entity_types['entity_view_display']
->setClass(\Drupal\custom_module\LayoutBuilderEntityViewDisplay::class);
}
else {
$entity_types['entity_view_display']
->setClass(\Drupal\custom_module\Entity\Entity\EntityViewDisplay;::class);
}
}
This `LayoutBuilderEntityViewDisplay` is override init function.
And then refresh the page, the page will broken a debug message like the title.
Current summary
If an entity class is overridden by multiple modules, then static call of intermediary overriding class will raise error as not possible to find matching entity type.
Example with entity_view_display overridden by Layout Builder LayoutBuilderEntityViewDisplay then overridden by another contrib or custom module.
In layout_builder.install, the following code will raise an error:
function layout_builder_install(): void {
...
$displays = LayoutBuilderEntityViewDisplay::loadMultiple();
...
Proposed resolution
The entity type should be aware of all intermediary class overrides.
| Comment | File | Size | Author |
|---|
Issue fork drupal-3127026
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
Comment #2
john.nie commentedComment #3
tim.plunkettIt does when layout_builder_entity_type_alter() runs correctly. Which should be before hook_install(), if I remember correctly.
This needs clear steps to reproduce the bug. We have test coverage for this code, and it's been in core since before LB was stable, so it works for a majority of cases.
Comment #4
john.nie commentedComment #5
tim.plunkettBut why would you have that code? There is no such class as
Drupal\node\LayoutBuilderEntityViewDisplay.And LB already has it's own entity_type code to change this.
And even if you were trying to change things in the
ifblock, theelseblock makes no sense to me.Comment #6
john.nie commentedComment #7
tim.plunkettKeeping the issue summary up-to-date is good, but does not replace the value of writing an actual comment to answer the questions I'm asking.
But from parsing the revision history of the IS, it seems like you are trying to alter the Field UI, and the LB override is getting in the way?
Comment #8
john.nie commentedyes,
Comment #9
john.nie commentedThe custom module redefined
Class, So the default class not works.
Comment #10
john.nie commentedComment #11
tim.plunkettThanks for the steps to reproduce!
\Drupal\Core\Entity\EntityTypeInterface::getOriginalClass()and all the code that uses it only tracks the original class, not the decorated class. So decoration only works one level deep. This is an unfortunate bug, and wouldn't be easy to fix at the entity type level.Comment #13
tim.plunkettNW for tests
Comment #15
nikhil_drupal commentedIs this issue resolved, i'm facing same issue when installing the module. any help would appreciated. i tried the above patches none were working my drupal version is 8.9.7
Comment #16
slayer722 commentedHello,
I have the same error message with Drupal 9.1.4 on one of my websites after LB install.
The last patch (#11) solved the error message but I cannot use LB with Display Suite installed on the same time.
It seems that this issue is related to DS because if I uninstall it before, no problem nor error message.
But I don't understand the reason and why it is not committed.
Regards
Comment #17
tim.plunkettPer #11, it needs test coverage.
Comment #18
mohit_aghera commentedComment #19
mohit_aghera commented@tim.plunkett I've added a simple test cases to install a new module after custom module that is overriding layout is installed.
Is it sufficient enough for the use case?
Comment #21
mohit_aghera commentedComment #24
edmargomes commentedDoesn't work for me.
Show this error: Error: Call to undefined method Drupal\Core\Entity\Entity\EntityViewDisplay::enableLayoutBuilder() in layout_builder_install() (line 27 of core/modules/layout_builder/layout_builder.install).
enableLayoutBuilder is only in LayoutBuilderEntityViewDisplay
Comment #25
edmargomes commentedComment #30
grimreaperEncountered the same problem in #3529127: Play nice with layout builder
Will create a MR from last patch. and use entity type manager service.
Comment #32
grimreaperComment #33
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #34
grimreaperComment #35
grimreaperMR updated.
Code quality done, Tests improved.
Review comments addressed.
Unrelated nightwatch failure, I retriggered the job.
Comment #36
christian.wiedemann commentedComment #37
christian.wiedemann commentedI tested the layout_builder installation process. Works as expected.
Comment #38
pdureau commentedComment #39
tim.plunkettCopying from a Slack conversation today:
I pointed this out 5 years ago, at the same time as proposing the workaround. #11
If the core committers would like to include this workaround, that's fine, but a major follow-up should be opened for the underlying bug.
Comment #40
heddnI'm not sure how this would be resolved any other way than fixing the hook_install for layout_builder to use the entityTypeManager service to get the storage. What is #11 and #39 suggesting we should do instead?
Comment #41
heddnAlso, something got triggered recently because there's a lot more traffic on this issue. Anecdotally, layout_builder_st depends on layout builder has all of its functional tests falling over because it override the the view display class and this breaks all of its installs. I don't recall this happening even yesterday.
Comment #42
heddnTagging as a contrib blocker.
Comment #43
danielvezaDid a code review of this earlier, and the feedback has been addressed. I think if this is a contrib blocker it's worth committing this in it's current state, however I do think we should open an issue based on #39 to explore the underlying code around this and see if there is any generic improvements we can make.
Comment #45
grimreaperIs the long term solution will be something like in the other MR I created for POC?: https://git.drupalcode.org/project/drupal/-/merge_requests/12799/diffs?c...
Comment #46
tim.plunkett#44 is exactly what I was looking for, thank you @grimreaper!
This speaks directly to the bug we're experiencing here, and retains the tests from the previous MR.
Comment #48
heddnI've been testing with the patch here from MR 12799 and did a code review as well of said MR. I think this does a better job than the previous approach. Contrib module testing can confirm the root issue is gone now. LGTM.
Comment #49
tim.plunkett+1 for RTBC, thanks @pdureau and @heddn for being patient with my pushback, and @grimreaper for making it happen.
Comment #50
grimreaperHi,
Thanks to have pushed the MR forward! And glad to have helped!
+1 for RTBC too, I have retested on my contrib project, working fine too!
Comment #51
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #53
dcam commentedI fixed the PHPStan failure that caused the bot to complain. It was a minor change from
@coversto@legacy-covers, so I'm restoring the RTBC status.Comment #54
kmontyComment #55
grimreaperLast commit is ok, back to RTBC.
Comment #56
anybodyAny chance to merge this into core soon, as this is RTBC and still blocking #3431600: Automated Drupal 11 compatibility fixes for layout_builder_st for example and therefore block Drupal 11 upgrades for many users. Would be great to have this fixed.
Thank you all!
Comment #57
mondrakeNits added inline to the MR.
Comment #58
kmontyComment #59
grimreaperRebasing and taking review into account.
Comment #60
grimreaperMR rebased and last review taken into account, back to needs review.
Comment #61
mondrakeBack to RTBC, thanks for taking care of my nits
Comment #62
catchI was expecting to see only layout_builder changes, but this is quite a low level change to the entity API - could we get an issue summary update? Also seems like it might need a change record.
Comment #63
grimreaperProposed new title:
Different modules can't override the same entity type class
Proposed summary:
If an entity class is overridden by multiple modules, then static call of intermediary overriding class will raise error as not possible to find matching entity type.
Example with entity_view_display overridden by Layout Builder LayoutBuilderEntityViewDisplay then overridden by another contrib or custom module.
In layout_builder.install, the following code will raise an error:
Proposed resolution
The entity type should be aware of all intermediary class overrides.
Comment #64
grimreaperUpdating issue title and summary.
Back to RTBC.
Comment #65
dcam commentedThe MR for this issue was identified as having a new Kernel/Functional test class that did not have the
#[RunTestsInSeparateProcesses]attribute. A deprecation warning is now issued in the case of these omissions. I've rebased the MR added the attribute to prevent this from being committed as-is and accidentally breaking tests on HEAD. Because this is a minor change to test metadata and the tests are passing I am leaving the issue's status as RTBC.Comment #66
pdureau commentedThat's great we are that close to 11.3 merge ;)
Comment #67
larowlanLeft some comments on the MR
Fine to self RTBC after updating/replying
Comment #68
grimreaperComment #69
grimreaperHello,
Last code review taken into account.
Per comment 67, back to RTBC.
Comment #70
alexpottAdded a comment to MR. We need a follow-up to replace \Drupal\Core\Entity\EntityType::getOriginalClass()
Comment #71
alexpottWe should also add a change record to detail what is changed here and what is now supported.
Comment #72
grimreaperComment #73
grimreaperFollow up created: #3557461: Deprecate EntityTypeInterface::getOriginalClass
Draft change record created: https://www.drupal.org/node/3557464
TODO: finish updating tests.
Comment #74
grimreaperHi,
All latest code review comments had been addressed.
Thanks for the new review round!
Comment #76
smustgrave commentedHiding old patches
Rebased the MR as it was about 190 commits back and it's still all green
Test coverage can be found here https://git.drupalcode.org/issue/drupal-3127026/-/jobs/7617730
Looking at the CR I'm going on the assumption this can still land in 11.3 but if not that will have to be bumped to 11.4
Rest of the feedback here appears to be addressed.
Comment #77
alexpottCommitted and pushed 22134b6d23d to 11.x and 47aac11708d to 11.3.x. Thanks!
Backported to 11.3.x as a release priority and a non trivial bug caused by modules overlapping.
Comment #82
heddnAny chance of this bug fix going back to 11.2 as well? 11.2 is still supported and is the active branch for executing testing. Causing https://www.drupal.org/project/layout_builder_st/issues/3431600 to still fail.