Hi all, I’ve re-reviewed the latest changes related to the disabled sticky behavior fixes. The issue with the sticky table header persisting when "Toolbar sticky behavior" is set to "Disabled" has now been resolved. All configuration options under "Toolbar sticky behavior" are functioning correctly.
The remaining transition property enhancements for the toolbar can be addressed separately, as suggested by @justcaldwell in the last comment.
I’m keeping the issue status as Needs Review to gather feedback from @ressa and @dydave. If everything looks good, we can move it to RTBC.
Additionally, I’ve updated the MR to include the missing disabled_sticky library dependency required for Drupal.displace().
Please review the latest changes and let me know if any further updates are needed.
Thanks!
Hi @Charles and @dydave,
I followed the steps to reproduce the issue and was able to replicate it. When a toolbar menu item is focused, the background color of the focused item changes as expected. After applying the provided MR as a patch, everything applied cleanly with no errors. Now, the focused menu item gets an outline based on the browser's default settings, and the background color has been unset as discussed earlier.
However, I encountered a couple of issues:
- Vertical Toolbar: The focus indication is not working when the toolbar is set to vertical alignment.
- Local Tasks Menu: The focus is also not functioning correctly for the Local Tasks menu item, regardless of whether the menu is in horizontal or vertical layout.
Do you think we should still keep some styles with the colors? (background/foreground)
Or just the outline styles could be enough?
Additionally, while the current focus style is functional, I believe it could be improved by reintroducing a background color to the focused item, similar to how it was previously. This would make the focus more visually distinct and improve accessibility.
I've addressed the focus-related issues in the cases mentioned above. Please review the MR and let me know if any additional changes or adjustments are needed. I’ve also attached screenshots showing the behavior before and after the fix for reference.
Thanks!
I tested on Chrome Version 137.0.7151.55 (Official Build) (64-bit) and Drupal 10.4.7v. It seems to be working fine on this version, but I’ll keep an eye on it and let you know if anything changes.
Let me know if you need any other details!
Hi @drupalbubb,
Thanks for the clarification! If I understand correctly, you're suggesting that the label of the link itself should be replaced with the text from the "external link label."
Since this seems to be more of a feature request, I'll tag the maintainer and subsystem to ensure this suggestion is reviewed.
@ressa
@tirupati_singh: Thanks! Did you test both options?
Yes, I tested all three options under the "Toolbar sticky behavior" configuration, including "Enabled", "Disabled, show on scroll-up", and "Disabled". Everything was working correctly in my setup.
I specifically checked using the Claro theme with sticky table headers enabled, and didn’t notice the table header hanging issue with the "Disabled" option.
Happy to retest or provide more details if it helps narrow down the issue!
Thanks for the quick follow-up, @dydave!
I went ahead and tested the module on a fresh Drupal 11 installation, and I can confirm that the issue I previously encountered (mentioned in comment #17 🐛 element hangs, when Toolbar is hidden Active ) is no longer present. The shortcut toggle (Alt + P) is working as expected, and there are no console errors related to the #toolbar-bar element.
It seems the issue might have been due to some customization or configuration in my earlier setup. I’ll keep an eye out and report back if I’m able to consistently reproduce it in a specific scenario.
Thanks again!
I'll review this.
Hi @drupalbubb, I followed the steps to replicate the issue and was able to reproduce it. Yes, this behavior also occurs for "mailto" and "tel" links. However, this is not actually a bug, as the module is designed to display the title for both the link icon and the link text itself.
You can configure the titles individually using the "{external} link label" field. If you don't want a title for the icon, simply leave the icon label field empty — the same applies to the link title. The module provides flexibility to set or omit these titles based on your needs.
If you'd like the label to display as "external link," you can set that value in the "external link label" field.
Since this is expected behavior and the module is functioning as intended, I believe this issue can be closed.
Thanks!
Hi all, I’ve retested the MR I raised for the fixes after the latest changes were applied. I patched it onto another local environment and verified that the changes are working as expected. The sticky behavior of the admin toolbar now responds correctly to the option selected under "Toolbar sticky behavior" configuration.
@dydave — while testing, I encountered a new issue when the "Hide or show the toolbar with shortcut (Alt + p)" option is enabled. The shortcut is not working in my setup, and I’m seeing a console error related to the following code:
toolbarElement.querySelector('#toolbar-bar').insertAdjacentHTML(
// The toolbar tab item is inserted as the last item in the toolbar.
'beforeend',
Drupal.theme.adminToolbarToggleCollapse(),
);
This error appears in the JS file:
/admin_toolbar/js/admin_toolbar.toggle_shortcut.js at line 66
.
Upon inspecting the DOM, I noticed that the element with ID "toolbar-bar" is not present, which might be causing the issue and preventing the shortcut from functioning.
Could you please confirm if I’m missing any specific configuration needed for this feature to work?
I've attached a screenshot of the console error for reference.
Thanks!
Hi @very_random_man,
While debugging the issue, I found that the Actions button was not showing when using the Gin Admin theme. As a result, I was initially unable to replicate the issue on my local environment. Upon further analysis, I found that this problem had already been reported here: [Workbench Moderation] Submit Button Disappeared, Create New Revision Checkbox Disabled, and Only Preview Button Appears after Applying Drupal GIN Theme 🐛 [Workbench Moderation] Submit Button Disappeared, Create New Revision Checkbox Disabled, and Only Preview Button Appears after Applying Drupal GIN Theme Closed: works as designed . However, the issue was closed by the maintainer with the status "Closed (works as designed)" and no merge request was provided.
Since the issue still exists in the latest version, I’ve raised a merge request with a fix for the missing Actions button for workbench_moderation module.
After resolving the Actions button issue, I was then able to replicate the original problem locally. It turns out that the dropbutton with only a single option was not rendering correctly when not in focus. I've resolved this by updating the styling for dropbutton so that single-option dropbuttons now match the design of multi-option dropbuttons.
I've attached before-and-after screenshots for reference. Please review the MR and let me know if any further changes are needed.
Thanks!
Hi, I've fixed the missing Actions button issue while using Workbench Moderation module with this theme. Now, the actions button is showing on the node creation and edition page with the configured moderation states. I'm attaching the screenshots of the fixes for reference. Please review the MR changes and let me know if any further changes are required.
Thanks!
Hi all,
I’ve retested the changes introduced in the MR by applying it as a patch and can confirm that the reported issues have been resolved. I had previously reviewed the MR, but after the recent updates, I reviewed the changes.
Before applying the patch, the View button's hover effect was not functioning as expected, and the Delete button was not visible once it lost focus. After applying the latest changes from the MR as a patch, both issues have been addressed: the View button hover effect now works as designed, and the Delete button remains visible after losing focus.
I’ve attached screenshots for reference and am moving the issue status to RTBC, as everything is now functioning as intended.
Thanks!
Hi all, I'm encountering the same issue when using the Workbench Moderation module with the Gin Admin theme. After enabling "Moderation states" (/admin/structure/types/manage/{content_type_machine_name}/moderation
) the Save action button no longer appears, which prevents content from being transitioned to any moderation state. This issue does not occur when using the Claro theme — the Save button and moderation options display as expected there.
I've already tried the solution suggested in comment #7, but unfortunately, it didn’t resolve the issue for me.
I'm attaching screenshots for reference. Since this problem persists with the latest version of the Gin theme, I'm updating the issue status to Active.
Thanks!
I'll look into this.
@abhishek@kumar, I've tried the CSS shared in comment #10, but it didn't work as expected. The attribute [data-toolbar="disabled"] is not present in the DOM during testing on Drupal 10.4.7.
Let me know if there's an alternate approach or if this behavior is version-specific.
@dydave, I've fixed the sticky table header design issue that occurred when the option "Disabled, show on scroll-up" is selected. Please review the MR and let me know if any further changes are needed. I've attached screenshots of the fix for your reference.
Thanks!
My bad, forgot to attach the attachments. Attaching here. I'm also looking into the issue.
Hi @dydave and @ressa, I've followed the steps to replicate the issue and can confirm that the issue persists. When choosing the option "Disabled, show on scroll-up" under Toolbar sticky behavior setting of Admin Toolbar Settings, on scrolling down and up the attribute "--drupal-displace-offset-top" is not getting restored respectively, which is triggering the issue for all the tables that have "Enable Drupal style "sticky" table headers" property enabled as @erutan commented on #6. I'm attaching the screenshot for reference.
Hi @very_random_man,
I tried replicating the issue on my end, but I wasn't able to reproduce it. Could you please share more details about the issue, including the steps to replicate it? If possible, screenshots or any other relevant information would be very helpful.
Thanks!
Hi @chrisolof, I followed the steps to reproduce the issue and confirm that it still persists. When using the phone_number field, its design stands out with its own instead of rendering as per the current admin theme set. I've redesigned the number field rendering and removed the unnecessary CSS codes from the file. After the fixes, now phone number field is now being rendered as per the current admin theme. Please review the MR changes and let me know if any additional changes are needed.
I've attached the screenshots of before-and-after fixes for reference.
Thanks!
I'll look into this isssue.
Thanks @thoward216 for the quick implementation of the requested changes. I’ve been reviewing the updated merge request with the feedback incorporated, but I’m encountering an issue while testing it with the same component props mentioned in comment #23.
When I use the component props as follows (from the earlier example):
name: CTA Button
description: This is component for adding CTA.
status: stable
props:
type: object
properties:
cta_url:
type: string
title: Link URL
description: Add the url to be used.
format: uri
examples:
- 'https://www.drupal.org'
cta_title:
type: string
title: Link Title
description: Add the title to be shown on hovering
examples:
- 'Learn more'
cta_icon:
type: string
title: CTA icon
description: Choose the icon to be display for cta
examples: ['PDF', 'Video', 'Arrow', 'External Icon']
default: Video
enum:
- ''
- PDF
- Video
- External link
- Arrow icon
cta_icon1:
type: string
title: CTA icon 1
description: Choose the icon to be display for cta
examples: ['PDF', 'Video', 'Arrow', 'External Icon']
default: Video
enum:
- PDF
- Video
- ''
- External link
- Arrow icon
cta_icon2:
type: string
title: CTA icon 2
description: Choose the icon to be display for cta
examples: ['PDF', 'Video', 'Arrow', 'External Icon']
default: Video
enum:
- PDF
- Video
- External link
- Arrow icon
- ''
I did not encounter the specific error message ('Prop "%s" has an empty enum value.', $prop_name) in the ComponentMetadataRequirementsChecker class, after the feedback was incorporated and the changes were made in the MR. However, I am now encountering a different issue in the Experience Builder UI. The error message displayed is: "An unexpected error has occurred while rendering the component's form." I’ve attached a screenshot for reference.
Could you please suggest any specific steps or checks I should follow when creating or testing the component? If there’s anything I might have missed or overlooked in the process, I’d really appreciate it.
Thanks!
@wim leers, thank you for the detailed feedback and insights — much appreciated!
You took a different approach than what's in the issue summary, @thoward216, and you had me first thinking it was genius, simple and elegant, but … I think I spotted some negative consequences: do you agree?
Yes, I do agree with your assessment. You're absolutely right — I took a different approach by omitting "" from the enum instead of explicitly disallowing it. At first glance, it seemed like a clean and unobtrusive way to sidestep the HTML limitation, but I can now see the downside — particularly in cases where "" is explicitly included in a required field's enum. This results in an unusable form element, which defeats the purpose of validating the SDC in the first place.
After re-reviewing the changes in my merge request, I realized that the current fix does not fully resolve the issue, especially for props like cta_icon1
and cta_icon2
.
While the intention was to handle enums with empty strings more gracefully, the approach I took (silently omitting "") doesn't correctly address all problematic cases. For instance:
- cta_icon1 includes "" in the middle of the enum array.
- cta_icon2 includes "" at the end.
Both of these cases still result in invalid for below component props
cta_icon:
type: string
title: CTA icon
description: Choose the icon to be display for cta
examples: ['PDF', 'Video', 'Arrow', 'External Icon']
default: Video
enum:
- ''
- PDF
- Video
- External link
- Arrow icon
cta_icon1:
type: string
title: CTA icon 1
description: Choose the icon to be display for cta
examples: ['PDF', 'Video', 'Arrow', 'External Icon']
default: Video
enum:
- PDF
- Video
- ''
- External link
- Arrow icon
cta_icon2:
type: string
title: CTA icon 2
description: Choose the icon to be display for cta
examples: ['PDF', 'Video', 'Arrow', 'External Icon']
default: Video
enum:
- PDF
- Video
- External link
- Arrow icon
- ''
Thanks again for the clear explanation — it’s really helped clarify the situation. I'll adjust the implementation to explicitly disallow "" in enums and ensure proper test coverage for these cases.
Hi all, I followed the steps to reproduce the issue and can confirm that it persists. I was able to replicate the problem on both Drupal versions 11.1.7 and 10.4.7. When I click the Save button on a form, such as the one for "/admin/structure/types/manage/page," the page reloads, and the changes are saved. However, if I click Save and then navigate back to the previous page using the browser's Back button, clicking Save again results in no action. The changes are only saved after refreshing the page. This behavior also occurs when creating a new field; after saving it and using the back button to return to the page, clicking Save again doesn’t work.
I’ve applied the provided MR as a patch on both Drupal 10 and 11 versions, and the patch applied successfully without errors. After applying the patch, I repeated the steps to reproduce the issue. Now, when I click Save, the changes are saved, and the page redirects to its destination route. After navigating back using the browser’s Back button, clicking Save again successfully saves the changes, which wasn’t happening before the patch was applied. The same behavior occurs when creating or editing fields — after saving and navigating back, clicking Save works as expected, as demonstrated in the attached video clips.
I’ve attached video clips showing the behavior before and after the fix for reference. Since the MR changes are now functioning as expected, I would mark this as RTBC. However, since the MR still requires maintainer review, I won’t change the issue status to RTBC just yet. If the maintainer approves the changes, the status can be updated accordingly.
Thanks!
I'm reviewing this.
I'll look into this.
Hi @wim leers, I applied the provided MR as a patch, and it was successfully applied without any errors. However, after applying the patch, I'm encountering the following issues:
- UI error: "An unexpected error has occurred while rendering the component's form."
- Console error: "Experience Builder determined the options_buttons field widget plugin must be used to populate the experience_builder:custom-cta prop on the cta_count component. However, no xb.transforms metadata is defined on the field widget plugin definition. This makes it impossible for this widget to work. Please define the missing metadata."
Before applying the patch, the components were functioning properly.
I'm sharing the component YAML file I'm using below for reference:
name: CTA Button
description: This is component for adding CTA.
status: stable
props:
type: object
properties:
cta_url:
type: string
title: Link URL
description: Add the url to be used.
format: uri
examples:
- 'https://www.drupal.org'
cta_title:
type: string
title: Link Title
description: Add the title to be shown on hovering
examples:
- 'Learn more'
cta_icon:
type: string
title: CTA icon
description: Choose the icon to bePDF display for cta
examples: ['PDF', 'Video', 'Arrow', 'External Icon']
default: Video
enum:
- ''
- PDF
- Video
- External link
- Arrow icon
cta_count:
type: integer
title: CTA Count
description: Store the cta count
enum:
- 1
- 2
examples:
- 2
cta_redirect_count:
type: integer
title: CTA redirect count
description: Count redirection of CTA
enum:
- 1
- 2
- 3
examples:
- 3
cta_redirect_counter:
type: integer
title: CTA redirect counter
description: Count redirection of CTA
enum:
- 1
- 2
- 3
- 4
examples:
- 4
Additionally, I tried enabling the all-props.component.yml
from "tests/modules/sdc_test_all_props/components/all-props/all-props.component.yml" by copying it to "/modules/contrib/experience_builder/components/" with a different component name to debug the issue. However, the component is not appearing under "Components" in the Experience Builder UI.
I'm unsure whether I'm missing something in my configuration or if the recent changes introduced this issue. The same component worked perfectly fine before applying the patch.
For reference, I'm also attaching the screenshots of the component before and after the patch was applied.
Thanks!
I'll review this.
Hi all, I've created a new component called "CTA Button" to replicate the issue and confirm that it still persists. Below is the component.yml file:
name: CTA Button
description: This is component for adding CTA.
status: stable
props:
type: object
properties:
cta_url:
type: string
title: Link URL
description: Add the url to be used.
format: uri
examples:
- 'https://www.drupal.org'
cta_title:
type: string
title: Link Title
description: Add the title to be shown on hovering
examples:
- 'Learn more'
cta_icon:
type: string
title: CTA icon
description: Choose the icon to be display for cta
examples: ['PDF', 'Video', 'Arrow', 'External Icon']
default: Video
enum:
- ''
- PDF
- Video
- External link
- Arrow icon
I agree with @wim leers and @heyyo's point that
By default XB adds a 'None' value to the SELECT OPTIONS, which is great like this no need to add a empty string in enum.
I also believe the empty string is unnecessary for the component props, as the "None" option provided by Drupal already covers this functionality.
To address the issue as per the comment #3 🐛 SDC prop of `type: string` with empty string listed in its `enum` results in broken input UX Active , I removed the empty string value from enum. However, I’d prefer that we accept the "None" option provided by Drupal, rather than adding an empty string in enum.
By removing the empty string, this should also resolve issues with other components. I've attached before and after screenshots of the fix for reference.
Please review the MR changes and let me know if any further adjustments are needed or if there's a better solution to address the issue.
Thanks!
I'll look into this.
Hi, after debugging the error:
Warning: Undefined property: Drupal\menu_ui\Hook\MenuUiHooks::$entityTypeManager in Drupal\menu_ui\Hook\MenuUiHooks->menuDelete() (line 276 of core/modules/menu_ui/src/Hook/MenuUiHooks.php).
that I encountered while deleting the menu, I found that it was fixed in the issue
Deleting a menu link from the node edit form does not apply hook_ENTITY_TYPE_access()
🐛
Deleting a menu link from the node edit form does not apply hook_ENTITY_TYPE_access()
Active
. The MR changes for the fixes were merged in the 11.x branch. Since I was testing on Drupal version 11.1.7, and its branch was 11.1.x, hence I was getting the error as the changes were not merged on the 11.1.x branch.
After applying both the MRs MR !11321 and MR !11946 as patch the encountered error is getting resolved. Now, on deleting menu, I'm not getting any error and also there's no error message appearing for the $entityTypeManager. After deleting the menu that has been enabled for a content type is also getting removed from the content type configuration upon exporting the configuration. I'm attaching the screenshots of after fixes for reference.
As the changes are working fine and MR is resolving the issue, and the pipeline was passing all the tests previously before pulling the latest changes from the source branch. Hence, I'm changing the issue status to RTBC.
Thanks!
Hi all, I've followed the steps to reproduce the issue and confirm that the issue persists.
- Created a new Menu i.e., Explore Drupal.
- Enabled the newly created menu to a content type under the
Menu settings > Available menus
- Exported the config using the drush cex command.
- Now deleted the newly Menu.
- Again, exported the config using the drush cex command.
Upon exporting the config for the first time, the new menu config has been exported and the content type config got modified with the changes in node.type.content_type_machine_name.yml file as follows under settings
third_party_settings:
menu_ui:
available_menus:
- explore-drupal
- main
- tools
parent: 'explore-drupal:'
and a new new config file "config/sync/system.menu.explore-drupal.yml" has been created for new menu.
After deleting the new menu, and exporting the configs with the same drush command did the following changes:
- Deleted the config file "config/sync/system.menu.explore-drupal.yml"
- However, the content type that were using the Menu, it's config file didn't get modify and the config remains the same.
third_party_settings: menu_ui: available_menus: - explore-drupal - main - tools parent: 'explore-drupal:'
I applied the provided MR !11946 and it applied cleanly without any errors. I followed the same above steps and tried deleting the menu. However, on deleting the menu getting this errors:
The website encountered an unexpected error. Try again later.
Error: Call to a member function getStorage() on null in Drupal\menu_ui\Hook\MenuUiHooks->menuDelete() (line 262 of core/modules/menu_ui/src/Hook/MenuUiHooks.php).
Tested on Drupal 11.1.7
Since, the provided MR is not resolving the issue and some changes still required to resolve the issue hence, I'm moving it to Needs work. I'm attaching the screenshots of before and after fixes for reference. Additionally, I'm looking into the above encountered issue.
Thanks!
Hi @sd9121, I followed the steps to reproduce the issue and can confirm that it still persists. When adding a link field, the URL field gets squished due to the description taking up too much horizontal space. This is also affecting the layout of fields for the link title and text.
I applied the MR provided as a patch, and it applied without any errors. After applying the patch, the URL field's description was moved below the URL, which resolves the design issue and prevents it from breaking the layout.
For reference, I’ve attached screenshots showing the issue before and after the fix.
However, in the latest version of Drupal 11, this issue doesn’t occur, since the CSS rule td > .form-item { display: flex; }
has been removed from tables.css. In Drupal 11, the .form-item now renders as a block element, which resolves the issue naturally.
Moving the status to RTBC as the changes are working fine and will fix the issue for older versions as well.
Thanks!
Hi @javi-er and all, I've made the changes for the component as per feedback provided. Additionally, I've noticed some design issues with the component and fixed those as well to align with the shared Figma design for the component. Please review the MR changes and let me know if any further changes are needed. I've attached the screenshots of before and after fixes of component design for reference.
Thanks!
Hi all, it been more than a month and since @vasantha deepika has not responded, so I'm picking this issue.
Hi all, I've also attempted to replicate this issue while working with the components. For example, with the "Carousel" component, when I passed the following values:
show_carousel_control: true
,
show_carousel_indicators: false
,
show_carousel_caption: false
,
the carousel still rendered indicators and captions, even though false was explicitly set for those props. This behavior was consistent across other components as well, whenever the default('true') filter was used. As @danchadwick mentioned in comment #6, the default filter was causing this unexpected behavior.
I applied the provided MR as a patch, and it applied cleanly without any issues. After the patch was applied, I observed the components working as expected. Specifically, replacing the default('true') filter with the null coalescing operator (??) resolved the problem. Now, when passing show_carousel_control: true, show_carousel_indicators: false, and show_carousel_caption: false, the carousel no longer renders the indicators or captions, as expected.
I've attached screenshots demonstrating the change and its effect on the component for reference. I am moving the issue status to RTBC, as the changes are now working as intended across the components.
Thanks!
Hi @madhaze, I followed the steps to reproduce the issue and confirmed that the issue exists. The contextual menu is getting hidden while using the gin layout builder sidebar, and unable to perform any operation without closing the sidebar. I've fixed the issue, and now the contextual menus are visible while using the layout builder sidebar. I'm attaching the screenshots of before and after fixes for your reference. Please review the MR changes and let me know if any further changes are required.
Thanks!
I'm looking into this.
Hi all, I was able to reproduce the issue by following the outlined steps, and I observed that the site branding logo was being rendered without its height, width, and loading attributes. I’ve applied the provided MR !1158 as a patch, and it applied cleanly. After applying the patch, the site branding logo is now rendered with height, width, and loading attributes for PNG, JPG, and SVG files, which was previously missing. Previously, only the src and alt attributes were rendered for the logo. The MR changes are working fine, and I’ve attached screenshots showing the issue before and after the fix for reference.
Additionally, with the new MR changes, $site_logo now returns an array containing the image elements with their properties instead of just the URI. This change may potentially cause layout issues for themes that use their own branding logo system or preprocess the branding block template.
Although the MR changes are working well with D11, I’m keeping the issue in "Needs work" state since the pipeline is failing and to consider backward compatibility.
Hi @dinerrr, I was able to replicate the issue. However, the Carousel paragraph component line height is not having too much verticle space. The space is getting adding as per the option chosen in the select list "Heading type" under the "Settings" tab for each Carousel Items. The line height will increase/decrease depends upon the value that you will select for "Heading type". The line height will be too big or will have large vertical space if you will choose 'H1' and will be the least if you will choose 'H5'.
This component is designed such that the line height will varry as per chosen value in "Heading type". As per my view this is not an issue the component is working as designed. In if we want to change the line height then, the component design will be affected as we cannot directly change it for a specific "Heading type"
I've attached the screenshot for your reference, where you will notice how the line height is getting changes as the "Heading type" changes from H1 to H2.
As the component is working as designed, I'm moving the issue to Closed (worked as designed).
Thanks!
Hi @dinerrr, I was able to replicate the issue. The extra spacing at the top was appearing due to the margin-top set at the class "d-p-gallery__items". The intention was to add some spacing between the "Main title" or "Gallery description" field added in the Gallery component; however, the margin was still added if the component does not have content in the fields "Main title" or "Gallery description".
I've fixed the spacing issue. Now, the "d-p-gallery__items" will have a margin at the top only when the component has content in the fields "Main title" or "Gallery description," and no margin at the top when there is no "Main title" or "Gallery description" added in the component. I'm attaching screenshots of the before and after fixes for the issue for reference. Please review the MR changes.
Thanks!
I'll look into this.
I'm look into this.
Hi @anybody, I've added a new widget option named "Enable Compact Row" to enable/disable display inline fields when using the module. I've attached the screenshots of before and after fixes for reference. Please review the changes.
Thanks!
Thanks @ressa and @dydave for looking into the feedback and making the quick changes. As @ressa noticed, the menu ordering for Admin Toolbar menus links was not alphabetically and this could affect user experience somehow.
I've re-applied the MR as a patch and it applied cleanly without any errors. After applying the patch, the menu links for Admin toolbar has been sorted alphabetically as shown in the attached screenshots.
Additionally, noticed one difference in the setting page title for Admin toolbar search config page. For Admin toolbar and tools config page, the page title has some inconsistency. For Admin toolbar setting config page title is 'Admin Toolbar settings', for tools it is 'Admin Toolbar Tools settings', however, for search it is 'Admin toolbar search settings'. As per my suggestion, the config page title for Admin Toolbar Search should be 'Admin Toolbar Search settings' to maintain the consistency for the modules.
I've fixed the title label for admin toolbar search settings page from "Admin toolbar search settings" to "Admin Toolbar Search settings" as mentioned previously in the comment. I think it would be better if consistency is maintained throughout the module. I'm attaching the screenshots of before and after fixes for reference. Please review the changes.
Thanks!
Hi @dydave, I've applied the provided MR as a patch, and it applied cleanly without any errors. Previously, as mentioned in the issue summary there was no way to navigate to the "Admin toolbar tools, Admin toolbar search and Admin toolbar" settings however the module configuration can be access under the menu "Configuration > User Interface > Admin Toolbar Search, Configuration > User Interface > Admin Toolbar Tools, Configuration > User Interface > Admin Toolbar".
After applying the patch, new tabs have been enabled to access/configure Admin toolbar, toolbar tools and toolbar search under Admin Toolbar Settings, i.e., /admin/config/user-interface/admin-toolbar
. This is a great feature enabling users to easily switch between these sub-module settings by just switching the tabs. I've reviewed the changes and the changes are working fine.
I've reviewed the MR changes and dropped a suggestion regarding the title changes for Admin toolbar settings. Additionally, noticed one difference in the setting page title for Admin toolbar search config page. For Admin toolbar and tools config page, the page title has some inconsistency. For Admin toolbar setting config page title is 'Admin Toolbar settings', for tools it is 'Admin Toolbar Tools settings', however, for search it is 'Admin toolbar search settings'. As per my suggestion, the config page title for Admin Toolbar Search should be 'Admin Toolbar Search settings' to maintain the consistency for the modules. I've attached a screenshot for the changes to be made for Admin toolbar search config page title.
I'm keeping the issue status to Needs review for now, although the changes are working fine. If the suggested changes can be applied then we can change status to Needs work or else it be changed to RTBC.
I'm attaching the screenshots of before and after the changes of the applied MR as a patch for reference.
Thanks!
I'll look into this.
I'll review this.
Hi, I was able to replicate the issue and found that when any height value, let's say 42px has been passed in the "block--system-branding-block.html.twig" template height variable then on the logo the height attribute is rendering as height="'42px'"
instead of height="42px"
due to which the image height is not getting height as per its attribute value.
I've applied the provided MR !136 as a patch and it applied cleanly without any errors. After applying the patch, the height attribute issue has been fixed and it is rendering as height="42px"
which is the correct. Additionally, when no height value or height auto has been passed into height variable then the render logo "img" tag does not have height attribute. I'm attaching the screenshots of before and after patch applied issue fixes. As the MR is resolving the issue, hence moving the issue status to RTBC.
Thanks!
Hi, I've fixed the margin issue for Side-by-side paragraph when Grid option enabled. Please review the MR changes. I'm attaching the screenshots of before and after fixes of the issue for reference.
Thanks!
I'm looking into this.
Hi all, as the MR conflicts have been resolved hence I'm reviewing this issue as the status was not updated after resolving conflicts.
I've applied the provided MR as a patch and it applied cleanly without any errors. After applying the patch, the image stretch issue has been resolved and it is working fine. I'm attaching the screenshot of after fixes of the issue for reference.
Thanks!
Hi @mlahde, I tried replicating the issue as per the mentioned steps to reproduce however the issue didn't replicate. After dragging hierarchical field group fields to Disable state and saving the changes, the changes are getting saved properly. I didn't encounter any issue where the arranged items that moved to disable state is not getting save. I tried replicate it for different content types and choosing all the formatter options that are available for Field group. I've attached a video clip for your reference and as per the attached reference I think there's no such issue either related to the Gin theme or Field group module.
Tested on:
- Gin: 4.0.6
- Field Group: 8.x-3.6
- Drupal: 11.0.5 and 10.3.6
Dragging items can have hierarchy and motion in 4 directions in the Manage Display page of any content type. If you for example add a field group (Fieldset) the field dragging handle/icon automatically changes from "Drag to re-order" to "Move in any direction".
The drag handler icon is also getting changed as for the nested fields we can change the field structure i.e., the field can be move in any direction as per the requirement under different field group items.
@mlahde 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.
Hi, I've rebased the MR. Attaching the screenshots of before and after fixes of the issue for reference. Please review the changes. Additionally, I've applied the MR as a patch, and it applied cleanly without any errors. After applying the patch the changes are working fine.
Thanks!
I'm rebasing the MR as there's no response from @alok_singh.
Hi, I've resolved the conflicts in the merge request. Attaching the screenshots of before and after fixes of the issue for reference. Please review the changes. Additionally, I've applied the MR as a patch, and it applied cleanly without any errors. After applying the patch the changes are working fine.
Thanks!
I'm looking into it.
Changing the issue status to Needs review as the pipeline is passing all tests.
Hi @drakythe, I was able to replicate the raised issue. And when the module is enabled, then on visiting the /user/1
page getting the issue The "" entity type does not exist. in Drupal\Core\Entity\EntityTypeManager->getDefinition()
. However, the issue is not only limited to the /user/1 page, i.e., the user having the admin role, it occurring for any user role having the permission to access "Navigation +: Use edit mode"
. I've fixed the issue, please review the MR changes. I'm attaching the screenshots of the before and after fixes for reference.
Additionally, I faced another issue while using this module. After installing the module and enabling it I got the error shown in the attached screenshot: navigation-plus_issue.png → . Since it is not related to the current issue, I'm moving the issue status to Needs review.
Thanks!
Hi, I've fixed the indentation issue in the template file. Please review the changes. I'm keeping the issue status to Needs work as the pipeline is failing.
Working on it.
Hi @trackleft2, I've updated the form's new element name from "Enable Spaceless Filter" to "Remove whitespace between HTML tags". I think the new form element label will be easy for a normal user to understand. For more clarification, the user will have to go through the description provided for the element.
I've also updated a conditional check to the new element so as to show "Remove whitespace between HTML tags" only when configuring the field group for a node view page. Previously, the "Remove whitespace between HTML tags" option was available for both "Manage Form Display" and "Manage Display" although it was only intended for the node view to filter extra space when visiting the actual page content. However, it was also available for form display, which was not required. After the new changes, the "Remove whitespace between HTML tags" will only be available for "Manage Display" form when adding/updating a field group.
Since I've updated the code logic, I'm moving issue status back to Needs Review state from RTBC. I'm attaching the screenshots of the after fixes for reference. Please review the MR new changes.
Thanks!
Hi @shelane, could you please provide an update on the draft merge request MR !31 and let me know if there’s anything needed to move it forward?
Hi @trackleft2, I've replicated the issue as per the comment #8 🐛 Browsers add space to output because of extra space in templates. Active and confirm that the issue persists. The rendered element is getting some extra spaces when the "HTML Elements" is selected as formatter for the field group. I've tested the issue after applying the spaceless filter, and on applying it, the additional space got removed.
As suggested by @trackleft2, it would be better to provide an option to users to enable/disable the filter as per their need. Hence, I've added a new configuration option, named Enable Spaceless Filter
for the field group when the "HTML Element" option is selected. When "Enable Spaceless Filter" is checked, then the elements will be rendered through template applied with spaceless filter, and if not checked, then it will be rendered without spaceless filter applied.
I'm attaching screenshots of the before and after fixes of the issue for reference. Please review the MR changes.
Thanks!
Hi, I've applied the provided MR as a patch, and it applied cleanly without any errors. After applying the patch, when the logged-in user has no Access the Content overview page permission, then on clicking Back to Administration
/admin
page is opening and when the user has the permission then /admin/content
page is opening.
Previously, clicking the Back to Administration
opens 403 (Access Denied) when the user has no Access the Content overview page permission and opens /admin/content
page when access is provided.
As the provided MR fixes the issue as per the proposed resolution and the changes are working fine, hence moving the issue status to RTBC. Attaching the screenshot and video clips for reference.
Thanks!
Hi @rubymuse, I've fixed the rendering issue for the menu icons for which the user has no permission. Now the menu icons along the menu link will be rendered as per the logged user's role permission. I've allowed some administrative permission to the logged-in user role and now the menu icons are being shown as per the role as shown in the screenshot. I'm attaching screenshots of the before and after fixes of the issue. Please review the changes.
Thanks!
I'm looking into it.
Hi all, I've applied the provided MR as a patch and it applied cleanly without any errors. However, after applying the patch getting below error when configuring the mega menu.
The website encountered an unexpected error. Try again later.
Error: Call to undefined method Drupal\Core\Menu\MenuLinkDefault::getEntity() in Drupal\we_megamenu\WeMegaMenuBuilder::getMenuTree() (line 48 of modules/custom/we_megamenu/src/WeMegaMenuBuilder.php).
I've also tried applying the patch provided in the comment #4 ✨ Add translatable menu links to we_megamenu Active but getting below errors on applying:
Checking patch src/WeMegaMenuBuilder.php...
error: while searching for:
}
}
}
}
}
}
error: patch failed: src/WeMegaMenuBuilder.php:448
error: src/WeMegaMenuBuilder.php: patch does not apply
I'm attaching the screenshots of before and after of the issue for reference. As the MR is not resolving the issue hence moving back the issue to NW.
Hi @anybody @xpersonas, I've applied the latest changes in the MR as a patch and it applied cleanly without any error. On applying the patch, the issue mentioned in the comment
#31
✨
Possibility to set words as reject pattern
Needs review
has been resolved. However, when the module is installed and then the patch has been applied, then on visiting the module configuration page i.e., /admin/config/content/protected_forms
getting the below error:
The website encountered an unexpected error. Try again later.
InvalidArgumentException: "0" is an invalid render array key. Value should be an array but got a string. in Drupal\Core\Render\Element::children() (line 97 of core/lib/Drupal/Core/Render/Element.php).
But after reinstalling the module with the applied patch then the above issue has not been encountered.
After applying the patch, a new field Pattern matching has been added with options Check whole word instances and Check within strings. The newly added field provides the option to match the added pattern to match the whole or match only the pattern within the words. Both the provided field options are working fine with the forms and blocking the form submission as per the selected option in the field. I've attached the video clip for your reference and screenshots of before and after fixes as well.
As getting the mentioned error after applying the patch, hence keeping the issue to Need works.
Thanks!
Hi @megachriz @sourojeetpaul, I've reviewed the updated logo in the comment #21 📌 Create logo for Feeds Tamper for Project Browser Initiative Active and it looks good to me. The change in the tamper circle color now representing in the modification of the input and output data through the conversion on squre into circle indicating the module functionality well. As the latest proposed logo meets the requirement hence, moving the issue to RTBC.
Thanks!
Hi all, I replicated the issue and the issue persists. Upon adding any pattern in the Reject patterns field, the user is unable to submit the form due the any word containing the pattern added in the reject patterns field. I also applied the provided MR as a patch and it applied cleanly without any errors. However, after applying the patch getting below issue:
The website encountered an unexpected error. Try again later.
TypeError: Drupal\protected_forms\Form\ProtectedFormsForm::__construct(): Argument #1 ($module_handler) must be of type Drupal\Core\Extension\ModuleHandlerInterface, Drupal\Core\Config\ConfigFactory given, called in /app/web/core/lib/Drupal/Core/Form/ConfigFormBase.php on line 57 in Drupal\protected_forms\Form\ProtectedFormsForm->__construct() (line 28 of modules/custom/protected_forms/src/Form/ProtectedFormsForm.php).
Now on visiting the module configuration page getting the issue and also on submitting the form on which the protected form is enabled getting the issue shown in the screenshot. The provided MR still need works hence moving it to Needs work.
Thanks!
Hi @debrup, I've reviewed the proposed logo for the module as per the guidelines mentioned on the project browser. The logo meets the following requirements:
- The logo dimension is 512x512px and it does not have any animation.
- The proposed logo file size is within 10kb and the file format is png.
The logo image quality looks good however, the design at the top and bottom edged of the logo seems to be cutting at the edge "the square blue gear-box one at the top and bottom center". If there'll be some gap then it would be better. And also, as per the guidelines the proposed logo filename should be "logo.png" instead of Dubbot-fs8.png. Considering the above issues, I'm moving the issue status to needs work.
Thanks!
Hi all, I've also tried replicating the issue and the issue persists while using the 2.0.3 version of the module. However, the issue has been resolved in the development version 2.0.x in the issue #3395325 🐛 Deprecated function: Creation of dynamic property (with php 8.2) Fixed and the provided MR has been merged as well. It will get resolved once the maintainer published the new release of the module. As the related issue has been merged on the dev version hence, changing the issue status to duplicate.
Thanks!
Hi, I replicated the issue and can confirm that the issue persist. Currently, to visit/add any custom permissions to the Custom Permissions module configuration page no menu item has been provided. It is hard for a normal user to find the module configuration. To access the module configuration, the users have to visit the Extend page and then after the module configuration can be accessed which is not a good user experience.
I've applied the provided MR as a patch and it applied cleanly without any errors. After applying the patch, a new menu item named "Custom permissions" has been added under the "People" menu allowing user to access the module configuration page to enhance the user experience. I'm attaching the screenshots of before and after fixes for reference. As the MR is resolving the mentioned issue hence, moving it to RTBC. Hope to see this fixes in the new release of the module.
Thanks!
Hi all, I've tried replicating the issue, and it reproduced. I've applied the provided MR as a patch, and it applied cleanly without any errors. After applying the patch, the multivalued image field overlap issue got resolved successfully, along with the mentioned issues in the comment #17 🐛 Widget for multivalued file field overlap Active . Now, the multivalued image fields occupying the required space and are not blocking the usage of multivalued fields, as mentioned by @piridium.
Thanks to @mudasirweb and @sandip-poddar for resolving further designing issues while using this theme. Initially, the drag handler is center-aligned for the theme for all fields/tables, so it would be better if consistency is maintained for the theme. As changes made for the handler are not affecting the other functionality while using the theme, hence moving the issue to RTBC. I've attached the screenshots of before and after fixes for reference.
Thanks!
Hi @andy-blum, I've added the gap between the site logo and site title & slogan. Attaching the screenshot of the after fixes for your reference. Please review the changes.
Thanks!
Hi @shivam_tiwari, I can confirm that after applying the latest MR's changes as a patch the mentioned issues in the comment #19 has been fixed and it is working fine. I'm attaching the screenshot of after fixes for reference hence moving the issue status to RTBC. Thanks for the quick fixes.
Thanks!
Hi all, I've applied the provided MR as a patch and it applied cleanly without any errors. However, after applying the patch the issue does not get resolved as the menu attributes are not added to the menu item. Additionally, the added attributes value are being added to link attribute instead of being added to its individual attributes. I'm attaching screenshots of the before and after fixes along with the menu item configuration for the attributes. Hence, moving the issue to NW state.
Thanks!
Hi @rajat4u, I've applied the provided MR as a patch and it applied without any errors. After applying the patch, the new configuration has been provided to add rel attribute to the formatter for both Image and File type fields. On enabling the rel attribute for the field, the rel attribute is being added to the DOM for download link. The provided new rel attribute configuration is working fine. I'm attaching the screenshots of before and after fixes for the issues and moving it to RTBC.
Thanks!
Hi @sourojeetpaul, I've updated the MR. Please review the changes.
Thanks!
Hi @sourojeetpaul, I've added the configuration fields for social media icons. Additionally, I've added a field to Show/Hide social media title element. Please review the MR changes. Attaching the screenshots for your reference.
Thanks!
Working on it.
Hi, I've reviewed the proposed logos for the Module as per the provided review steps.
I liked the logo
jQuery-UI-Resizable.png →
provided in the comment
#5
📌
Project Browser: Create a logo for jQuery UI Resizable
Active
as it designed as the proposed logo is representing the resizing icon instead of crop. The logo proposed by @AaronDeutsch seems that the module's functionality is to crop instead on resizing.
The proposed logo meets the following requirement:
- The logo dimension is 512x512px.
- The file format is PNG.
- No animation has been used in the logo.
- Better image quality.
- The logo file size is within the 10kb.
- Logo representing the module functionality.
As the proposed logo is meeting all the requirements hence moving it to RTBC.
Thanks!
Hi, I've resolved the pipeline issues for MR !16 only as it is resolving the issue, and it has been verified by @selfirian and @leducdubleuet. The sidebar can also be hidden by clicking outside the sidebar region. Please review the MR changes and verify whether the changes are working fine or not.
Thanks!
I'm looking into the issue.
Hi @raynaldmo, follow the instructions provided in the block configuration by visiting the URL /admin/structure/block
to download the libraries. All the procedures have been mentioned there to use the other icon pack. I'm attaching the screenshot for your reference.
Thanks!
Hi, I'm also facing the same issue for tel link. The telephone link is also being shown as external link icon when Use Font Awesome icons instead of images
config is enable. I've applied the provided MR as a patch and it applied cleanly without any errors. I can confirm that the MR is resolving the issue successfully. I'm attaching the screenshots of before and after fixes of the issue.
Thanks!
Hi all! I've also replicated the issue following the steps to reproduce and found that the problem was caused by the use of the spaceless filter in the Twig templates. I have removed the filter from the affected templates, please review the MR changes. I'm attaching the screenshots of the before and after fixes for reference.
@doxigo, I have only removed the filter from the templates associated with the address module. Would you recommend removing the filter from all template files, or should we limit the changes to these specific ones?
Thanks!
Hi, I've applied the provided MR as a patch and it applied cleanly without any errors. After applying the patch the logo bottom cut issue has been resolved successfully. However, the current logo dimension rendered is large as compared to the previous one. If the image dimension is not an issue then moving the issue to RTBC. I'm attaching the screenshots of the before and after fixes for reference.
Thanks!
Hi @nk, I've tested the mentioned issue on 2.0.x-dev and when the number of slide is less than 2 getting a warning message as shown in the attached screenshot when saving/updating the node. And confirm that the changes are working fine, did not get any console errors when the slider has only one slide. I'm attaching the screenshot for your reference. As the changes are working fine moving the issue to RTBC.
Thanks!
Hi @dhruv.mittal, I've applied the provided MR as a patch and it applied cleanly without any errors. After applying the patch, when the anonymous user tries to access the admin page getting Access Denied along with the login form as configured through the module configuration. After logging, the user is redirected to the hit URL only. I'm attaching the video clips of the before and after fixes for reference. Moving the issue status to RTBC as the MR is resolving the issue.
Thanks!
Hi, I was also able to replicate the issue for seven theme on Drupal 10.3.6 and confirm that the issue still persists. I've applied the provided MR !13 as a patch and it applied cleanly without any errors. After applying the patch the hover effect issue has been fixed and now there's no issue while hovering the action buttons.
I've also tried replicating the issue mentioned by @ehsa_kundu in the comment
#27
🐛
In ui-dialog box at Views button hover effect is odd
Active
and confirm that the issue persists for the Delete
action button visibility issue occurring after clicking anywhere except the Delete button. On applying the patch this issue has also been fixed.
As the provided MR !13 fixing all the issues hence, moving it to RTBC. I'm attaching the video clips of before and after fixes for reference.
Thanks!