Overview
The first thing in \Drupal\experience_builder\Storage\ComponentTreeLoader::getXbFieldName() is a LogicException that is thrown if you try to use XB on anything except an article node.
This is not going to work for Drupal CMS. Although we do not need any ability to use XB to edit individual nodes right now -- nor do we need the ability to edit content templates in the UI -- we do need the ability to render any entity type through an existing content template (which will we hand-craft). The LogicException is a brick wall preventing that.
This blocks site templates, and therefore the full adoption of XB by Drupal CMS 2.x.
Proposed resolution
Fully remove the exception.
User interface changes
None.
Issue fork experience_builder-3539108
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 #3
phenaproximaComment #4
phenaproximaAlternative approach: if we don't want to remove the exception outright, another option that will work for us is to remove this from
ContentTemplateAwareViewBuilder:This would mean we don't care if any entity is "opted into" XB or not -- only that a template exists. However, we'd certainly want to restore this logic, or equivalent logic, at a later time.
Comment #6
isholgueras commentedThe only difference that this MR brings is the exception logged in the database and is step forward. We would have to delete this code sooner or later, so I'm OK with this.
About #4, I think it's better to leave the code as is. IMO, that would be, or kind of, the final code.
I've fixed one phpunit test and all should be green now.
Comment #7
isholgueras commentedComment #8
wim leersAs of https://git.drupalcode.org/project/experience_builder/-/commit/843e7b0b1...,
ContentTemplates are only allowed fornodecontent entities, as proposed by @effulgentsia as a realistically achievable goal for 1.0. @lauriii and I both +1'd this proposal, and made it so.That did not implement all of #3518272: Support all entity types with configurable displays for content templates, but allowed us to make it no longer stable-blocking.
(Fun fact: you created #3518272, @phenaproxima! :D)
Comment #9
wim leers+1 to removing this exception.
But let's convert rather than delete existing test coverage to expect the fallback exception? i.e. this one:
I might be missing something obvious, but I don't understand why we wouldn't keep that.
Ah … I guess that is what #4 is implicitly referring to — I think removing that
catch(and the other one in the same file) is the right thing to do.Comment #10
phenaproximaComment #11
wim leersThanks — looks great now! 👍
Comment #13
wim leers