[PP1] Show entity information on the Top Bar

Removing Postponed status as 📌 Define the 3 areas the Top Bar will provide Active is merged to 11.x.

Adding the "Drupal CMS release target" to see if we could hopefully get to it.

Also adding Navigation stable blocker

Appears to have pipeline issues

Even though it's marked as a task think having simple test coverage to verify that the information appears would be good.
Left some small comments on the MR.

Appears to have pipeline errors.

Have not reviewed

Small nitpicky change, didn't resolve any of the threads yet would feel better if the original posters did that.

Thank you. I added comment about nesting. Please check and compare with existing CSS of module.

I have an hour right now, going to see what I can do to address open threads.

Read the code and added a couple of comments. I think we need to have a more detailed issue description to decide the actual scope of this one.

We just discussed this issue on Slack with @lauriii and @plopesc, and agreed on the following direction about the Title shown:

• If it’s an entity, Top Bar should show the entity’s Title
• If it’s a view, it should show the views's title. But only on the front-end because it needs an edit button (not on the admin People page for example)

I'd try to unblock this issue as much as we can trying to get the title right and then open follow-ups for improvements for the other info like the ones @berdir was suggesting. Since this is still experimental, that can be refactored an improved afterwards.

> If it’s a view, it should show the views's title. But only on the front-end because it needs an edit button (not on the admin People page for example)

This already sounds like a non-trivial special case. views pages are not canonical entity pages, we'd need to hardcode frontend/backend logic. edit button is also a separate issue and depends on local tasks, views pages don't have local task for editing at the moment, so that would also require custom views specific logic there.

My suggestion would be to just focus on regular entity routes here.

I guess one question is whether canonical pages and edit/delete pages should both just show the title or something else. I feel like Edit %title would duplicate the page title, the screenshot in https://git.drupalcode.org/project/drupal/-/merge_requests/10417#note_43... shows that perfectly. Is that really useful? The same can be said about the frontend, but on the frontend, the title is usuallly further away and not always obvious, depending on the design (hero elements, hidden titles, ...

> This already sounds like a non-trivial special case.
> My suggestion would be to just focus on regular entity routes here.

If that's going to be complicated, agreed that spinning off another issue is a better approach instead of trying to solve all the things here.

> I guess one question is whether canonical pages and edit/delete pages should both just show the title or something else.

We are now adding helpful info into the Title itself, like prepending the "Edit" to the entity Title. In an ideal world this contextual / extra info should be communicated with UI elements instead of keep pushing things into the only places we had available years back. So this "you are editing" context could be communicated with visual elements assigning to them the appropriate visual relevance. I'd recommend solving as much as we can with new UI elements, even if we have to come up with them. I've created 📌 Evaluate if the Top Bar entity title needs to show extra Active to work on that on a follow-up.

Read all the feedback above and some related Slack conversations, trying to get a simple approach that could be used as base for further improvements in the future.

New iteration on this one including:

• New service to detect the current entity. Part of Navigation for now, but it could be moved to core in the future. See discussion in https://drupal.slack.com/archives/C079NQPQUEN/p1736417720388089
• Use the service mentioned above to detect the current entity from route
• Show the entity label instead of the page title in the Page Context Top Bar Item
• Modify the return type for the getStatus() method

Tried to work on the Content Moderation integration, but I was not sure how to integrate the ModerationInformation service in a clean way, since Navigation is still Experimental and we should not interfere with other module's code.

Please review the approach and let's decide what else should be part of this issue and the bits that could be moved to new follow-ups

I've been thinking about this, and one possibility to make the PageContext output easier to customize is to have it return a render array with a specific theme function or even a new render element instead of a generic render array. This approach would allow content_moderation or any other third-party module to implement a preprocess hook or similar mechanism to modify the original output. Alternatively, we could explore other options to achieve similar flexibility.

I agree that we need to figure out a way to integrate content moderation with this. However, it would be great to punt as much of that to future as we can so that we can continue to make rapid progress. The key challenge I'm seeing that's preventing us from committing to the UX as it exists today is that the information displayed in the top bar in the case of content moderation could be outright inaccurate. What I propose to address that is to provide three states instead of the current two states; Published, Unpublished, Changed. Changed is a state we would use when the page has been published but there's a forward revision for the entity. This way it becomes clear that what the user is seeing, is not actually what is visible in the published site.

Like I said, none of this means we shouldn't integrate content moderation with the top bar, it just means that we can ship something that works even for the content moderation use case, and allows us to properly design what that API for overriding this should look like.

We should check whether the current logic works with taxonomy/term/n pages which are overridden by views by default. I have a feeling that it won't because of ✨ Upcast named arguments/named parameters in views Needs work , but also that it might just start working once that issue is fixed. Either way not commit blocking here but good to verify what happens and maybe open a follow-up to track it.

Changed is a state we would use when the page has been published but there's a forward revision for the entity. This way it becomes clear that what the user is seeing, is not actually what is visible in the published site.

I might be missing something, but I'm not sure this is a problem with content_moderation as such.

Wouldn't this only happen if the user is reviewing the actual revision page? Other entity pages should only show the default revision anyway so it will either be published or not, and it'll accurately reflect what they see.

Showing the workflow state is different - that also applies to unpublished entities in a draft state, even if they're also the default revision. So it's about something more granular than 'unpublished' then. On the edit form, they'll see the draft, but that's shown clearly on the edit form.

Workspaces will behave differently but we already have the workspace indicator, so users theoretically should already have an indication they're seeing things as they are in the workspace.

If the user is viewing the actual revision page, then they ought to know they're on it, although it could still be confusing if there's a mis-match.

If the above is right, I think we could special case the 'revision' entity link route (either here or in a follow-up), and then handle customisation in a further issue? But it doesn't seem like an issue with forward revisions specifically to me but more workflow state indication regardless of whether dealing with a forward revision or not.

Agreed #27. I somehow thought that the latest revision tab was default but that's most definitely not the case. Based on that, the two states are fine and we can build the content moderation integration to this in a follow-up.

📌 Provide a Workflow FieldType that references a workflow entity and tracks the current state of an entity Needs work might help with the content moderation follow-up (or a follow-up after both of those issues land).

FWIW, I'm perfectly OK if we completely ignore Content Moderation (and Workspaces) here. The implementation is fairly well abstracted and we can easily do a follow up and start with some basic module exists checks to get the content moderation state.

> in the top bar in the case of content moderation could be outright inaccurate.

I think it's not that bad. It's a bit confusing when it's a pending draft, as it would show Unpublished then. But if you use workspaces, it gets more complicated anyway. It can be published in a non-live workspace and what not.

Also might be useful to look at https://www.drupal.org/project/moderation_sidebar → for some inspiration. It displays the current Moderation state (Draft / Published / Archived) usually and if you're on the published page and there is a pending draft, it says "Draft available". published states are green, non-published is red, an available draft is yellow. a pending draft is also red, I suppose that could be a different color.

Made a minor refactor of the tests to save a few seconds there merging the 2 methods into one.

> We should check whether the current logic works with taxonomy/term/n pages which are overridden by views by default.

Tested locally and it worked for taxonomy pages as well. I had doubts, but I can confirm it both in Vanilla Umami and Standard profile at least.

From comments #27 & #30, I think we are OK for now regarding the Status part of the Top Bar Item and we can discuss the approach for 3rd party integrations in a follow-up.

Some CSS adjustments seem to be made before having it ready for final review, though.

Thank you all for your thoughts and collaboration here.

gonna work on it.

A few notes:

It shouldn't be a list because it's not a list.

It also breaks the output in some themes (Claro) because the item list has its own styles https://gyazo.com/4667c856e63d3d4b3459b2ab0c43b264

We should keep in mind that everything we create should (and will) be reused in the further development of the module. When we make forms and the second sidebar, for example.

And these two components: title and badge are key elements of any design system. Therefore, it is obvious to me that they have no place in the depths of the nested CSS

I remade it as I see the further development of the module components.

Result:
https://gyazo.com/cda07be66460fdec1d06fb635e99f0e2

Several fixes are needed in the tests and possibly the render array.
Please review

Thank you for jumping into this one.
Code looks simpler and clean.

My only concern is that usage of SDC directly from the render array is whether it would make the integration with 3rd party modules more complex in the future.

I'm not an SDC expert and I might be missing some bits here.

I made some updates to the design:

1. Use the database icon instead of page icon since which will be used for most entity types other than the Page entity type introduced by Experience Builder.
2. Adjust the grid implementation to ensure that the context region is centered on all viewport sizes.
3. Minor tweaks to the vertical positioning of the elements.

I think the MR is starting to look pretty good. We'll have to do some additional work to make the top bar a bit more flexible to meet the needs that other modules like content moderation have. It seems fine to leave this to another issue since this issue is taking a big step forward already.

We have 📌 Evaluate if the Top Bar entity title needs to show extra Active as a follow-up, but I think that's more about how different pages such as edit/delete should behave, I think it would be good to have a follow-up how this should be integrated with content moderation/workspaces. I plan to have a look into that myself and will create an issue when I get around to it, but maybe someone could already create it?

an updated screenshot how it now looks compared to the design might be helpful for reviewers? Not sure if a change record is useful?

I filed ✨ Display content moderation state in the Navigation Top Bar Active for the follow-up. Also added a screenshot to the issue summary.

I don't think we need CR for this issue specifically. We may want to create CR after we've figured out how to optimize this for content moderation.

Committed 54c4637 and pushed to 11.x. Thanks!

doesn't cherry pick to 11.1.x but i think that's fine, module is hidden anyway.

nod_ → closed merge request !10417

Thank you @nod_! 🙌 Next step is 📌 [PP1] Move the Edit buttonoutside the more actions drop down Postponed .

Great stuff! Has this a chance of being backported? (Sorry i did not find the criteria but saw that other navigation top bar stuff is.)

per thread on slack we're not backporting the top bar work to 10.x, closing this one

Automatically closed - issue fixed for 2 weeks with no activity.