🇨🇭Switzerland @dpacassi

Played around a bit more, I think there are two points that we haven't thought of.

1. Content types already limited by the field settings
If I add an entity reference field and limit it to e.g. nodes of type "article" in the field settings but use the new LinkIt widget, that widget will return a list of nodes with the filters set on the linkit profile.
I think that's slightly wrong as I'd say the field settings limitations are more important than the linkit profile settings.
My proposal would be to simply combine both filters? Like use the LinkIt profile filters and then apply the field setting filters additionally.

2. Searchable metadata
Displaying the metadata is already great but it would be even better if that data is also searchable?
If the widget displays the username in the metadata, we could search for an username instead of the title and the widget would return the entities. Fancy, right?
However, we probably want to add an option to the form display settings to set if we want to search the metadata data as well.

Would love to help out but December is quite busy for me as probably for most of us but still wanted to point out to these two points.

Wow, this would be *really* amazing, I was just googling for solutions and came across https://www.drupal.org/project/linkit_references → (but that's for D7), so having this in LinkIt core would be so great!

Opened a MR ( https://git.drupalcode.org/project/gin/-/merge_requests/510 ), and also adding the patch file as an static asset to this issue.

The selector is fine, it should just also ignore elements that have the class .ajax-new-content.

@mglaman, can you check if the MR/patch file fixes the issue on your side?

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

Created a 3.x branch and a 3.0.0 release.

Fixed!

Fixed it in the 3.x version of the module, thanks for the help!

Added the changes to the 3.x branch of the module, if you want to extend the view mode selection per entity type, I'm happy to merge future MRs/patches (hopefully quicker this time).

Thanks, added the change to the 3.x version of the module!

Oops, that comment was meant for another issue.
However, I still keep the MR closed/won't apply the changes as per https://www.drupal.org/docs/develop/managing-a-drupalorg-theme-module-or... → I quote:

Please note that the Drupal Coding Standards have not yet been updated to allow Markdown files, conversion should only be undertaken at the request of an existing project maintainer.

So, there's really no need to update the MD files for now.

Pull request created, see:
https://git.drupalcode.org/project/entity_export_csv/-/merge_requests/7

Attaching a static patch file in case the PR gets rerolled.

dpacassi → created an issue.

Adding a static file from the current stage of https://git.drupalcode.org/project/viewsreference/-/merge_requests/37 in case the MR gets updated/rerolled.

Adding a static file from the current stage of https://git.drupalcode.org/project/viewsreference/-/merge_requests/45 in case the MR gets updated/rerolled.

We ran in the same issue, following code should work with the current state on dev:

/**
 * Implements hook_oauth2_server_user_claims_alter().
 *
 * @param array $claims
 *   An array of claims.
 * @param \Drupal\user\UserInterface $account
 *   A user account object.
 * @param array $requested_scopes
 *   An array of requested scopes.
 */
function your_module_oauth2_server_user_claims_alter(array &$claims, \Drupal\user\UserInterface $account, array $requested_scopes) {
  if (in_array('openid', $requested_scopes)) {
    $claims['zipcode'] = $account->get('field_zip')->value;
    $claims['town'] = $account->get('field_city')->value;
    $claims['country'] = $account->get('field_country')->value;
    // etc.
  }
}

I can reproduce the same error with the Claro (core) theme.
As it happens there too, I don't think it's a bug from the themes but from the module itself.

The themes expect a type to be set, which is currently not.
I've created a MR: https://git.drupalcode.org/project/bootstrap_datepicker/-/merge_requests/6 and uploaded a static patch (#6) to fix this issue.

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

dpacassi → created an issue.

Thanks for the fix, using it on a Drupal site which had this issue.
+1 RTBC

Using #39 on two big Drupal sites, has been working so far :)

+1 RTBC

Well, I just found out the project's custom theme overrides a field template (field--entity-reference.html.twig) and has only following content:

{% for item in items %}
  {{ item.content }}
{% endfor %}

I've created a new field template specifically for my newly created field (field--paragraph--field-photoswipe-images.html.twig) which has the content of the classy field template:

{% if label_hidden %}
  {% if multiple %}
    <div{{ attributes }}>
      {% for item in items %}
        <div{{ item.attributes }}>{{ item.content }}</div>
      {% endfor %}
    </div>
  {% else %}
    {% for item in items %}
      <div{{ attributes }}>{{ item.content }}</div>
    {% endfor %}
  {% endif %}
{% else %}
  <div{{ attributes }}>
    <div{{ title_attributes }}>{{ label }}</div>
    {% if multiple %}
      <div>
    {% endif %}
    {% for item in items %}
      <div{{ item.attributes }}>{{ item.content }}</div>
    {% endfor %}
    {% if multiple %}
      </div>
    {% endif %}
  </div>
{% endif %}

The gallery now works without my patch.
Sorry for the fuss, should have tested it first on a vanilla installation :|

So, I've checked again on a vanilla Drupal 10.1.5 instance and can confirm that everything works as supposed.
When I've encountered this bug and saw the other issue, it seemed so obvious that there might have been a mistake in the fix, specially since I didn't overwrite any templates or implemented any hooks.
It was a new entity type (paragraph) with a new media field but yeah, there's probably still a contrib or custom module interfering with the gallery on the real project.

Closing the issue for now, I might come back with additional info on my installation once I've fixed it to work without the patch.

I know that ✨ Different/wrong html when there is only one image Fixed is already in the dev branch and that the tests have been updated.
But I need a quickfix for this, so for now, I'm uploading a patch which simply undoes the changes of ✨ Different/wrong html when there is only one image Fixed .
That seems to work for me for now, though I haven't tested it with single images.

dpacassi → created an issue.

MR created.

When getting $container->get('logger.factory') we get a LoggerChannelFactory object which implements LoggerChannelFactoryInterface and not LoggerChannelFactory.

See attached patch.

dpacassi → created an issue.

MR opened:
https://git.drupalcode.org/project/social_media_links/-/merge_requests/31

Attached you can find the current patch file.

dpacassi → created an issue.

Created a MR, see: https://git.drupalcode.org/project/better_exposed_filters/-/merge_reques...
Also attaching the current diff as a patch file.

dpacassi → created an issue.