No worries! Closing this one. Cheers
Tested with various instances and I can't reproduce this.
Also here is a vanilla instance of 10.3.1 with RC13: https://master-jt622hr9gjfrh2yjbgb8pwt8hm14a1vf.tugboatqa.com/user (admin/admin).
Doesn't seem to be an issue of either Gin or Gin Toolbar.
Can you create a MR to add it? Cheers!
Please create a new feature request instead so we can work on adding support (or at least somebody which owns such a device can!)
Basic functionality was shipped, so closing this one again.
Thanks,
Closing this as duplicate as there are already related issues open. Thanks!
Will we still have the top toolbar on the front end?
Yes
The test integration gets removed soon from Gin, so nothing we have to worry π
Use the core navigation instead.
A problem of Core, I'm closing this here. The core team is already working on a fix.
You'll need to make sure your Drupal & PHP caches are cleared. Sometimes you'll need to restart the php service.
As we don't declare anything in table.theme
(as it got removed) it could either be the following:
- Cache: Clear all the PHP and Drupal caches
- Remove patches if you use any as they might not be compatible with the latest release and you might need to update them
We're running on all standards checks, see pipeline. Closing this issue.
@szeidler this needs a review π
I move this to postponed for now as we're working on other things.
One can argue over which icon should be used for sure, the sidebar icon indicates worse than the cog wheel. As the default placement of content in the sidebar is somewhat configuration related, it does make sense (opinion might vary of course here).
One thing I can already tell is that we don't plan in attaching the toggle functionality to the sidebar itself, as we do not have a collapsed state. It is intentionally placed in the sticky header and does perform well in our testing.
Closing this again.
Let's wait until β¨ Add attribute to form if Gutenberg enabled Active has been merged π
Can we get this in soon? Thank you!
@SirClickalot can you please open an MR with the additional forms we need to check for? Thanks
Thanks y'all!
This needs a review
Thanks!
I'm moving this back to needs work as the changes seem to only be in the dist folder. Also we would need an MR to run all the tests π
saschaeggi β changed the visibility of the branch 3417719-edit-media-icon-3x to hidden.
saschaeggi β made their first commit to this issueβs fork.
Either downgrade to RC10 or update Drupal to 10.3 might be your best solution here
Closing in favor of issue π Fix the warning issue that occurs when pressing the save submit button in the Gin Admin theme RTBC
Does that mean we can close this issue in favor of the module's?
Closing as multiple issues already exist.
That being said, you could develop a small companion module which alters the behavior for breadcrumbs.
Currently not in the scope or planned, sorry! I'm closing this again.
@szeidler thanks for the quick turnaround here! I think the PHP attribute is the better solution for sure and works fine for what's needed from Gin's side. The additional data attribute might be beneficial for any JS related checks (if there are any needed).
Thanks!
szeidler β credited saschaeggi β .
This is a Gutenberg specific issue, the Mercury editor issue was already fixed in dev.
@szeidler a form (data?) attribute would be nice so we could check for that instead of a css class (something like data-gutenberg-enabled
) on the form root element ($form['#attributes']['data-gutenberg-enabled'] = TRUE;
)
Could we add something like that in Gutenberg?
Updated
gin_toolbar
patch to also fix the check for the experimental navigation_top_bar
module
Added compatibility with Drupal 10.3+
Needs a patch for Gin Toolbar to test this properly (see attached).
saschaeggi β made their first commit to this issueβs fork.
Maybe we need to move this issue to Drupal core? As core defines the name of this block for the navigation module (or do I miss something here?)
The or
is the correct behavior in the check
There must be a better way in checking if Gutenberg is active other than checking for the existance of a css class π and ignore our sticky implementation, the best way probably would be if Gutenberg is using our ignore hook for this, but as a temporary workaround this MR should help π
gutenberg_gin_ignore_sticky_form_actions() {
// Check if Gutenberg is active here and return FALSE
return FALSE;
}
So you might want to open an issue in their issue queue to handle this properly.
saschaeggi β made their first commit to this issueβs fork.
saschaeggi β made their first commit to this issueβs fork.
saschaeggi β made their first commit to this issueβs fork.
saschaeggi β made their first commit to this issueβs fork.
Closing as duplicate of π contents of dropdown button go to the left and can be off the visible page Needs work
This needs to be named like that to function properly with the new core navigation. I'm closing this as works as designed.
I've uploaded a patch to ignore webforms elements form as a temporary solution until we figured out (hopefully together with the webforms team) why this single form does not work sequently
@jrockowitz could we fix this with adding a dependency on the corresponding webform library?
See also the efforts in π Form buttons missing in modal/off-canvas Needs review
Closing as haven't heard back, please reopen when you have more information.
This will be fixed with π Form buttons missing in modal/off-canvas Needs review
@trickfun can you please test the MRs in the mentioned issue, thanks.
I can't really reproduce this, I think we need step by step instructions how to reproduce this with the latest dev versions.
I'm trying to understand why this is needed. Are you using a different (custom) menu for the editor?
Did you test the patch from the mentioned issue?
We shipped improvements for high contrast mode in the latest 3.x and 4.x dev which included the chevrons for details.
We shipped improvements for high contrast mode in the latest 3.x and 4.x dev and included improving the toggle styles.
I'm closing this issue as the sceenshot show Olivero and not Gin, please open an issue in the Olivero issue queue (Core) instead, thanks!
I'm closing this as we're using Core's logo field which does not provide an alt text. Please instead open an core issue for this, thanks!
I close this issue as outdated, as we completely overhauled the toggle integration.
Closing as outdated, as we have removed that template a while ago.
This was fixed in 3.x & 4.x dev a while ago. Closing this issue.
Closing this as we implemented a different solution in π gin-table-scroll-wrapper hides drop down options if they expand beyond container Fixed
Still potentially a browser cache issue, SVGs get cached pretty heavily sometimes. Also the svg itself might not be affected by Drupal's caching system.
Can you share some screenshots please?
@andreic generally speaking it might not be a good idea to try to use the admin_dialog
module to override all basic functionality with off-canvas dialogs as Drupal isn't designed for this. So you can always run into issues. The issue in #22 on the other hand has nothing to do with what we're trying to solve here as it's not a form at all.
If you want a better experience for the add content menu you can either use one of the following solutions:
- β¨ Improve "Add Content" on admin overview pages Needs work
- Use the new navigation module (Drupal 10.3+)
- Use Gin's experimental navigation implementation
Let's focus on fixing the modal/off-canvas form
handling here π
This needs a review π