Een hart voor de Drupal Community

Sven Decabooter added a comment on drupal.org: Removing and adding translations causes stale data to be shown when editing

I can confirm this issue, and the added patch fixes it. Committed now.

Sven Decabooter added a comment on drupal.org: Removing and adding translations causes stale data to be shown when editing

Problem/Motivation

Currently the project depends on config_split 1.x, with a "develop" split configured. The Belgian (and other) websites are using config split in order to split of language-specific configuration (e.g. enable FR language for the .be website, which should not happen in the general project).

I propose to update the config_split module to its version 2.x as soon as possible, because that introduces the concept of patching. Rather than splitting a whole config YML file, config_split only puts the changes in the split directory.

Steps to reproduce

The default language.negotiation.yml looks like this:

session:
  parameter: language
url:
  source: path_prefix
  prefixes:
    en: en
    '': null
  domains:
    en: ''
selected_langcode: site_default

When using config_split 1.x, we split the whole file. If later the "session" or "selected_langcode" property would change in the default config, it will not propagate to the split off configurations.

Proposed resolution

Use config_split 2.x, so the above configuration would be stored in config/drupal_be split folder as follows:

adding:
  url:
    prefixes:
      nl: nl
      fr: fr
      de: de
    domains:
      nl: ''
      fr: ''
      de: ''
removing:
  url:
    prefixes:
      '': null

This alters only the prefixes content, nothing else.

If we decide to let all spin-off sites use config_split, it will be a lot more maintainable this way.

Remaining tasks

- Create MR to update to config_split 2.x + update existing splits

Problem/Motivation

PHPCS reports various issues with this module.

Proposed resolution

- Add Gitlab CI to automate code quality checks - Fix reported issues

Problem/Motivation

When setting up the token with `without-some-parameters` or `with-some-parameters` options, we are getting an error on non-existing pages, which should just render a 404 page instead:

TypeError: array_intersect_key(): Argument #1 ($array) must be of type array, null given in array_intersect_key() (line 104 of modules/contrib/token_url_plus/token_url_plus.module).

Steps to reproduce

- Install this module + Metatag (for example) - Set a global metatag (e.g. canonical URL) that uses the following token: "[current-page:url-with-query:with-some-parameters:page]" - Go to the path "/path-does-not-exist"

Proposed resolution

- Make sure the $query variable is an array, before performing array-operations on it.

Bram Goffings added a comment on drupal.org: Automated Drupal 10 compatibility fixes

Bram Goffings added a comment on drupal.org: Fix DomainMenuAccessControlHandler::checkAccess

Patch #2 works here as well.

@berdir is it possible to roll a new release?

As per this issue / comment: https://www.drupal.org/project/select2/issues/3474793#comment-15991481 Is this still active/relevant?

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.

randalv created an issue. See original summary.

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)

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