Een hart voor de Drupal Community

Problem/Motivation

When enabling the setting `show_groups_in_menu`, in combination with admin_toolbar, the `Admin > Content > Site Settings` link gets children for each configured site settings group.

When using the Navigation menu instead, a user needs to select "Content" in the navigation, and then use the "Site settings" tab on that page.

We would like to more easily reach the site settings, including group child links, if enabled.

Moreover, when the `show_groups_in_menu` setting is enabled, the group menu items are added randomly in the main navigation tree (between "Structure", "Appearance", etc.. links), which looks clunky.

Steps to reproduce

- Install navigation core module - No site settings are available.

Proposed resolution

The Navigation module provides a "Content" menu, where it places the default content links ("Create", "Content", "Media", ... When this menu exists, add the "Site settings" + optional group children to it.

Remaining tasks

Create MR

User interface changes

Before:

After

Problem/Motivation

Alter logic does not seem to work anymore in Drupal 11.1, since hooks are now OOP.

Steps to reproduce

- Install Drupal 11.1 (I used 11.1.2) - Go to `/admin/config/user-interface/navigation-block` - Click "Add block" in sidebar - Error is triggered, because `navigation_plugin_filter_block__layout_builder_alter()` no longer exists.

Proposed resolution

Call `\Drupal\navigation\Hook\NavigationHooks::pluginFilterLayoutLayoutBuilderAlter()` for newer Drupal versions

Remaining tasks

- Update code with backwards compatibility layer

Merged latest changes from 9.0.x into MR branch, seems to apply and work fine on my end. Setting back to 'Needs review' so someone else can have a test before it's merged!

Problem/Motivation

site_settings.routing.yml contains a route `entity.site_setting_group.settings`, with path `admin/structure/site-setting-group` which triggers a fatal error when called in the browser. I suppose this is a leftover route that is no longer in use?

Steps to reproduce

Go to `admin/structure/site-setting-group` and see error.

Proposed resolution

Remove the route, if it's no longer in use.

randalv made their first commit to this issue’s fork.

Randal added a comment on drupal.org: Some twig functions aren't aware of the currently active language

Problem/Motivation

When using the core Navigation module, the menu item "Manage site settings" is not reachable. Because it has a child menu item, it is considered a grouping menu item, and is not clickable. To reach it, you would need to click the "Manage Site Settings Group" link first, then through the breadcrumb go to its parent.

See screenshot:

Steps to reproduce

Install core Navigation menu, and try to go to "Manage site settings"

Proposed resolution

Use a generic grouping parent item that uses `'\Drupal\system\Controller\SystemController::systemAdminMenuBlockPage'` and add 2 child items under it, one for managing site setting entities, and the other for managing site setting entity groups. Both will then be reachable via the Navigation module.

Remaining tasks

Create a MR

User interface changes

The "Structure > Manage site settings" breadcrumb will become "Structure > Manage site settings > Site settings" or similar.

API changes

/

Data model changes

/

Problem/Motivation

I have an entity type that uses form modes, and is translatable. In version 3.0.0 I was able to translate these entities, by loading them in the appropriate language, and clicking the right form mode manager tab.

E.g. when my original entity has a form mode "Advice", I could go to `/en/{entity_type}/123/edit/advice` and configure the original entity. When I want to set up a translation in Dutch, I'd go to `/nl/{entity_type}/123/edit/advice` and edit the translation of that entity.

In version 3.1.0 that no longer seems to work.

Upon inspecting the changes between 3.0.0 and 3.1.0, I saw a commit related to content translation, which seems to break this functionality. Upon inspection of the code, I noticed the following:

- It seems node-specific in some parts of the code, so wouldn't work with my custom entity - It only adds a "content translation add" route, not an edit route. I'm not sure if that is by design, because the edit path should keep working as I mentioned above (it doesn't for me at least), or if that's been forgotten.

Merge request added!

I also took the liberty to remove what I assume was an orphaned `var_dump` 😇

A little correction from my end, all the functions that call the "renderSiteSettings"-method in the extension class do seem to render with the correct language context, but the other two functions (`site_setting_field` && `site_setting_entity_by_name`) specifically check for a langcode and load that translation, so those should be altered I think.

I'll add a MR for it.

Hi,

First of all thanks for a great module, it works like a charm. I do have a small feature request, it would be nice if the twig function 'site_setting_field(..)' was aware of the current language by default if no language code was provided.

Problem/Motivation

Some twig functions aren't aware of the current language right now. Currently I have to inject the langcode to use it as follows: {{ site_setting_field('[id]', '[field]', '[view_mode]', langcode) }} Instead of ideally just: {{ site_setting_field('[id]', '[field]') }}

That's because Drupal\site_settings\Twig\TwigExtension::singleSiteSettingsByNameAndField does the following:

if ($langcode && $site_setting->hasTranslation($langcode)) {
  $site_setting = $site_setting->getTranslation($langcode);
}

Proposed resolution

Let's make it so that if no langcode was provided, the current language id is given. I suppose the above code snippet would have to become:

$langcode = $langcode ?? $this->languageManager->getCurrentLanguage()->getId();
if ($site_setting->hasTranslation($langcode)) {
  $site_setting = $site_setting->getTranslation($langcode);
}

(The language manager will need to be injected in the class still)

randalv created an issue. See original summary.

Somebody, anybody?

I'm testing out the possibilities of this theme currently. I'm wondering if there is support by default for a responsive menu, because I can't seem to get it working.

I've placed a regular Menu block in the navbar_center region, as well as a "Menu" block provided by UI Patterns module.

From config alone I can't seem to get a responsive menu working, so I might have to strip out and replace some things in the template - but I'm checking first if I'm not missing something obvious.

It looks like the whole navbar component doesn't seem to be very responsive as a whole. I've placed a logo in navbar start, menu in navbar center and language switcher in navbar end, but in mobile view I only see part of the main menu..

Thanks for all your hard work in integrating Daisy UI with UI Suite!

With the current MR changes, I run into a plethora of issues where the value is set to an empty array or null or something... Not sure why this happens.

Causes issues on basically any entity form for me, for example when saving a new taxonomy term, then the 'weight' value is set to null and gives a WSOD.

Problem/Motivation

See https://www.drupal.org/node/3268441: method image_filter_keyword is deprecated.

Proposed resolution

Update code.

Would be nice to get a D11 release out there. 🙏

Upgrading to 3.0.0-beta1 fixed the issue. Thanks!

Problem/Motivation

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Fons added a comment on drupal.org: Error: Call to undefined function layout_builder_form_entity_form_display_edit_form_alter() in layout_builder_at_form_entity_form_display_edit_form_alter() (line 56 of /web/modules/contrib/layout_builder_at/layout_builder

Fons added a comment on drupal.org: Error: Call to undefined function layout_builder_form_entity_form_display_edit_form_alter() in layout_builder_at_form_entity_form_display_edit_form_alter() (line 56 of /web/modules/contrib/layout_builder_at/layout_builder

Problem/Motivation

The module seems to call a function that doesn't exist anymore in Drupal 11.

Steps to reproduce

1. Install a Drupal 11 website
2. Install the latest layout_builder_at module (Mine is patched see below)
3. Create a block type to use in layout builder
4. Go to the form display of this block, the error hits

Patch:

"drupal/layout_builder_at": {
    "#3431569: Drupal 11 compatibility": "https://www.drupal.org/files/issues/2024-10-18/D11-compatibility-3431569-8.patch"
},

Remaining tasks

Look for a solution for the code at layout_builder_at.module line 56:

if ($hide) {
    layout_builder_form_entity_form_display_edit_form_alter($form, $form_state);
}

f0ns created an issue. See original summary.

Bram Goffings added a comment on drupal.org: Fatal error when testing drupal 11

Bram Goffings added a comment on drupal.org: Fatal error when testing drupal 11

Can confirm the issue persists and is solved by the patch, thanks!

I had the same issue and the MR fixed it for me in the form of a patch (in attachment for others that also need it).

Hi @julianriemersma,

Sorry for the delay, I'll try to take a look into this ASAP. I think something else might be wrong still, it's normal the authenticated role can't be chosen (since you *need* that role to use Masquerade by Role), but it shouldn't deny access when trying to masquerade as authenticated.

I think I've found a solution but need to do more testing. Will keep you updated.

@marcus thank you, this answer is really helpfull. As we probably can't fix this for all providers, we probably will create a seperate module.

How would you block the requests when the limits are reached?

In the world of agencies it's not uncommon that the web agency manages the API keys of the projects of their clients. The clients pay for a fixed fee and they have a limited amount of API requests for that specific key.

OpenAI, gemini, ... all have a system of spending limits, but they don't have a system to restrict limits per API key. This makes it hard for an agency to manage abusers.

It would be really helpfull if you could restrict the number of API calls for a specific API key. API calls and billing are not 100% correlated but it's enough to monitor and limit the usage within a project.

On top of that, some kind of overview with the number of API calls/month would be needed as well. We could provide some resources to help building this system but it would be nice if we could have input and guidance from the maintainers and the community.