Problem/Motivation
Now #3549266: Move DisplayBuildableInterface to a new plugin type has been merged. We can now simplify DisplayBuildableInterface and related mechanisms as much as possible.
Proposed resolution
1. Rename ::saveSources() by ::publish()
So we are consistent all along the codebase.
2. Remove ::initInstanceIfMissing()
Works in the instance collection page has introduced a new principle: the automatic creation of missing instances entity.
See InstanceListBuilder::filterEntities(). We bet on the fact those entities are very light to be created on the fly.
That means we can remove ::initInstanceIfMissing() calls which are fragile and spread out a bit everywhere.
3. Remove ::getInstanceId()
During the early days of the development, instead of considering Instance entity ID as an opaque string, we have put meaning into it, and we rely on this meaning in DisplayBuildableInterface::checkInstanceId(), ::getDisplayUrlFromInstanceId(), ::getUrlFromInstanceId().
It is not necessary anymore since the introduction of this field in Instance entity:
$fields['buildable'] = BaseFieldDefinition::create('plugin')
->setSetting('plugin_manager_id', 'plugin.manager.display_buildable')
->setRequired(TRUE)
->setReadOnly(TRUE);We can load the buildable directly now. Let's consider this Instance entity ID string opaque, as it must be.
We will only remove ::getInstanceId() here because:
::getPrefix()has be done in #3615031: Enhance instances list for better navigation::checkInstanceId(),::getDisplayUrlFromInstanceId()and::getUrlFromInstanceId()will be done in #3616313: Check static methods on DisplayBuildableInterface
This is also the opportunity to remove an infinite loop between ViewDisplay::getProfile() calling Instance::getProfile() which is calling ViewDisplay::getProfile()....
4. Replace DisplayBuildableInterface::checkAccess() by Drupal\Core\Access\AccessibleInterface::access()
Leverage existing interface instead of creating/existing our own.
Issue fork display_builder-3573905
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
mogtofu33 commentedHas already been done.
Comment #3
mogtofu33 commentedComment #4
pdureau commentedHi Jean,
I was thinking about a bigger change of logic.
At the beginning of the project, things were more losely defined than today:
So, we were relying a lot on guessing the DisplayBuildableInterface implementation of an Instance by analyzing the instance ID string.
I have the feeling we now can start considering the instance ID string as opaque, by:
protected DisplayBuildableInterface::instanceproperty (it is already the case)protected InstanceInterface::buildable(must be added, withEntityWithPluginCollectionInterface)Anyway, I will play safe in my proposal. So if the benefit of such change is not obvious, i will not include in the MR.
Comment #5
pdureau commentedIt is also the opportunity to remove
EntityViewOverride::initInstanceIfMissing()which doesnt seem to do much than the method it overrides.Comment #6
pdureau commentedComment #8
pdureau commentedComment #9
pdureau commentedComment #10
pdureau commentedComment #11
pdureau commentedDisplayBuildableInterface::getInitialContext()andDisplayBuildableInterface::getInitialSources()will already be removed here: #3576918: Specific first log messages according to the data sourceComment #12
pdureau commentedComment #13
pdureau commentedWork has started
Comment #14
pdureau commentedComment #15
pdureau commentedComment #16
pdureau commentedSome work will be done in #3578469: Make instance entities aware of display buildables, lets postpone this one.
Comment #17
mogtofu33 commentedComment #18
pdureau commentedThe MR has been rebased on #3562989: Implements RevisionLogInterface for Instance entity because it is a better starting point for simplifications.
Comment #19
pdureau commentedComment #20
pdureau commented#3562989: Implements RevisionLogInterface for Instance entity has been merged. We can resume.
Comment #21
pdureau commentedAlso in the scope of #3616313: Check static methods on DisplayBuildableInterface, so no need to work on this here.
Comment #22
pdureau commentedLet's implements
AccessibleInterface::access()and call it a day.Comment #23
pdureau commentedComment #24
pdureau commentedComment #25
pdureau commentedComment #26
mogtofu33 commentedI put myself here as it seems a bit stopped to see with #3618945: Tidy Instance methods let me know if it's an issue.
Comment #27
pdureau commentedSure, go fot it.
Here is the current status:
✅ Done
✅ Done, but i initially wanted to do more.
✅ Done
❌ I have reverted it because it was not working as expected.
Comment #28
pdureau commentedFor information, we reached PHPMD class complexity limit for
ViewDisplay&DisplayBuildablePluginBasein an other ticket, so any simplification of buildables would be welcomed.Comment #30
mogtofu33 commentedYour first two commits are on 1.0.x now, merged with #3618945: Tidy Instance methods
The third, folding creation into `getInstance()`, I did not take: it is called from read paths (`calculateDependencies()`, the pinned preview, the Instances panel) and #3617570: Instances list enhancements made those read-only on purpose. A getOrCreateInstance()` used only where a write is wanted would do the same job. Dropping `getInstanceId()` is #3616313: Check static methods on DisplayBuildableInterface.
What's left here is `AccessibleInterface::access()`.
What was not working as expected?
Comment #32
pdureau commentedIt was a bit mysterious. I will rebase this MR so we can focus on this task and check.
Comment #35
pdureau commentedI opened a second MR with a Claude try: https://git.drupalcode.org/project/display_builder/-/merge_requests/384/...
With similar results than the first manual try:
Could it means we have some wrong phpunit tests here?
Comment #36
pdureau commentedSecond Claude try, this time with Opus 5.5, the pipeline are green.
Needs review.
Comment #38
pdureau commentedReview is starting.
Review with 3 different roles
Limitedprofile is a profile created for this tests in order to check the users can't access the default profile.Role 1: with all permissions (but not the administrator)
Permissions:
LimitedDisplay Builder profile (Display Buildermodule): YESDefaultDisplay Builder profile (Display Buildermodule): NOField UImodule): YESViewsmodule): YESDisplay Builder for page layoutmodule): YESNodemodule, to test entity view display overrides): YESPage Layout:
Limitedprofile. Expected: YES. Results: ???Defaultprofile. Expected: NO. Results: ???<Limitedprofile. Expected: YES. Results: ???Defaultprofile. Expected: No. Results: ??Entity view display:
Limitedprofile. Expected: YES. Results: ???Defaultprofile. Expected: NO. Results: ???<Limitedprofile. Expected: YES. Results: ???Defaultprofile. Expected: No. Results: ???Entity view override:
Limitedprofile. Expected: YES. Results: ???Defaultprofile. Expected: NO. Results: ??? tab not visible + HTTP 403Limitedprofile. Expected: YES. Results: ???Defaultprofile. Expected: No. Results: ???Views:
Limitedprofile. Expected: YES. Results: ???Defaultprofile. Expected: NO. Results: ???Limitedprofile. Expected: YES. Results: ???Defaultprofile. Expected: NO. Results: ???Role 2: has the "classic" permissions of Drupal display building, but not the ones from Display Builder
Permissions:
LimitedDisplay Builder profile (Display Buildermodule): NODefaultDisplay Builder profile (Display Buildermodule): NOField UImodule): YESViewsmodule): YESDisplay Builderfor page layout module): YESNodemodule, to test entity view display overrides): YESPage Layout:
Entity view display:
Entity view override:
Views:
Role 3: has the Display Builder permissions, but not the ones from classic Drupal display building
Permissions:
LimitedDisplay Builder profile (Display Buildermodule): YESDefaultDisplay Builder profile (Display Buildermodule): NOField UImodule): NOViewsmodule): NODisplay Builderfor page layout module): NONodemodule, to test entity view display overrides): NOPage Layout:
Entity view display:
Entity view override:
Views: