🇨🇭Switzerland @saschaeggi

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

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!