🇨🇭Switzerland @saschaeggi

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

Left one question in the code, moving this back to needs work for now

Hey @christianadamski thanks for creating an MR, I left one comment 👀

We're currently not planning a feature to disable this feature, so I'll close this for now. However you can use the hook to place all actions outside.

Thanks for the clarification! Yes, this seems to be wrong.

Why the use case I was testing still works as expected: For that button to function correctly, the important part is what gets set on the submit button themselves. The form attribute is referring to the id of the form and the data-gin-sticky-form-selector is referring to the the action being triggered (also an id). This seems to be correctly set. As this button doesn't have to rely on the additional click() event from JS as it can directly (natively) trigger the id which is defined in the form attribute on the button (that's an native HTML feature). That's why this still works as expected.

So in a nutshell, if that's not the case for a form action the JS never gets triggered in the first place because of the id and data-drupal-selector selector mismatch.

If you can spin up an MR which changes the part within the if (buttonSelector) {} to use [id="${formId}"] instead of [data-drupal-selector="${formId}"] this should be fixed.

We might want to additionally exit the function when the form attribute exists on the action and is available in the dom, but this could be done in a follow-up.

Yes, feel free to spin up a MR with a fix and adding steps how we can reproduce it!

The id is being used which generally would be correct as it gets updated by the context object in an Ajax request running through Drupal behaviors. In my short testing with an simple Ajax form this seems to work as expected and the id gets replaced with each Ajax call. But maybe your user case does not run through this function somehow.

I've also quickly did spin up an vanilla instance on tugboat here: https://master-oipts4sjqrrbzlm2ezjy0rvvw0jnjxkj.tugboatqa.com/admin/stru...

(admin/admin) and if you change the "Allowed number of values" it sends an Ajax request and the id gets changed, Save gets the updated form id and form selector id.

Cheers!

I'd agree with most being written here. There are certain things we can't control as we're dependent on Core and other modules or would be complete overkill for Gin to handle like the granularity you're looking for with class names. This eventually would need to be placed in the ideas issue queue to make this change in Core itself.

While the scope of Gin has organically grow drastically in recent years there are certain things which are awaiting a refactoring – and this is one of them. We've modularized already a fair bit of the CSS we ship but not just yet the basic styles like you mentioned. Eventually we would also want to override CSS from Claro completely instead of just extending it at some point in the future – so there is some refactoring planned in that regard at least. But It's currently something which is not of the highest priority unfortunately. That being said you or anyone else is more than welcome to contribute towards this goal though! It's something that can be worked on a component basis, file by file.

We'd happily take any contributions in that regard.

I hope this helps,
Cheers

Hey lovely Gutenberg team

Could you debug why this potentially is not showing up?

Thank you in advance

Should we close this in favor of 🐛 Details elements have incorrect aria-describedby attributes Needs work ?

As you reported this as being an issue on rc15, can you reproduce this issue on either stable release 3.0 or 4.0.2?

I'm pretty confident that we've fixed this in rc16+

Thanks for verifying. I'm moving the issue to the field group issue queue

potentially composer require 'drupal/gin:^4.0' --with-dependencies would work, too

Are you using the field_group module? If so we might want to move this to the module so they can look into fixing this.

I don't think we have different opinions about stable code – but there is quite some complexity maintaining the main admin theme which has a ton of hidden requirements for different use cases which might not be obvious at the first glance.

We don't want to add an explicit dependency. Also toolbar will soon be replaced by the new navigation module.

Unfortunately I'll have to close this as won't fix.

The search icon seems misaligned and not the remove button

I'm closing this again, as you already created a new issue for the same thing in 🐛 Paragraphs Issue Active

penyaskito → credited saschaeggi → .

That's a bummer. I see more situations where we do certain things where we only want to target Drupal CMS.

It could be just a config which we can easily query e.g. (drupal_cms: true) or anything else. We potentially could also include this setting in Gin if we can't place it somewhere outside it. However other modules might benefit of a setting like this, too in the long run. We can then make sure it gets enabled on the Drupal CMS installation progress (via recipes).

We should NOT add the accent library as this is only suitable for the backend, not for the frontend.

I would disagree here. The accent might be required to show the correct accent color within the dialog. As all our accent colors are gin prefixed this does not interfere with any content in the frontend. Also gin_dialog wraps all it's styles within the scope of .ui-dialog {} (note that we could change that to something like .gin-dialog {} down the line.

So with that there might no iframe needed.

That data attribute, among others, are being added in gin_preprocess_html(). Here is the catch. That preprocess never runs on the page where the XB app is rendered due to XB's unusual controller.

You're correct, also this will lead to more issues like Darkmode not working correctly, so we might want to fix this.

Can we scope this to Drupal CMS only?

Do we know how this is supposed to look like? It seems still pretty much unstyled afterwards? 🤔

that suggested change looks much better in theory. However, the buttons don't have any background color defined with that approach

Maybe a cache clear?

Thank you Cristina 💙

@pameeela can we add an issue credit for lauriii and myself as we have worked on the initial proposal, too

Thanks!

Thanks Jürgen, closing

Please contribute this to localize project over at https://localize.drupal.org/

Please report problems with the new sidebar navigation in the core issue queue

The legacy CSS was removed like it was announced in the release notes. You might need to clear caches.

We have spent a lot of research and time for different solutions and the split option just didn't perform and did not work for most users. Of course there will never be a solution which fits 100% of users. If you want to raise your concerns however, you can provide your feedback in the core issue queue for the new core navigation.

Thanks for confirming. Closing as works as designed as this level is only ment to open and close the flyout menus. You can access the level from within the flyout menu itself (Overview links or the title).

Cheers

Great thanks, I've issued a new release https://www.drupal.org/project/gin/releases/4.0.2 → 🎉🖖

More information are needed here. Which Extra tools? From Admin Toolbar or from Navigation?

Also can you provide a screenshot of which 1st level links you're talking about?

Thanks for confirming Paul 🙇

Let's wait for another review

Thanks both 👏

saschaeggi → created an issue.

bump

I still can't reproduce this, we'd need more steps or a video how to reproduce this

We're not using the sidebar for the media entity, so this must be some custom config or patch.

Additionally Gin 4.0 has removed its legacy code (Settings migration checks & CamelCase class support), see the 3.0 release notes.

Cheers

You might need to change the z-index of your sticky header.

Thanks! I've went ahead and included some more outstanding implementations to expose local actions as well as a temporary solution.

saschaeggi → changed the visibility of the branch 3495024-make-top-bar--gin.html.twig-compatible to hidden.

saschaeggi → changed the visibility of the branch 8.x-3.x to hidden.

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

Thanks @flocondetoile 👏

Thank you James

The icon used is quite complex at its optical size. It doesn't seem to go well with other icons. We also want to use svg's instead of pngs.

LGTM, Thanks!

This MR needs a rebase, I also left one tiny code nitpick

Thanks!

This needs a rebase

This needs a rebase and a dist recompile

Thanks for reporting, it's merged 🚂

Decreasing prio. here as it's on the dev branch

Merging

Thank you hudri, added you to the issue credit

Closings as another duplicate, Paragraphs EE or Paragraphs features need to be updated. The issue was fixed in their issue queue.

Thanks

The MR needs a rebase 👀

I wasn't able to reproduce this, so I'll close this one. If that's still a problem for some feel free to reopen.

saschaeggi → changed the visibility of the branch 3437516-improve-chosen-single-size to hidden.

Dist files are missing in the MR, moving back to needs work

The MR needs a rebase and recompiled CSS. Also I left 2 code comments 👀

Thanks!

Is this still a problem?

If yes, we might want to rebase the MR and update it's code to not use background-image as this won't scale with accent colors.

Closing as duplicate of 🐛 The icon color for the 'Remove Media' button should match the button color. Active

Closing as outdated as I wasn't able to reproduce this. We recently pushed some paragraphs related improvements which might have fixed the issue described here, too. If that's not the case please feel free to reopen. Thanks

Closing as I can't reproduce this, it might be outdated.

If you can still reproduce this feel free to reopen please.

I believe this is outdated as of now with recent changes.

Feel free to reopen if that's not the case please!

If this still applies, this MR needs a re-roll

Is this still a problem?

If yes, we might want to rebase the MR and update it's code to not use background-image as this won't scale with accent colors.