Drupal CMS

esmoves credited svendecabooter.

I was trying to add my own custom theme, and followed the following process:

- Create a new theme based on the starterkit - as per `starterkits/ui_suite_daisyui_starterkit/README.md` - Run the `npm install` and `npm run build` commands - Add new theme file in `mytheme/css/themes/fancy.pcss.css` with contents like this:

@plugin "daisyui/theme" {
  name: "fancy";
  default: true;
  prefersdark: false;
  color-scheme: "light";
  --color-base-100: #FAF7F2;
  ...
}

- Add file `mytheme/mytheme.ui_skins.themes.yml` with contents like this:

# No value because same as plugin ID.
fancy:
  label: "Fancy"
  label_context: "color"
  key: "data-theme"
  target: html

- Run the `npm install` and `npm run build` commands again - Go to `/admin/appearance/settings/mytheme` and select the "Fancy" theme from the "Theme" dropdown

The CSS file for fancy theme is included in the HTML output, and my tag contains `data-theme="fancy". I can't see any of the colors though...

Is this because I use hex color codes, instead of oklch()? Or anything else in the process I missed?

And another apparent oopsie, issues like this already exist 🤦🏻‍♂️

I'll link them and mark it duplicated, apologies.

Sven Decabooter added a comment on drupal.org: Conflict with core system/base hidden.module.css

Randal added a comment on drupal.org: Variation cache error when enabling the "domain"-module.

Sven Decabooter added a comment on drupal.org: Conflict with core system/base hidden.module.css

Problem/Motivation

I have an element that needs to be hidden on smaller screens, and shown on larger ones. So I have set it up with the following classes: <div class="hidden lg:block">Show this only on large screens.</div>

The file `css/components/hidden.module.css` in Drupal core's system/base library also contains a definition for .hidden classes, and seems to take precedence over the DaisyUI / Tailwind logic.

The result is: my block is not shown on larger screens, even though that is desired.

Proposed resolution

Override the hidden.module.css logic, to avoid this behaviour for .hidden classes. Other functionalities provided by this CSS file should remain intact.

svendecabooter created an issue. See original summary.

Apologies, I forgot this has now been included in core and the issue queue has moved there. Changing project + component.

Problem/Motivation

When enabling the core "Navigation" module and contributed "Domain" module, I seem to run into this error:

The complete set of cache contexts for a variation cache item must contain all of the initial cache contexts, missing: user.site

I saw in the cache contexts that the exact ones listed in the default value of the container parameter `render.config:required_cache_contexts` were used, but when looking at the NavigationRenderer, they're hardcoded into it. If I replace the hardcoded contexts list on line 133 in the NavigationRenderer:

$build[$delta]['#cache']['contexts'] = ['user.permissions', 'theme', 'languages:language_interface'];

With this code:

$renderer_config = \Drupal::getContainer()->getParameter('renderer.config');
$build[$delta]['#cache']['contexts'] = $renderer_config['required_cache_contexts']
  ?? ['user.permissions', 'theme', 'languages:language_interface'];

Then it seems to work (since I've added `user.list` as a required context in my services file).

Steps to reproduce

- Start on an empty Drupal 11 website - Enable the Navigation and Domain modules

Proposed resolution

I think, using the container parameter renderer.config:required_cache_contexts instead of the hardcoded list: - user.permissions - theme - languages:language_interface

Should be fine? Unless I completely misunderstand this functionality.

Sven Decabooter added a comment on drupal.org: Add in tenths of a second

Sven Decabooter added a comment on drupal.org: Better output format support

svendecabooter created an issue.

Problem/Motivation

Fix PHPCS / PHPStan issues, as reported by Gitlab CI.

Sven Decabooter added a comment on drupal.org: Automated Drupal 11 compatibility fixes for hms_field

Sven Decabooter added a comment on drupal.org: Use PHP attributes instead of annotations

Thanks for your work!

Sven Decabooter added a comment on drupal.org: Support OOP hooks

Problem/Motivation

Currently, in the FilesLogController, the overview of logs and canonical log pages are built completely in the controller with inline render arrays and inline templates. Ideally this should just follow the Drupal way of using templates.

Proposed resolution

Rework the controller to render only templates that can be overridden elsewhere.

Rebased MR on the latest 1.0.x code. Not sure how to fix the failed pipeline though...

Sven Decabooter added a comment on drupal.org: Layout Builder translation issues

Thanks for the summary and both for your work on this!

I created a MR to add this functionality. For the selectable prefill attributes for form elements I didn't add an option, as this needs to be configured per field widget manually anyway, AFAIK.

Attached is also a patch version of the MR changes, for Composer based workflows.

Sven Decabooter added a comment on drupal.org: Allow selection of which features to activate

svendecabooter created an issue. See original summary.

Problem/Motivation

To improve flexibility for people using this module, it would be good to allow the option to disable some of the features this module provides (although probably not recommended).

For example, one could choose to disable the HTML5 validation that is added to all forms, and selectively decide which forms can have HTML5 validation (e.g. Webform module already provides a toggle for this - which is overridden by this module).

Proposed resolution

Provide a configuration schema and settings page to select which features to enable (defaults to everything enabled).

Remaining tasks

Create a MR with this functionality

User interface changes

An extra settings page would be added. No other UI changes needed.

API changes

/

Data model changes

/

That looks like a great approach to add translation options to recipes.

I don't have strong feelings regarding the exact syntax, but personally prefer the options where the parameters are named explicitly (so 2nd or 3rd).

I'm assuming the 3rd could also be written as

   form:
      '#type': email    
      '#title': !translate { 
        string: 'Feedback form email address', 
        context: 'Third context' 
      }

As it would avoid having everything on 1 line, especially with larger strings you would need to do some horizontal scrolling in your IDE. Come to think of it, then I probably prefer the 2nd version, as it avoids the extra brackets as well..

Sven Decabooter added a comment on drupal.org: Automated Drupal 11 compatibility fixes for resend_register_mail

Thanks for the notice. Since this module has more usage and already has some releases, I think it would make sense to deprecate your module, and provide its extra functionalities in this module. I'd be happy to review merge requests to get extra functionality in.

Sorry for the delay. Had a bit of time to review this now.

This does allow the user to select the type of message to send, but only when the action plugin is triggered. When editing a user and clicking the button shown on the form, the old behaviour is still used. So that introduces 2 different behaviours, according to the path you take to trigger it.

Also, would it be an option to reuse the functionality that now decides in code which mail to send, to provide a default value to the user? Some editorial users might not know which email is the most appropriate, so guiding them in the right direction would be good.