🇪🇸Spain @idiaz.roncero

+1 to this. I also fell on the misleading slots===blocks (or "blocks is the recommended and only implementation for slots") comparison, and other colleagues as well.

It will be much useful to emphasize that you can implement slots by using includes and embeds, and the tradeoffs and benefits of each approach.

idiaz.roncero → created an issue. See original summary → .

There's a particular Field Widget that is not intsanceof DateTimeWidgetBase and shoudl also benefit from this extension: TimestampDatetimeWidget, especially used for the "Authored on" (created) base field.

/**
 * Plugin implementation of the 'datetime timestamp' widget.
 */
#[FieldWidget(
  id: 'datetime_timestamp',
  label: new TranslatableMarkup('Datetime Timestamp'),
  field_types: [
    'timestamp',
    'created',
  ],
)]
class TimestampDatetimeWidget extends WidgetBase {

I have tried to add this to the whitelist and it works perfectly out of the box, as the widget renders almost equally as other Date widgets. I propose to update the MR with this addition.

@justcaldwell yep, that might work for the CKEditor whitelisting part, but the problem I'm reporting is related with the very Drupally filter_html rules, this is, the elements: <* class="my whitelisted classes"> part.

idiaz.roncero → created an issue.

Moving to needs review.

I've created a MR. Instead of whitelisting all attributes as it was proposed for CKE4, I've added stricter rules that (when possible) will whitelist only the specific classes and data-attributes used on this plugin.

idiaz.roncero → created an issue.

idiaz.roncero → created an issue.

Created MR that uses the Source plugins to check for the Image plugin and the actual source field name.

idiaz.roncero → created an issue.

dan2k3k4 → credited idiaz.roncero → .

Closing, i've seen it fixed on 1.x-dev

idiaz.roncero → created an issue.

Your URL starts with http://default/, which might be the problem - it looks like it won't be accessible by Storybook.

This might be related to the way the `drush storybook:generate-stories` is run. Are you running it from inside a container (docker, ddev, lando)? I'm facing this same issue: the URL generated does include a "default" part instead of the site URL.

Bum! MR created.

@e0ipso if you see it fit, feel free to skip credit for this change, as it could be considered a issue that might not receive credit →

idiaz.roncero → created an issue.

Please see this comment 🐛 Reset button does not use AJAX Needs work for a quick workaround that just re-enables the Drupal core behavior - to avoid AJAX on Clear Filter buttons.

With facets 3.x we are facing the exact opposite as cajewell said: exposed form in a block is reset when using clear filters; but view content area results are not - they keep the old filters applied.

We have found this to be not working with facets. Didn't test it with other exposed filters.

Basically, the Clear Filters will on first click reload the results via AJAX but keeping the same parameters - so, results are kept unchanged even if the form is cleared - and on second click will finally show all content, unfiltered.

It is important to note, first, that Drupal core itself does skip the AJAX reload for reset buttons and states that "many things break during the form reset phase if using AJAX" (ajax_view.js).

    // Exclude the reset buttons so no AJAX behaviors are bound. Many things
    // break during the form reset phase if using AJAX.
    const $exposedFormInput = $(
      'input[type=submit], button[type=submit], input[type=image]',
      this.$exposed_form,
    ).not('[data-drupal-selector=edit-reset]');

This code in core is basically skept because of this line that alters the ID and the data-drupal-selector for the reset button, making the .not('[data-drupal-selector=edit-reset]') condition fail.

$form['actions']['reset']['#id'] = Html::getUniqueId('edit-reset-' . $this->view->storage->id());

So, if you need - as we do - to revert back to the no-AJAX reset button, you can just comment this line as a workaround.

I think this change needs to be re-reviewed. Should I create a new one or do maintainers prefer to re-open this?

Created a MR that makes the module compatible with Layout Library.

It includes an important data model change - making the "entity_id" not required.

I'm manually testing, the change, for now it works correctly. Still pending automated tests and a review by module maintainers to see if this functionality is wanted and what implications could have the missing "entity_id" value.

But, if anybody needs to support layout_library right now, the MR works.

idiaz.roncero → created an issue.

Same here, I tried to try to pass a plain URL text to a pattern using views but it outputs the twig debug comments when enabled.

No amount of views processing (removing whitespace, rewrite results, etc) prevents this.

A solution is to put {{ url | striptags | trim | etc }} on the pattern but this feels like a workaround and ... it should be implemented on all pattern props just in case you use a view? - it does not feel right.

I'm having the same issue.

It looks like menu_link_attributes module being enabled at the same time might be the culprit.

Makes sense, as both modules perform alterations on the menu_link_content form.

@divya.lakshman can you check if this module is enabled on your install and try disabling it?

I'm having the same issue.

Note that, as the title of the issue says, this is only happening for menu attributes, this is, with the link_attributes_menu_link_content module enabled and when editing menu links.

That's a really clever solution. I guess browser support is the same as CSS custom properties?

Hola!

Yo podría encargarme de esta formación. Como dije en el canal de Slack, útlimamente no he estado trabajando mucho con SDC debido a que estoy en un proyecto que usa UI Patterns, y por eso tengo miedo de haberme quedado algo desactualizado, pero el temario propuesto lo podríamos cubrir sin problemas.

Se me ocurre que la charla podría girar en torno a una instalación desde cero de un Drupal 10 con un theme que use SDC (radix, se me ocurre) e ir viendo ejemplos de mayor a menor complejidad de cómo se implementarían usando SDC patrones de diseño habituales en Drupal primero y custom después.

Respecto a disponibilidad, tengo unas vacacaciones hasta el 10 de Abril más una entrega, por lo que sería razonable ponerlo para finales de abril o principios de mayo.

idiaz.roncero → created an issue. See original summary → .

Yes, Name is required. I posted this issue too fast, sorry. I was thinking just on the props and got confused.

CLosing as works as designed.

Thanks. I'll be using Radix 6.x soon, so I might be able to help filling out this kind of low-hanging fruit issues.

e0ipso → credited idiaz.roncero → .

idiaz.roncero → created an issue.

Created MR to fix the problem.

Also, for the different SDC integrations that make use of SDC plugins (i.e. SDC styleguide, CL Devel, SDC Display) it would b e very useful to add descriptive labels and descriptions to the props.

idiaz.roncero → created an issue.

Looks like I wasn't granted credit for this fix. Can I ask what are the reasons?

Looks like the error is related with the dual processing of the "dialog:aftercreate" event, only for regular modals.

A quick workaround is to check if the dialog is BS4 and, if not, bypass the second event. See attached MR for details

idiaz.roncero → created an issue.

Created a MR with the same solution than the region_attributes: an empty() check.

idiaz.roncero → created an issue. See original summary → .

Opened MR.

The type of modelAttributes should be Iterable, as stated on the types of toMap:

/**
 * Transforms object or iterable to map. Iterable needs to be in the format acceptable by the `Map` constructor.
 *
 * ```ts
 * map = toMap( { 'foo': 1, 'bar': 2 } );
 * map = toMap( [ [ 'foo', 1 ], [ 'bar', 2 ] ] );
 * map = toMap( anotherMap );
 * ```
 *
 * @param data Object or iterable to transform.
 * @returns Map created from data.
 */
export default function toMap<T>(data: {
    readonly [key: string]: T;
} | Iterable<readonly [string, T]> | null | undefined): Map<string, T>;

...but as I can see, JSDoc does not support Iterable as a type, so I put object instead (even if any iterable will suffice)

@prop {object} modelAttributes
     *   An object containing the supported attributes on the model element or
     *   elements.

idiaz.roncero → created an issue.

I've created an MR (draft) with a solution that works.

It will need some review, though. I don't feel like putting the rerender key inside the DrupalElementStyleDefinition is 100% correct, as it belongs to the "group" level instead.

I have a working proof of concept, will upload it once polished.

idiaz.roncero → created an issue.

idiaz.roncero → created an issue.

Add Sdc Story Generator module

idiaz.roncero → made their first commit to this issue’s fork.

The patch in #14 fixes the issue for me.

Create a MR with a fix that ensures that PHP arrays are not associative and won't be interpreted as objects when converting to javascript.

idiaz.roncero → created an issue.

The module is https://www.drupal.org/project/feeds_youtube_api_parser →

Provided a MR with the proposed Event.

idiaz.roncero → created an issue.

Changing to Needs Review and upgrading priority as this is breaking the Copy functionality.

Lacking a JS API, I think the best place to perform the alias resolution is inside the filter.

This way, the language will be correctly marked as its alias (HTML) bu the correct *.min.js file will be loaded from unpkg.

It will also have better performance as filters are only executed on content update while a client-side resolution would be executed every time.

I've created a draft MR with my proposal. I've only added aliases for HTML, but it would need to have any possible Highlightjs alias added, which is the main pain point (it introduces maintainability problems!).

Any ideas on how to solve the "getting-the-alias-info" problem is welcome!

This error also prevents the Copy plugin for getting loaded, and will break this functionality. Updating issue to reflect this.

The only HLJS API that can be applied is of little use:

hljs.getLanguage('html');

returns

{
    "aliases": [
        "html"
    ]
}

So it seems the only solution should be to manually maintain the list of aliases inside this module.

idiaz.roncero → created an issue.

Same here, I noticed that this module nevertheless DOES use a config that is not exposed via an admin UI (a module settings form) but exists:

        $parent_view_mode = \Drupal::config('paragraphs_previewer.settings')->get('previewer_view_mode');

So, if you are using the full view mode via Layout builder, you are doomed... unless you manually change the exported paragraphs_previewer.settings.yml and manually set your preferred view mode.

A solution proposal would be the following:

1. Expose a module settings form that allows the developer to choose a different view mode
2. Better errors: trigger a warning if the view mode in use is using layout builder in order to let the developer know what's happening, and/or instead of No preview available. print something like It seems the view mode you are using to render this paragraph is using Layout Builder, which is unsupported. Please use the module settings to switch to a different view mode.

+1000 to this

Explanation: i'm not using the more mainstream $url->getInternalPath() method because it returns an un-slashed node/NID path that needs to be compared with an slashed /node/NID path.

Passing path_processing seems to work as it will return the slashed path.

Submitted MR, ready for review.

Drupal will convert internally any path alias that is stored under system.site.page.front config to its unaliased path, see Drupal\system\Form::validateForm and Drupal\system\Form::submitForm:

  /**
   * {@inheritdoc}
   */
  public function validateForm(array &$form, FormStateInterface $form_state) {
    // Get the normal path of the front page.
    $form_state->setValueForElement($form['front_page']['site_frontpage'], $this->aliasManager->getPathByAlias($form_state->getValue('site_frontpage')));

I think then it is safe to always assume the drupal site front page will be expresed as an un-aliased path and request the current request URL also as the unprocessed one:

    $path = parse_url($url->setOption('path_processing', false)->toString(), PHP_URL_PATH);

As far as i can tell from looking at the code, the quickest solution is to bypass the path processing option when generating the URL string

idiaz.roncero → created an issue.

Añado un punto que me parecen importante y(creo) que no ha salido.
* La web de la camp, material gráfico y las diapositivas de los ponentes deben de pasar los tests de accesibilidad de la WCAG (contraste, color, HTML outline, etc), mínimo AA y preferible AAA.

Y un principio general muy obvio pero que no está de mas reflejar en el manual de buenas prácticas.
* La inclusividad debe de ir primero. Cuadrar cuentas es complicado, sin duda, pero se deben de solucionar primero todos los asuntos de inclusividad (incluyendo los que necesiten de presupuesto) y después el resto (swag, actividades). Si algo se debe de quedar fuera, que nunca sea la inclusividad.

+1

+1 to this.

Also, for readability and clarity I think the new public method (getActiveComponents) is the best solution. Boolean flags tend to obfuscate what's happening, calls to getAllComponents(TRUE) or similar are harder to read and understand at first sight for newcomers.

Can't reproduce it on a clean D10 install and the error also vanished after a reinstall on my local environment, so I guess this is something related to my configuration or specific to my local env.

Marking as Cannot reproduce

idiaz.roncero → created an issue.

My bad, this is independent of the use of layout_builder_iframe_modal.

It seems related to the fact that Layout Builder isn't using the admin, but the public theme, so Claro+Gin styling is not applied there.

Re-opening this issue as it has happened again, on a completely different environment and under a completely different set of circumstances.

First time it happened to me, I was using a clean D10 install, no modules installed (other than the standard profile ones) on a DDEV local env.

This time it was an old project (7 years old), on D10, with a lot of active modules and a lot of customizations on a Docker4Drupal local env.

I uninstalled the module layout_builder_iframe_modal, which alters the contextual links on Layout Builder blocks.

Then, I found the same error as reported above: the contextual links remained cached, with the layout_builder_iframe_modal alterations, leading to errors as it changes the data-dialog-type attribute.

Only manually cleaning the cache by using window.sessionStorage.clear() on the console solved the issue. No amount of Drupal cache clears resolved the issue.

I still don't know under which circumstances the error appears, but the fact that I have reproduce it on two completely different environments leads me to consider that this might affect more people.

@KarlShea are you using layout_builder_iframe_modal

If so, I think that's the culprit. The CSS is attached, but inside an iframe (while the dialog topbar, where the button is in, remains outside the iframe). That's why the CSS variables can't access the outer scope.

SO.. i did a little investigation and the following is happening:

1. When you load layout builder, you are using the front-end theme so no Claro assets are present on the page (claro/global-styling library, which includes the variables.css file)
2. When you load the modal, the Gin theme kicks in and via AJAX the assets are loaded: now the variables.css file is present
3. ...but, somehow (maybe because of dynamically loading CSS via AJAX?) the new CSS variables are not applied to the page: they all appear as undefined

If this is confirmed, it might be a major bug as CSS is moving towards variables and then, any AJAX loading of CSS assets that involves adding CSS variables might fail.

The surprising thing is that I can see /core/themes/claro/css/base/variables.css loaded on my theme ¿¿??