Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Overview
Within XB, the top bar should display page-specific context, such as the title and publishing status, as shown in the screenshot. This issue focuses on exposing, displaying, and styling the relevant top bar information.
Proposed resolution
This MR will get the publish status and page title from selectPageData selector from pageDataSlice and the hard-coded title and status on the selector to get the values should be removed after #3501847: Send entity keys to the editor from the mount controller is in. Once the information is rendered, styling will be added to align with the design specifications.
https://www.drupal.org/i/3501847
User interface changes
| Comment | File | Size | Author |
|---|---|---|---|
| Screenshot 2024-11-22 at 11.26.09 AM.png | 77.67 KB | kunalkursija |
Issue fork experience_builder-3489106
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:
changes
Comments
Comment #2
kunalkursija commentedComment #3
kunalkursija commentedComment #4
shyam_bhattComment #5
shyam_bhattComment #6
longwaveThe preview endpoint could probably return additional data to achieve this.
Comment #7
wim leersI think it's not the
experience_builder.api.previewroute that should provide that info, butexperience_builder.experience_builderitself? 🤔Because:
experience_builder.experience_builderis requested once, and the information should be retrieved thenexperience_builder.experience_builderis requested N times (once per component placement/props change), and it is completely unaware of the underlying content entity being editedBut perhaps @longwave sees a reason for using
experience_builder.api.previewthat I'm missing? 🤔Comment #8
longwaveIf the user changes the page title inside XB, should it update immediately (ie. on preview)?
Comment #9
lauriiiThe page title should update automatically as it's being changed.
Comment #10
longwaveI guess another question is what should be displayed here: just the entity title/label? Or the HTML
<title>tag from<head>?Comment #11
lauriiiThat's a good question. I think it should be just the entity title/label since that's what we would be using for referring to the page else where.
Comment #12
shyam_bhattComment #13
parthbcharya commentedComment #14
anjali rathodI will be working on the API part of this issue and then my colleague parthbcharya will take over the FE work. I’m unclear about which API to use for my current task in experience_builder. Should I leverage an existing API route, extend one of the current routes, or consider creating a new API from scratch?
I’d appreciate some guidance to understand the best approach for this scenario.
Comment #15
longwaveGiven the discussion in #7-11 I still think the preview endpoint is the best place to add this to the API; if the title is edited then the preview will update and reflect the change.
I suggest adding the title to the JSON response in
XBPreviewRenderer::renderResponse(); it looks like we might be able to capture the title inprepare().Comment #16
anjali rathodComment #18
anjali rathodNeed review for the API related changes made by me, so that @parthbcharya can then continue working with these changes for React code part.
Comment #19
longwaveWhile I agree we want to refactor this in the near future in #3494348: Support additional top-level data in returns from ApiPreviewController I think this is OK for now, but it would be good to add at least two assertions to
ApiPreviewControllerTestto prove that the entity title and status are returned.If #3494348: Support additional top-level data in returns from ApiPreviewController lands first then this will need refactoring to match the changes there.
Comment #20
lauriiiMerged #3494348: Support additional top-level data in returns from ApiPreviewController.
@anjali rathod Could you reimplement the API to utilize the new API? 🙏
Comment #22
larowlanI've pushed a rebase on top of 0.x making use of the new functionality from MR 420 and added a test.
This is ready for the FE implementation now.
I would suggest this goes in its own slice and makes use of onQueryStarted in the preview API to pluck out the values and dispatch the reducer to update the slice
Comment #23
parthbcharya commentedComment #24
balintbrewsLet's create a UI component (or set of UI components) and present them in Storybook. We'll need to display the currently focused global region in #3497648: Focus mode for global regions. Whichever issue gets to implementing a UI component earlier, let's anticipate each others' needs with the component design. 😉
Comment #25
wim leersThanks for explaining the rationale, @anjali rathod — I was thinking about not making this too narrow, and I've now clarified that in the MR comments.
I think that between my response and @balintbrews' at #24, you have all you need here to proceed? 😊
Comment #26
parthbcharya commentedComment #27
longwaveThis appears to be duplicating what is being done in core in #3484600: Show entity information on the Top Bar
Comment #28
lauriiiWhat's being done in #3484600: Show entity information on the Top Bar is for the top bar when visiting the site frontend / current edit form. What we're supposed to be doing here is doing the same but within XB. These need to be sync but it shouldn't be duplicated effort.
Comment #29
lauriiiComment #30
mglamanGoing to help push this through over the finish line
Comment #31
mglaman🫡 ready for reviews
Comment #33
mglamanMR approved! here's my attempt at issue credits, other maintainers fix as needed!
Comment #35
mglamanWoo! We're unblocked to build the in-editor page navigation.
Comment #36
wim leersWow, the merged MR looks nothing like what I reviewed a month ago: no more server-side changes!
Comment #37
hooroomooUpdated issue summary to remove "fetching from API" from the proposed solution, since the solution changed to use the selectPageData selector instead.