🇨🇭Switzerland @saschaeggi

jurgenhaas → credited saschaeggi → .

xjm → credited saschaeggi → .

Note that the navigation module does not set sticky so we kept the fixed state

saschaeggi → made their first commit to this issue’s fork.

You can opt-out for those pages, see https://git.drupalcode.org/project/gin/-/blob/5.0.x/gin.api.php?ref_type...

Cheers!

Thanks!

Thanks!

@jurgenhaas sounds like a plan

Closing this as duplicate of 📌 Update vulnerable package Active

The main issue is that without Gin Toolbar, the navigation loses the Gin styling on front-end pages, so it gets the Claro styling instead.

That's a limitation of Drupal we can't overcome in contrib

@poker10

Navigation itself currently does not support horizontal menu, only vertical, which may be quite restrictive, given the original core's Toolbar module offers both options

Navigation will soon be the default in core and toolbar will get deprecated and eventually removed. So the path forward is the vertical navigation

t seems like the decision may affect Gin toolbar module, which is used on 60k+ sites and offers horizontal and vertical menu. If removed, it will cause upgrade issues for sites which are currently using it. Is there any plan to keep/or add back the possibility to have also the horizontally oriented menu in such case?

Until toolbar gets eventually removed from core we'll at least support the regular toolbar options but will remove our additional own custom implementations around toolbar (vertical, our own test navigation implementation etc. to reduce variants and make it easier to maintain)

smustgrave → credited saschaeggi → .

Hey Marc

Thanks for putting this together. Unfortunately we'll not develop the feature any further in Gin as it has since been moved to Core as an experimental module! We'll soon remove our experimental implementation. You can already use Core's version by enabling the navigation module.

Feel free to test out Core's implementation and directly provide feedback towards the Core issue queue.

Cheers!

Hey smustgrave 👋

I've added you as a maintainer. Feel free to do a 2.0 release!

Thank you 🎉

Looks like you haven't set Gin as the (default) admin theme

Maybe try to follow the steps in https://www.drupal.org/docs/contributed-themes/gin-admin-theme/installat... →

if it doesn't work try to simply uninstall and install it again (maybe the hooks haven't been run)

Cheers

I can't reproduce this on a fresh install. Please provide the steps how you installed the theme and what Drupal version you're on.

Like I mentioned above it needs to be fixed in Module builder, if you click on the link it will lead you to the line you'll need to change.

I'm moving this back to module builder

I also provided you a codepen above

You're presumably doing something weird with CSS which is breaking things.

Nice accusation, thank you.

> gin-table-scroll-wrapper gin-horizontal-scroll-shadow syncsc

Without looking too deep into Module builders code , If you change this line to fixed, would it work? (There might be additional changes needed, too like setting top when changed to fixed)

https://git.drupalcode.org/project/module_builder/-/blob/4.0.x/css/compo...

See example: https://codepen.io/saschaeggi/pen/RNNdrro

I hope this helps

I've seen the screenshots that it works in Claro. I'd still want the Module builder team first having a look if they can fix it on their end as we're hesitant to add any further custom code for modules at this point to Gin. We'll actually deprecate a lot of the custom module code in Gin soon and will push for the modules to directly include the code as it's not really maintainable on our end.

So I'm moving this once more so the Module builder team can have a look at this 😊

bump

Thanks for reporting Joachim, I'm moving this one to the Module builder issue queue instead

Hey @kirillsolo

Thanks for your interest in Gin! There are actually efforts underway to create a new design system based on Gin actually.

Consult https://www.figma.com/design/IQNqQnxkUiFjp5GSp9E3nV/Design-System---Drup... to learn how you can get onboarded. You can also ping @ckrina in the Drupal slack.

Thanks again & cheers!

bump

I'm closing this as the admin theme is not responsible for the site building experience and that's not something we can change. You can change the type of the description field when you build your site.

Please consider to migrate to the Core navigation now that it has been shipped with recent Drupal core.

We'll soon deprecate and remove our test integration.

Cheers!

The dropdown in Core and used in Gin is a native select element. This looks like a chosen or select2 dropdown. Please open an issue in the module issue queue instead.

That could be, we generally do not officially support sub theming.

I'm closing this as there wasn't any recent activity.

Closing as this would need to be implemented in core after all.

Closing as there was no recent activity.

I'm closing this as there was no activity and it seems like it was a core issue.

bump

I'm closing this in favor of the new core navigation which will have a top bar region which is full width.

For other options, please take a look at our docs https://www.drupal.org/docs/contributed-themes/gin-admin-theme/custom-th... →

Updating message to reflect the changes where we lost both our Gold sponsors in recent weeks

Thanks for confirming! Feel free to RTBC the other MR

Also if I'm allowed to provide a small UX feedback here: A single primary button (use secondary for the other actions) will enhance the UX for users in your example as it adds guidance on what the main action should be (assuming it's Save)

Hey @defcon0

Is this any different from ✨ Allow the visible actions allowlist to be altered Active ? Can we close this out as a duplicate?

The gin-custom can only be used when Gin is set as admin theme, that's by design as Gin serves the logic for the gin-custom.css file.

I'm closing this as works as designed.

Cheers!

jurgenhaas → credited saschaeggi → .

The use of $this still needs to be checked here

I'm closing this one as it hasn't been worked on since 2022.

I think an issue already exists in the Core issue queue. Note that the navigation got included in the meantime into Core so all requirements regarding the new navigation should be placed in Core instead. We'll soon deprecate our "test" integration in Gin.

You can enable Core's experimental navigation module instead

PS: The change here is also included in 4.0.x

Cheers!

If you relate to our Navigation test integration in Gin – unfortunately you can't. We'll soon retire this implementation in favor of the now included navigation module into Core. We included this in Gin to test things until they land in Core – which is now included as an experimental module. Enabling Core's navigation module is highly recommended in your case. With this you'll be able to change the navigation using Layout builder 🎉

Cheers!

Hey thanks for your request. I'm closing this as works as designed. You can provide this feedback to the Core navigation. We're not integrating any new features into Gin regarding the navigation as this will be part of Core.

For the meantime you might want to take a look at the theme customization features Gin offers out of the box to tailor this to your needs: https://www.drupal.org/docs/contributed-themes/gin-admin-theme/custom-th... →

Cheers!

Gin toolbar is a hard requirement for Gin and can't be removed as it's a theme (module) dependency. You can deinstall it though Gin will lack some features. It polyfills lots of functionalities which only a module can do as themes have certain restrictions. It's use is way beyond toolbar nowadays (even though it started as just for that one purpose) and will also serve for the new navigation.

Cheers!

@m4olivei thanks for putting this together 👏

This is a promising start! As far as I can tell this currently would break Gin for all Drupal versions Core < 11.2

We might want to keep the icons as-is as legacy to avoid breaking Gin. This can either be done

• Move CSS styles to the legacy CSS folder and ship it only for Core < 11.2
• We keep it as-is and ship the gin.icons.yml alongside the current method

Hey @Jürgen 👋

Can you take a look here?

You'll need to install navigation and navigation_top_bar

Thanks for opening this

Let me know if anything else is needed to get this over the finish line 🤝

Bump

Thanks, included in 4.0.6 release! 🖖

saschaeggi → created an issue. See original summary → .

@Jürgen @Scott I've added you both as maintainers to gin_permissions

Bump as it's still very much relevant

I'd suggest to report this to Droopler then! :)

I've just tested this using the latest Drupal 10 and 11 releases and can't reproduce this. Make sure the blocks are set. Maybe try reinstalling Gin to see if that fixes the issue (this will recreate the needed blocks).

I hope this helps, Cheers!

I move this back to needs work as the phpunit tests are failing, see https://git.drupalcode.org/issue/gin-3508553/-/jobs/4490177

I don't think $this-> will work in this context

Thi is by design, content should be active on any node as this is considered content.

I'm closing this one as works as designed.

Cheers!

@phenaproxima I think we have different ideas in mind here.

I want to keep PB styling aroudn for pre 2.0.0-alpha10 versions, that's what MR !588 is doing. If 2.0.0-alpha10 or greater Gin will not ship any PB relevant styling at all. We're just ensuring we'll not break the experience for users which are still on an older PB version here.

No worries, I'll close this for now then

Cheers!

Are there any JS errors on that page? It looks very much broken to me.

Not sure which module this is, but maybe best to first open an issue in the respective module issue queue instead?

Please see https://git.drupalcode.org/project/gin/-/merge_requests/588 in Gin 📌 Remove Project Browser-specific styling Active

@acbramley not needed anymore as we have refactored this so it works with the regular submitForm again provided by Core.

I'm closing this as duplicate of ✨ Integrate Gin with the new Navitaion Top Bar Active as the integration is still pending.

Cheers!

I'm working on it.

So far I've pushed the basic support for the new regions in the top bar and to disable the toolbar when navigation top bar is active.

saschaeggi → made their first commit to this issue’s fork.

Hey @phenaproxima

Like we discussed on Slack, this is where I would land, see https://git.drupalcode.org/project/gin/-/merge_requests/588

saschaeggi → made their first commit to this issue’s fork.

I'm closing this again, like mentioned above. Please install the new core navigation instead. We'll deprecate our own integration very soon.

I'm closing this as we won't further develop the test integration of the core navigation. This has moved into Drupal Core. It the problem is with the core navigation feel free to directly open an issue in Drupal Core.

This module is not being actively developed. It was created as an outcome of my ideas proposal https://www.drupal.org/project/ideas/issues/3244581 🌱 Enhance user experience with customizable dashboards Active which then led to the creation of https://www.drupal.org/project/dashboard →

I think we can close this issue for now as "outdated" as the successor is the Dashboard module which gets actively worked on and is part of Drupal CMS. There are also other modules which came out of this initial idea, like https://www.drupal.org/project/dashboards →

Cheers y'all!

Released 4.0.5 -> https://www.drupal.org/project/gin/releases/4.0.5 →

Thanks for working on this! I left a question and a minor code suggestion

Seems we haven't cherry-picked the commit, my bad 😅

Can you check if it's fixed on 4.0.x-dev?

If so I'll quickly do a 4.0.5 release

Thanks!

Gin's styles are scoped for the modal while Claro's aren't that's true.

Like i mentioned above

If you think we should make this optional in the future, we can open a new issue to track it's development to provide maybe a setting for it.

We can create a follow-up to either (or both):
a) remove the need for Claro's styles and embed them into Gin so everything we provide for the modal is scoped.

b) Add a setting to enable/disable the libraries being exposed in the first place

Like I mentioned I'm completely not against this, but I know there are use cases (and thus we've added it) to have them exposed.

With the given solutions above we should be able to make it work in all situations

Feel free to open a follow-up!

Have a nice weekend

Included in the 4.0.4 release: https://www.drupal.org/project/gin/releases/4.0.4 →

Included in the 4.0.4 release: https://www.drupal.org/project/gin/releases/4.0.4 →

Included in the 4.0.4 release: https://www.drupal.org/project/gin/releases/4.0.4 →

When is the toolbar interacting with media library? Why is it needed?

The toolbar module ist just called "toolbar" as it was originally named this way. It's functionality has grown over time quite a bit and it does provide all the things which are not possible to handle within an (admin) theme (to get past limitations).

This one depends on your use case and could be made optional in the future for sure. If you use Drupal's frontend editing tools this is needed to style for example the modal itself and it's contents under the umbrella of the admin theme as you'll get it unstyled otherwise (unless you include styles for this in your frontend of course). This is a longstanding issue in Drupal (Core) as admin themes can't declare anything outside of it's own context (/admin) and that we can't differ admin tools from frontend tools. Again this really depends on your use case, if this should be part of the admin experience or not.

I hope this helps ☺️

I'm closing this as works as designed for now. If you think we should make this optional in the future, we can open a new issue to track it's development to provide maybe a setting for it.

Cheers!

Thanks for working on this, I've pushed some more fixes and made some slight adjustments but overall it looked great 👏🤝

Thanks for the changes Vasantha 👏

Thanks everyone!

Same happening to me on a site with Drupal 10.4.2

Error appears on any route even not related to Project browser

@timplunkett suggested the problem happened when admin_toolbar_tools module is installed. Once I uninstalled that module I was able to update to project_browser-2.2.0-alpha8

This issue will probably surface on every Gin install if that's the case

Glad to see this fixed, thank you! 🥳👏🤝

I'm not sure about the best path but as CiviCRM places an option to override the admin theme specifically for CiviCRM maybe you can first reach out to CiviCRM if they actually can handle it? This might be the best solution in my opinion.

As a temporary solution you could place your CSS overrides in https://www.drupal.org/docs/contributed-themes/gin-admin-theme/custom-th... → or create a small helper module and override the secondary toolbar template on the given path you mentioned

@rkoller thank you for putting this together 👏

It will take a while to get through them so I appreciate you added a meta as well 🤝

Hey @sandip thank you for working on this.

This currently only addresses the throbbers but this might need to be extended to transition properties as well?

@rkoller @mgifford maybe can provide some guidance here

Thanks!

I'm relying on Jürgen's expertise here, but if we can move complexity out of Gin or avoid adding it by adding it to a helper module I'm usually very happy as Gin is already quite complex on it's own. My 5 cent:

I guess, it felt necessary because a them can't provide permissions?

100%, themes can't declare permissions. So a helper module is needed

If that's the case, I'd rather put that into gin_toolbar as it is already a hard dependency for Gin and we could rely on it to be present.

That is currently the case, but once navigation is stable and takes over and we deprecate toolbar we have to evaluate the need for gin_toolbar again. So if this specific use case is handled in it's separated module it might make more sense [at least to me]

This probably needs a rebase since we've merged 🐛 Sticky actions fail on Ajax Active

Thanks 🙇

Thanks! 👏

Released & included in 4.0.3

https://www.drupal.org/project/gin/releases/4.0.3 →

@scott_euser we closed it in favor of https://git.drupalcode.org/project/gin_permissions

So it could be worked on in gin permissions and I could add you as a maintainer if you'd like to contribute to that ☺️

But would also love to hear @jurgenhaas opinion first about a permission approach 👀

Hey chris

Great discovery, updated, thanks!

Also updated the installation guide: https://www.drupal.org/docs/contributed-themes/gin-admin-theme/installat... →

Update to 4.0

Thank you for your contribution here.

I have one question: Could this be solved with permissions? We've started https://git.drupalcode.org/project/gin_permissions a long time ago but it got never fully being worked on

See also 🌱 Add permissions for User settings Closed: won't fix

I'm asking as there could be a use case that you want to expose more settings to admins and less settings to content editors. But this solution seems to generally limit the settings no matter their role.

We have scrollable tables with scroll indicators in Gin

So we might want to consider re-using Gin’s implementation here also to avoid potential conflicts and issues

@christianadamski can you confirm that the latest added changes still work in your case? Thank you