🇨🇭Switzerland @saschaeggi

@jan

And my CSP does not report anymore.

The new solution looks promising (clever idea)! I'll look into it this week. I'll report back once I tested it (potentially needs some slight asjustments to Gin Toolbar as well). Thank you for working on this

@ambient.impact

My original implementation of dark mode toggling was primarily CSS using @media (prefers-color-scheme: dark) {}, which not only would have avoided having to store anything by default

Both solutions had it's pro and cons (and still have). I still think the solution we went with is suited pretty well for the specific use case we have.

Closing as duplicate of 🐛 Cannot opt out buttons using #gin_action_item = TRUE Active

@yevko you'll need to update to RC14

Closing as it was fixed in Paragraphs EE.

I'm postponing this for now as there is currently heavy development in this area for Drupal CMS.

The topbar module will be hidden in 10.4 for that reason and should be installed for development purposes only.

See https://www.drupal.org/project/drupal/issues/3486198 📌 Hide the navigation top bar in 11.1.x and 10.4.x Active

Moved to main navigation

saschaeggi → created an issue.

Added 🎉

saschaeggi → created an issue.

Added

saschaeggi → created an issue.

Thanks all for working & testing this 🙇

There are errors in the pipeline, so moving this back to needs work 🙇

Thanks 👏

Awesome, thanks Jürgen for your hard work on this. Let's merge this so we can get a new release out this week 🎉

Thanks, I verified this now works

Before:

After:

I can't reproduce this. Also where does this magic number of 350px come from?

Potentially this is something you can add to the gin-custom.css ( see documentation → ).

I'm closing this as can't reproduce it.

Cheers!

@Jürgen @tirupati_singh are we ready to merge here or is another round of testing needed?

👍

Hey Dieter

I'm going to close this one out as we had several reportings and there was an issue opened in field group instead.

Thanks y'all for your patience and solution finding for this issue 🎉

One question left to the removed code (see https://git.drupalcode.org/project/gin/-/merge_requests/339#note_396145)

When we can verify that this is not needed to fix this issue we can move ahead 👀

Thanks again!

Thanks!

Yes it's working.

Awesome, I'll merge it 👌

But I'm really unsure that this `left:0` is still needed, without it's working the same.

Let's keep it as I don't know what side effects we'll have when we remove it 👍

@jurgenhaas

This is certainly not a privacy issue. If anything, it's a question of storing data on the user's browser. There is regulation around that limits when something like that is allowed, but not for privacy reasons because that data is not used for tracking, and it is no PII.

Let's see what @legalwebio has to say about that.

Do we know more about this?

@jan kellermann

I looked at MR !509 and left one question regarding potential issues with CSP inline script rules.

Hey @heyyo can you review this fix? TY!

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

bump

Thanks y'all for working on this. I left some code suggestions and found some bugs 👀

@tirupati_singh there was a typo I'm afraid, I've pushed a fix. If you mind having another look if it works now 🙇

Thanks for working on this! I left a code suggestion, also a before/after image would be helpful here :)

It looks like the library and CSS styles do not get loaded in your example (hence the unstyled Hide button. What module are you using? Is it displaying a core message (instance of core/drupal.message)?

If that's the case we'll need the steps how to reproduce this issue, as I tested this quickly with regular/ajax messages and can't reproduce it so far. Also it might not work as expected in a sub theme of Gin.

I'm closing this as I can't reproduce this in the backend. Note that Gin is not designed to be used as a frontend theme. While you can, it's not something we support. You'll need to load the variables.css (via gin/gin_base) to make the accent color work.

We need steps how to reproduce this, as I just checked it and it works as expected, apl
Variables are set correctly.

This is a change which will come in the next release, closing as works as designed.

As mentioned Gin is not intended to use as a frontend theme (while you can it's not something we actively support), and looking at your screenshot that's rendered in the frontend.

I quickly tested this and I can't reproduce it, so it seems to work. You might want to check for patches or overrides you might use in Gin.
Your best resource might be to open an issue in the poll issue queue at this point.

Best regards

Gin is an admin theme and not a frontend theme, we're not officially support using it in the frontend.

As far as I can tell it works as it shows the content. So closing this.

bump!

Great fix, thanks Eugen 👏

Let's close this in favor of 🐛 Ensure sticky action buttons to work with modals and ajax refresh-calls Needs review then 🤝

Closing this as won't fix as there is 🐛 Token browser invoked by CKEditor5 button will insert tokens in the Title field Needs work

Thanks!

When going through the multi-step form, I'm seeing warnings like these: Warning: Undefined array key "#type" in gin_form_after_build() (line 65 of themes/contrib/gin/includes/form.theme).

While using the simple_multistep module the actions button is now being shown. However, I'm also encountering the same issue as mentioned by @jurgenhaas in #22. Although the save button is present in the form but the Save button is not working as expected. Getting the error messages Warning: Undefined array key "#type" in gin_form_after_build() (line 65 of themes/custom/gin/includes/form.theme).

@Jürgen @tirupati_singh I've added a check for type, can you please have another look if it's fixed now?

Moving this back to needs work as there are some conflicts in the MR and the SVG is missing

Hey 👋

I left some comments in the code. Also note that the source files are missing, so moving this back to needs work

I wonder if we better fix this in Core instead of here so other themes can benefit of this, too.

No worries at all, that's why I linked the OG issue 👍

Moving to needs review 👀

Closing as duplicate of 🐛 WYSIWYG toolbar hidden when browser zoomed Closed: duplicate , see issue queue

Thanks!

Thanks for testing & providing feedback on this @heyyo & rajab natshah 👏

Agreed, closing this again

Thanks y'all 👏

@heyyo should we move forward with what we have in this MR to unblock this? I think we can fix the Shortcut one in a follow-up as it wasn't introduced here. WDYT?

dan2k3k4 → credited saschaeggi → .

The letter spacing of the text in the hero on the home page (https://new.drupal.org/homepage) is a bit cramped and hard to read

@jaygriggs thanks for your interest! A good start might be to review open issues or to contribute to the ones which need a helping hand, so we can see if you'd be a good fit!

This issue though is for finding more financial sponsors for the project

gábor hojtsy → credited saschaeggi → .

@manindres so this is not a specific issue to Gin? We should then maybe move this issue to the Token module instead?

The second is related to toolbar tooltip for example the one on hovering menu items in navigation bar, in RTL they are truncated, because they are not going to the correct direction (position set in javascript)

This was fixed yesterday with the latest push

postcss-rtl-logical-properties

Just makes sure that when CSS gets compiled that we don't introduce new non-logical CSS code (as the pipeline will fail and compiled CSS will always include logical CSS)

I suppose no javascript is needed to display tooltips now days.

Yes, this might be something to look at (also in Core) as we're currently using the integration of Core's new navigation tooltip library to display them (to use a unified approach).

one related to shorcut message displayed when pressing the star, because this text is not really hidden(opacity:0), it takes too much space if the translation is too long

This is something we can look into fixing here or in a follow-up but I guess this is not currently broken because of moving to logical CSS, right?

@heyyo that was potentially not covered when I rebased it as they were newer changes. I pushed a new change to add this to the coverage.

Note that we need to set this to localStorage as otherwise there will be a flickering at every page load. So it's an essential piece where it doesn't work as indented without. We therefore can't move this to drupal settings.

The question still remains if this violates any privacy law when we set exactly a binary value the browser offer us out of the box (user prefers dark scheme).

Closing as a duplicate of 🐛 Required asterisk doubled Closed: duplicate

@kostask I think that will be the better solution anyway. Thank you for taking care of that!

Let's close this issue in favor of a more stable solution in CV itself 🙇

@rajab let me know if you have any objections, I've just rebased the MR so this would need a final look 👀

@rajab natshah I think as there is now a lot of momentum for Drupal Starshot we can proceed with this even in 3.x

3.0 will be 4.0 at the same time. As Gin is not yet marked as stable and as you reported there are no major issues I think we should be good to go after a rebase. This will simplify the CSS codebase quite a bit.

@saurav-drupal-dev as both issues are not coming from Gin I think this should be fine for now

Thanks y'all 👏

I'm moving this one back to needs work as I found one issue with the change:

It adds the meta information ("English translation") for the default language back. We explicitly removed this from the UI for the default language as it's not a translation:

@kostask can this be combined or fixed with ✨ Incompatible with Clientside Validation and required checkbox Needs work ?

Let's close this as outdated in favor of the 🐛 Ensure sticky action buttons to work with modals and ajax refresh-calls Needs review .

Let's merge this in. Thanks 🙇

Note that there will be more changes needed down the road to make the user flow better for keyboard navigation on the entity edit form, but I'll defer that to after the sticky action direction decision.

This is a duplicate of 🐛 Edit form sidebar tab order does not match layout, makes reaching via keyboard very cumbersome Active

I'm closing this one in favor of the other one.

Thanks y'all 🚀

Let's get this in, thanks! 👏

Hey @simohell thanks for reporting! I've opened an MR which needs a review to fix this 🙇

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

I also wasn't able to reproduce this with the given MR, published status shows up in form.

I'll close this one as can't reproduce for now.

Is this still a problem with the latest changes from 🐛 Ensure sticky action buttons to work with modals and ajax refresh-calls Needs review applied?

saschaeggi → changed the visibility of the branch 3463796-ensure-sticky-action to active.

saschaeggi → changed the visibility of the branch 3463796-ensure-sticky-action to hidden.

Thanks Mark!

Closing this as outdated as 🐛 contents of dropdown button go to the left and can be off the visible page RTBC has landed.

Thanks everyone which was involved in fixing this bug 🙇

@tirupati_singh I was wrong, there were recently some phpcs changes for PHP 8.4 support, strangely enough this is the first MR which this shows up. See 📌 [PHP 8.4] Fix implicitly nullable type declarations Active

So I think we're good to go here 👏

@tirupati_singh I pushed a change to remove the phpcs issues as they're not really issue but rather false positives. I'll look into why this MR behaves like this

Thanks Norman 👌

Thanks for contributing this 👏

Let's have a look at this at DrupalCon Barcelona and how we can contribute back Gin's improvements

Thanks y'all 👏

@volkerk actually I was wrong, it works perfectly fine, sorry! I've went ahead and merged it! Thanks for the fix 🙇

Because another theme is violating european law it is okay, if gin is doing this, too? I hoped we dont need to argue on this level.

Again, I still believe we don't violating any law here, as it's a technical requirement and not data we gather. We just want to be sure if we're violating anything first before we act rashly and break a working feature for potentially hundreds or thousands of users.

In the current situation gin in combination with gin_login violates european privacy law and the issue should not be postponed. Please set to need work and i can add an config item.

As I mentioned before as a workaround – until we figured this out if this really applies here – would be that you can add it to your privacy policy that Gin sets Drupal.gin.darkmode which sets the browser default value of the user preferences a dark scheme or not.

PS: I would like to remind you that in the Drupal community we respect each other, no need to be offensive here.

Moving to needs review

Closing as outdated. Please reopen if this problem still persists in the latest dev versions.

I'll close this in the meantime as it's not reproducible. Feel free to reopen if you can.