Define the 3 areas the Top Bar will provide

Working on the definition of the 3 new areas.

plopesc → changed the visibility of the branch 3484564-define-top-bar-regions to hidden.

plopesc → changed the visibility of the branch 3484564-define-top-bar-regions to active.

Initial round to define the new TopBar render element and the plugin system to define top bar items.

We can iterate from here if the approach is considered valid.

Conceptually I don't see an issue. The fact that it's not editable makes sense.

on the PHP implementation i'm not the best person to comment, just pointing out that the region names feels a bit magic, if we're really tryin to enforce the 3 areas i'd use an enum or something a bit more restrictive (and maybe easier to document).

As it is contrib can add anything fairly easily, and i'm not sure it's a feature or not.

Good point about the enum!

Created and used it as part of TopBar::preRenderTopBar() . Tried to use the enum in the twig template as well, but it was not possible, given that enum support in Twig has been added recently and will not be available until 3.15. Core is now using Twig 3.14.

See https://twig.symfony.com/doc/3.x/functions/enum.html & https://github.com/twigphp/Twig/pull/4352

Regarding the styles, some basic styling is needed. Hopefully a more experienced FE dev could help here.

Let's get some minimal styling going on. just some barebone flexbox layout to replicate the positioning we can see 📌 [PP1] Show entity information on the Top Bar Postponed

This issue has POC with styles required
https://www.drupal.org/project/drupal/issues/3401826 🌱 [PLAN] Top contextual bar Active

Left a (slightly drive-by) review on the MR.

I tried applying the patch today to see what functionality is being added. Unfortunately, The patch is failing to apply.
Navigation.module seems to be having conflicts.

Tried out the MR, This seems to be a solid way of defining the top bar elements. Thanks @plopesc!

I'm not really sure how to apply styles to nothing :)

Could you please add some test cases?

ckrina → closed merge request !10016

ckrina → reopened merge request !10016

@finnsky We only need the very basic styles to define the 3 regions:

• Tools: Aligned to the left
• Context: Centered
• Actions: Aligned to the right

Currently, only Actions has any content, the "More Actions" dropdown in entity pages.

we can add markup for this

I'm not really sure how to apply styles to nothing :)

Could you please add some test cases?

I also see that the local tasks are not rendering with the latest changes. Looks like we need to update the top_bar theme hook to be a render element type and probably do some preprocess.

I'll can work on that, as well as adding some basic styles.

I've addressed the issue that was preventing local tasks from showing up where appropriate. I've also addressed adding some markup to get local tasks over to the right-hand side. There were already some grid styles in place for that. That can probably be further improved in follow-ups.

I'm looking at the failing test ATM.

Test is green. Ready for review.

Applied styles.

All the comments by core committers were addressed and the basic styles implemented, I think this one can be marked as RTBC.

It would be useful if the issue summary could say:

1. What the three top bar items are

2. However they're being defined (quick look at the MR looks like plugins, but then I checked the issue summary and didn't see a mention).

If we're expecting contrib modules to interact with these (I think we are?) then a change record would good too.

I've updated the issue summary per #26.

Will work on a CR as well.

CR written: https://www.drupal.org/node/3489732 →

Removing the relevant tags.

Thanks for the suggestions @catch.

nod_ → closed merge request !10016

nod_ → credited larowlan → .

Committed 3ef3cfe and pushed to 11.1.x. Thanks!

Cherry pick is not clean on 10.5.x, need a MR for it

How will the https://www.drupal.org/project/experience_builder → React-powered UI be able to reuse this "Top Bar"? 🤔

Probably some Microfrontends with common context. Just brainstorming. I don't have lot info about ExB.

https://dev.to/nik-bogachenkov/building-micro-frontends-with-vite-react-...

XB won't use this directly (inside XB). This is simply partially driven by needs from Drupal CMS and XB to bring continuity between the Drupal UI and XB (by making changes to the Drupal UI).

Then yeah. We have tiicket to backport all to sdc