🇨🇭Switzerland @dpacassi

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.