🇫🇷France @goz

goz → created an issue.

goz → created an issue.

goz → created an issue.

You are right, thanks !

goz → created an issue.

goz → created an issue.

Looks great.
What's about a test to confirm props attributes will keep its values in case keys exist in both.

    $build = [
      '#type' => 'component',
      '#component' => 'sdc_theme_test:my-card',
      '#props' => [
        'header' => 'Drupal.org',
        'attributes' => new Attribute([
          'foo' => 'bar',
        ]),
      ],
      '#attributes' => [
        'foo => 'third',
      ],
    ];

I think in this case, foo should still be bar.

And what's about attribute with array like classes for example ?

    $build = [
      '#type' => 'component',
      '#component' => 'sdc_theme_test:my-card',
      '#props' => [
        'header' => 'Drupal.org',
        'attributes' => new Attribute([
          'foo' => ['bar', 'ter'],
        ]),
      ],
      '#attributes' => [
        'foo' => ['quater'],
      ],
    ];

Issue has been followed to mondial relay development team.

Without news, i'll commit this, waiting a fix from the library.

You are right, thanks

Looks great to me, RTBC

Same issue for me.

#1 Option does not download library.

#2 Option load library but name folder is northernco--ckeditor5-anchor-drupal.

Adding in installer-paths the mapping solve the issue as explained in #31.
Warning, it has to be added before web/libraries/{$name}

    "extra": {
        "installer-types": [
            "bower-asset",
            "npm-asset"
        ],
        "installer-paths": {
(...)
            "web/libraries/ckeditor5-anchor-drupal": [
                "npm-asset/northernco--ckeditor5-anchor-drupal"
            ],
            "web/libraries/{$name}": [
                "type:drupal-library",
                "type:bower-asset",
                "type:npm-asset"
            ]
        },

Remove first the library before changes, then require it again.

composer remove npm-asset/northernco--ckeditor5-anchor-drupal
# Make changes in composer.json in sntaller-paths
composer require npm-asset/northernco--ckeditor5-anchor-drupal

Thanks to put widget back.
Glad to see we are moving to MapItem, good job !

I still have an issue, but we are almost there !

With my layout paragraph, i have a field storage for components (props & variant).
When i create my paragraph, content is stored correctly.
When i edit my paragraph, preview is good, but saving loose changes.

Sad to see widget disappear while it was working in previous commits :(

I think you are right @pdureau, MapItem could do the job BUT we have to be sure it do the job without having to tweak it and it does not seem to be really used

Something is wrong with the last commits, my submission is not stored anymore in field. FYI, i also use last commit from https://www.drupal.org/i/3511027 →

goz → created an issue.

The fix in action :

goz → created an issue.

Weight of fields is different between configuration and display.

In configuration :

In display :

Thanks @Christian, i miss that.

MR has to be rebased

MR has to be rebased.
Merge is currently in conflict due to 📌 [2.0.1] Make Componenent element builder alterable Active https://git.drupalcode.org/project/ui_patterns/-/commit/6ee5db3b2d5b2c3e...

goz → created an issue.

@Christian, i think you miss my comment #6

Hi Christian. Good work on this !
I have an issue installing this module.
Looks like something is missing in entity type configuration, which do config_translation module complain.

[10-Mar-2025 09:14:07 UTC] PHP Fatal error:  Uncaught Error: Call to a member function getPath() on null in /var/www/html/web/core/modules/config_translation/src/ConfigNamesMapper.php:247
Stack trace:
#0 /var/www/html/web/core/modules/config_translation/src/Routing/RouteSubscriber.php(39): Drupal\config_translation\ConfigNamesMapper->getOverviewRoute()
#1 /var/www/html/web/core/lib/Drupal/Core/Routing/RouteSubscriberBase.php(37): Drupal\config_translation\Routing\RouteSubscriber->alterRoutes(Object(Symfony\Component\Routing\RouteCollection))
#2 [internal function]: Drupal\Core\Routing\RouteSubscriberBase->onAlterRoutes(Object(Drupal\Core\Routing\RouteBuildEvent), 'routing.route_a...', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))

Adding definition of edit_form in routing file fixes it

entity.sdc_component_form_display.edit_form:
  path: '/admin/structure/component/{sdc_component_id}/form-display/{form_mode_name}/edit'
  defaults:
    _entity_form: 'sdc_component_form_display.edit'
    _title: 'Edit a component display'
  requirements:
    _permission: 'administer sdc_component_form_display'

g4mbini → credited goz → .

goz → created an issue.

goz → changed the visibility of the branch 3.0.x to hidden.

goz → created an issue.

goz → created an issue.

#89 works with 3.0 but use previous fix based on "Any".
MR add the adjustmentType which should be kept for 3.0

But we should also support denormalizer implementing DenormalizerInterface and adding denormalize method, so we can create order item with adjustment from jsonapi.

  /**
   * {@inheritdoc}
   */
  public function denormalize($data, $type, $format = NULL, array $context = []) {
    if (isset($context['field_type']) && 'commerce_adjustment' === $context['field_type']) {
      if (isset($data['amount'], $data['amount']['number'], $data['amount']['currency_code'])) {
        $data['amount'] = new Price($data['amount']['number'], $data['amount']['currency_code']);
      }
      return new Adjustment($data);
    }

    return $data;
  }

#89 works great on Commerce 3.0

goz → created an issue.

goz → created an issue.

Hi, i have the same issue using ui_suite_bootstrap + layout_paragraphs + mercury_editor

In node edition with paragraph layout, start a new paragraph, choose a component (+ button), add your section paragraph in the first dialog, second dialog opened and error is logged in console

goz → created an issue.

My bad, the module was in a strange state. This does not match with 5.1.x version.

goz → created an issue.

Référence aux 2 Pull requests :

https://github.com/GouvernementFR/dsfr/pull/943
https://github.com/GouvernementFR/dsfr/pull/951

goz → created an issue.

They document it by comment, but it doesn't make it good.

For my point of view, JSON schema of a component describe how the component is build and rules applying to it.
We should rely on it, and not report some stuff in twig for something like default values, especially when the implementation is not that hard.

If i make a documentation based on component definitions, UX will be very bad to say for each default value (be careful, this default value is not a default value for the component but only for form component). Form configuration is one of the way to use components. All the ways to implement components should follow the same rules.

I understand you are aligned with how SDC work, so it's more an issue with this core module at first.

I guess waiting fir this, theme maintainers will have to keep this in mind and report themselves the default logic into their twig files. One little missing piece of code, need to be care by many sub-projects.

Digging, i think the issues comes from src/Template/TwigExtension.php

  /**
   * Normalize props (and slots).
   *
   * This function must not be used by the templates authors. In a perfect
   * world, it would not be necessary to set such a function. We did that to be
   * compatible with SDC's ComponentNodeVisitor, in order to execute props
   * normalization before SDC's validate_component_props Twig function.
   *
   * See ModuleNodeVisitorBeforeSdc.
   *
   * @param array $context
   *   The context provided to the component.
   * @param string $component_id
   *   The component ID.
   *
   * @throws \Drupal\Core\Render\Component\Exception\InvalidComponentException
   */
  public function normalizeProps(array &$context, string $component_id): void {
    $component = $this->componentManager->find($component_id);
    $props = $component->metadata->schema['properties'] ?? [];
    foreach ($context as $variable => $value) {
      if (isset($component->metadata->slots[$variable])) {
        $context[$variable] = SlotPropType::normalize($value);
        continue;
      }
      if (!isset($props[$variable])) {
        continue;
      }
      $prop_type = $props[$variable]['ui_patterns']['type_definition'];
      $context[$variable] = $prop_type->normalize($value, $props[$variable]);
      if ($context[$variable] === NULL) {
        unset($context[$variable]);
      }
      if (isset($props[$variable]['ui_patterns']['prop_type_adapter'])) {
        $prop_type_adapter_id = $props[$variable]['ui_patterns']['prop_type_adapter'];
        /** @var \Drupal\ui_patterns\PropTypeAdapterInterface $prop_type_adapter */
        $prop_type_adapter = $this->adapterManager->createInstance($prop_type_adapter_id);
        $context[$variable] = $prop_type_adapter->transform($context[$variable]);
      }
    }
    // Attributes prop must never be empty, to avoid the processing of SDC's
    // ComponentsTwigExtension::mergeAdditionalRenderContext() which is adding
    // an Attribute PHP object before running the validator.
    // Attribute PHP object are casted as string by the validator and trigger
    // '[attributes] String value found, but an object is required' error.
    $context['attributes'] = $context['attributes'] ?? [];
    $context['attributes']['data-component-id'] = $component->getPluginId();
  }

  /**
   * Preprocess props.
   *
   * This function must not be used by the templates authors. In a perfect
   * world, it would not be necessary to set such a function. We did that to be
   * compatible with SDC's ComponentNodeVisitor, in order to execute props
   * preprocessing after SDC's validate_component_props Twig function.
   *
   * See ModuleNodeVisitorAfterSdc.
   *
   * @param array $context
   *   The context provided to the component.
   * @param string $component_id
   *   The component ID.
   *
   * @throws \Drupal\Core\Render\Component\Exception\InvalidComponentException
   */
  public function preprocessProps(array &$context, string $component_id): void {
    $component = $this->componentManager->find($component_id);
    $props = $component->metadata->schema['properties'] ?? [];
    foreach ($context as $variable => $value) {
      if (!isset($props[$variable])) {
        continue;
      }
      $prop_type = $props[$variable]['ui_patterns']['type_definition'];
      $context[$variable] = $prop_type->preprocess($value, $props[$variable]);
    }
  }

None of the 2 methods take default props values.

goz → created an issue.

goz → created an issue.

goz → created an issue.

Definitely, a d there is already a follow up on icon finder port on core

Tests fail because now options are TranslatableMarkup and not string anymore

Trying to add a card on layout builder with ui_patterns2 and ui_suite_dsfr, i have the following error generating /ui_styles/stylesheet with this patch

InvalidArgumentException: $string ("0") must be a string. in Drupal\Core\StringTranslation\TranslatableMarkup->__construct() (line 132 of core/lib/Drupal/Core/StringTranslation/TranslatableMarkup.php).

Drupal\ui_styles\Definition\StyleDefinition->t(0) (Line: 156)
Drupal\ui_styles\Definition\StyleDefinition->getOptionsAsOptions() (Line: 217)
Drupal\ui_styles\Service\StylesheetGenerator->getThemeStyleOptions('ui_suite_dsfr') (Line: 68)

ui_suite_dsfr has some style options with int, not string

  options:
    fr-m-0: 0

Proposed resolution

Cast to string in \Drupal\ui_styles\Definition\StyleDefinition::getOptionsAsOptions()

        $options[$option_id] = $this->t((string) $option);

Duplicate ✨ Make style definition options translatable Active

My bad... i don't know how i check this but i was wrong.

So close duplicate 🐛 Does not cast options label in styles definitions Active and fix this patch

goz → created an issue.

Looks like this issue has been fixed on 1.1.x. I can see changes of this patch in currnet code.

Looks like tests fails for another reason but cannot launch it again.

@mogtofu33 you set "Needs work" status because of failing tests or you are waiting for another changes ?

In \Drupal\Core\Theme\Icon\IconFinder::processFoundFiles()

        'source' => $this->fileUrlGenerator->generateString(str_replace($this->appRoot, '', $file_absolute_path)),

does not take care of base_path

Here is a piece of code to check logic.

<?php
// Hardcode base path, i want Drupal root with subfolder, so http://domain.tld/dir is my drupal root base path.
$GLOBALS['base_path'] = '/dir/';

// Check current code, $this->appRoot does not end by /.
$appRoot = '/var/www/html';
echo(\Drupal::service('file_url_generator')->generateString(str_replace($appRoot, '', '/var/www/html/core/modules/system/tests/modules/icon_test/icons')));
// Result is : /core/modules/system/tests/modules/icon_test/icons

echo ("\n");

// Add / to the end of appRoot.
echo(\Drupal::service('file_url_generator')->generateString(str_replace("{$appRoot}/", '', '/var/www/html/core/modules/system/tests/modules/icon_test/icons')));
// Result is : /dir/core/modules/system/tests/modules/icon_test/icons

We could check first $this->appRoot does not already end by / before adding it.

goz → changed the visibility of the branch 2670798-nojsajax-route-parameter-10.4.x to hidden.

I agree the idea to have specific access for Ajax should be a good idea, except reading actual code, this does not provide more or less feature, only duplicate code.

Current patch does not work anymore, and taking care of #60 make me wonder if all this duplicate stuff is really needed.

Why we do not need _csrf_ajax_token ?

Using _csrf_ajax_token, we have to create both RouteProcessorCsrfAjax and CsrfAjaxAccessCheck which do exactly the same thing as _csrf_token.

_csrf_exclude_parameters is enough to solve the issue, like it's already in use in https://git.drupalcode.org/project/vote_up_down/-/blob/8.x-1.x/vud.routi...

So instead of adding both _csrk_ajax_token and/or _csrf_exclude_parameters, the second one should be enough for less code.

I put this in MR instead of keeping on old patchs.

goz → created an issue.

goz → created an issue.

Duplicate 📌 Accessibility: better skip link Active , my bad

goz → created an issue.

There is no base_url but base_path().

Take a look at \Drupal\Core\File\FileUrlGenerator::doGenerateString()

protected function doGenerateString(string $uri, bool $relative): string {
    // Allow the URI to be altered, e.g. to serve a file from a CDN or static
    // file server.
    $this->moduleHandler->alter('file_url', $uri);

    $scheme = StreamWrapperManager::getScheme($uri);

    if (!$scheme) {
      $baseUrl = $relative ? base_path() : $this->requestStack->getCurrentRequest()->getSchemeAndHttpHost() . base_path();
      return $this->generatePath($baseUrl, $uri);
    }
    elseif ($scheme == 'http' || $scheme == 'https' || $scheme == 'data') {
      // Check for HTTP and data URI-encoded URLs so that we don't have to
      // implement getExternalUrl() for the HTTP and data schemes.
      return $relative ? $this->transformRelative($uri) : $uri;
    }
    elseif ($wrapper = $this->streamWrapperManager->getViaUri($uri)) {
      // Attempt to return an external URL using the appropriate wrapper.
      $externalUrl = $wrapper->getExternalUrl();
      return $relative ? $this->transformRelative($externalUrl) : $externalUrl;
    }
    throw new InvalidStreamWrapperException();
  }

I don't understand why you talk about relative path to the module. In any case, in \Drupal\ui_icons_backport\IconFinder::processFoundFiles(), $this->appRoot is the root path to drupal in system, so for example : /var/www/html/web.

$file_absolute is absolute path on system, so /var/www/html/web/modules/contrib/your_module/assets/dist/img/my_image.svg for example.
If you replace $this->appRoot by empty and pass modules/contrib/your_module/assets/dist/img/my_image.svg to \Drupal\Core\File\FileUrlGenerator::doGenerateString(), this will return relative path modules/contrib/your_module/assets/dist/img/my_image.svg to the file, except in case we are using a specific base_path() other than /, url will still begin by /modules, but this path does not exists in nginx/apache config because we are waiting for different base_path.

Do you have an example where my fix broke something ?
I try differents libraries and no issues

goz → created an issue.

Using another media widget like entity_browser display buttons correctly

goz → created an issue.

My bad, i reproduce in D10.4 and D10.3.

In ui_style.routing.yml file, route is defined with .css extension

ui_styles.stylesheet:
  path: '/ui_styles/stylesheet.css'
  defaults:
    _controller: 'Drupal\ui_styles\Controller\StylesheetController::generateStylesheet'
    _title: 'UI Styles CSS generator'
  requirements:
    _permission: 'access content'

In Nginx, the following configuration add ?q= because of .css extension.

    location @rewrite {
        rewrite ^/(.*)$ /index.php?q=$1;
    }

    location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|eot|ttf|woff|woff2)$ {
        try_files $uri @rewrite;
    }

So in web/modules/contrib/redirect/src/EventSubscriber/RouteNormalizerRequestSubscriber.php, at the end of onKernelRequestRedirect method, redirect_uri is

/ui_styles/stylesheet.css?q=/ui_styles/stylesheet.css&prefix....

so redirect module redirect to this url.

?q should not be there, but it's caused by nginx configuration and because it's not a real CSS file but generated on the fly by controller.

Renaming controller path to something without .css extension solve the issue

I confirm the issue with D11, and i'm using :
ui_patterns : 2.0.0-rc2
ui_styles: 8.x-1.15

After applying patch, i can add section to my layout.

goz → created an issue.

As pointed on my topic, composer require works, but Drupal module install doesn't

goz → created an issue.

There was no need to push other commits on MR, only relaunch the failing test