🇬🇧United Kingdom @natts

natts → created an issue.

natts → created an issue.

Hi @anfor - any progress? :)

Fundamentally, it appears that Viewfield only supports views, whereas this module supports other types of entities.

natts → created an issue.

natts → created an issue.

The v2.1.0-rc1 release is not stable (I will add issues shortly that I'm experiencing), and did not have any release notes, so this task is not complete.

https://www.drupal.org/project/entity_extra_field/releases/2.1.x-rc1 →

Released in v 2.0.0-rc1 →

Released in v v2.0.0-rc1 →

Released in v2.0.0-rc2

This is a duplicate of issue #3423623 🐛 "Enforce Privacy Consent Policy" checkbox default value is checked even when it is disabled RTBC , where the additional issue of how this will affect users of different previous versions is being considered.

The Project Update Bot is recommending an additional change 📌 Automated Drupal 10 compatibility fixes Needs review , in CartBlockBase.php, returning the rendered element using the renderer Drupal service.

So here's an updated version of the D10 compatibility patch.

While waiting for this merge request to be accepted and released, you can patch the module using https://git.drupalcode.org/project/address_display/-/merge_requests/6/diffs.patch

Now released → .

I would have done so sooner if I had known about this issue.

Committed and released → now.

When will this be released?

natts → created an issue.

Here's a patch which selects the first thumbnail returned by the API, and uses the width specified. Its height is not specified by the API, so this is calculated on the assumption that the video and thumbnail are using 16:9 aspect ratio.

natts → created an issue.

@Anybody This commit broke my front page on my 9site, with a similar error to #4. The commit means that PageRedirectHref has no methods, and so getActionTarget doesn't return anything.

This commit should not have been included in v2.0.2.

I suggest you release again (v2.0.3) with this commit reverted, and please test changes before releasing them.

Thanks for the quick release ;-)

Please release this fix! v2.0.2?

natts → created an issue.

*bump* :-)

natts → created an issue.

Hi @paulrad, I won't be adding a LICENSE.txt because that's something that drupal.org does itself, using a GNU public license. That issue you've linked to only relates to patching, and it is still active (unresolved), and doesn't say anything about adding a LICENSE.txt file. It suggests that the information be moved to another file that can be added at the same time that the LICENSE.txt file is added, by the drupal.org packaging process.

I've now updated the dependencies in both .info files, thanks.

Thanks for reporting this. I've committed a fix and will release it shortly.

The reason why this isn't working, is that the module contributors never bothered to actually implement the suggestions. If you search the code, there's no use of the suggestions hook: https://git.drupalcode.org/search?search=suggestions&nav_source=navbar&p...

See https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Render%21...

It's very disappointing this expected functionality from a templating module has never been implemented.

natts → created an issue.

OK, so is anyone reading this able to help with that? I really don't have the experience with Gulp or Webpack etc., but am happy to approve merge requests to get this theme marked safe again.

I was able to trigger it using hook_preprocess_ds_entity_view:

function mytheme_preprocess_ds_entity_view(&$variables) {
  $variables['node'] = $variables['content']['#node'];
  $variables['view_mode'] = $variables['content']['#view_mode'];

  mytheme_preprocess_node($variables);
}

natts → created an issue.

Here's what to do: Opting into security advisory coverage →

The FontAwesome module is compatible with Drupal 10 as of version 8.x-2.24 → .

v3.1.0-rc1 of link_icons → is now compatible with Drupal 10.

Hi @Maikel, are you still planning to log this?

Fixed in 8.x-1.0-rc3

Do you still plan to do this, @devkinetic?

I'm surprised that neither of these issues, especially the second which is a definite bug, have been addressed in all this time.

Just to confirm that using the global block area provided by the views_block_area → contributed module worked for me too.

natts → created an issue.

I've now been able to get the patch working, after starting with a fresh checkout on the 8.x-1.x branch (sorry about that). Running 'npm audit' confirms all vulnerabilities have been addressed.

However, I don't know what theme functionality this could affect or break. Does anyone have experience with travis? There are some tests available in the project.

Thanks but that still doesn't work:

$ curl https://www.drupal.org/files/issues/2023-04-13/npm-dependencies-3353211-6.patch | git apply -v --index
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 1132k  100 1132k    0     0   176k      0  0:00:06  0:00:06 --:--:--  276k
Checking patch starterkit/package-lock.json...
error: starterkit/package-lock.json: does not match index
Checking patch starterkit/package.json...
error: starterkit/package.json: does not match index

Again, which commit (give me the commit message, date/time, hash, or link to it) does your patch work against? The commit log is here.

OK, but what is the hash or the commit message of the commit that you cloned? When I am cloning from the commit tagged with the latest release (8.x-1.15), hash 4de9cd3, your patch doesn't work.

Thanks.

I can't test it as I don't know which release you were working from? The hash doesn't match 8.x-1.15 (4de9cd3). Which release is the patch for?

curl https://www.drupal.org/files/issues/2023-04-13/npm-dependencies-3353211-%236.patch | git apply -v --index
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 1132k  100 1132k    0     0  3342k      0 --:--:-- --:--:-- --:--:-- 3342k
Checking patch starterkit/package-lock.json...
error: starterkit/package-lock.json: does not match index
Checking patch starterkit/package.json...
error: starterkit/package.json: does not match index

Thanks for that @very_random_man. I was doing something more simple with a entity reference field for media, and didn't know that I needed to use target_id as the attribute of the field to assign the generated entity to it, but your code showed me that's what I was missing:

process:
  youtube_1/url: youtube1
  youtube_2/url: youtube2
  youtube_3/url: youtube3
  vimeo_1/url: vimeo

  videos:
    - plugin: get
      source:
        - '@youtube_1'
        - '@youtube_2'
        - '@youtube_3'
        - '@vimeo_1'

  field_videos:
    plugin: sub_process
    source: '@videos'
    process:
      target_id:
        - plugin: skip_on_empty
          source: url
          method: process
        - plugin: entity_generate
          source: url
          entity_type: media
          bundle: remote_video
          bundle_key: bundle
          value_key: field_media_oembed_video
          values:
            field_media_oembed_video: url

These updated links don't work any more. Does anyone know the current correct pattern?

@Arshu1864: As the new module maintainer, I'm OK with having others work on the outstanding issues, but I need to know when you expect to resolve this specific issue by?

I have finally been given maintainer access to the project, after I chased up the Security Team: https://security.drupal.org/node/178491

What's the hold-up on fixing this fundamental bug?

The same problem exists when using the bootstrap5 theme. On its theme settings page, there is a link /admin/appearance/styleguide.

I've just reported this to the Security Team to try to get some attention/progress made: https://security.drupal.org/node/178491

I also want my migrations, located in the current correct place (which is 'modulefolder/migrations') → , to be listed in the UI.

Moving it to config/install is not best practice any longer. Re-installing modules or writing update hooks is messy, laborious and unnecessary.

If there really is some kind of issue about about having too many migrations shown, then just have tabs or another UI mechanism to filter them.

natts → created an issue.

Just to add to this, for me, I was just migrating into a simple time field, not a time range, from an external MySQL table via CSV.

So I was able to output the time field in my SELECT query using MySQL's TIME_TO_SEC() function (which outputs an integer between 0 and 86399, representing the seconds from midnight), and then my migration YAML just needed to be:

...
source:
...
  fields:
    - name: time
    - label: 'Time'
...
process:
  field_time/value: time
...

natts → created an issue.

I'm grateful for the quick turnaround today, but the issue was first reported 15 days ago 🐛 Incorrect URL Paths in CSS Closed: works as designed and apparently ignored until I followed up on it yesterday.

Oddly, on an installation where I don't have the bootstrap theme installed, this patch still worked on my bootstrap5 theme, updating the 25 references to the 24 starterkit_theme image icons across 6 bootstrap5 CSS files accordingly. I applied it using cweagans/composer-patches.

The required.svg is not the only missing image icon that's referred to in the CSS of this bootstrap5 theme. There are 25 matches across 6 CSS files. All of those icon images being referred to are in fact available within the Drupal core starterkit_theme (core/themes/starterkit_theme/image/icons) since Drupal 9.3.

So while a quick fix is to add required.svg into the place where the CSS says that it is (bootstrap5/images/icons), I believe the correct fix is either for all of the CSS to be updated to use the 24 image icon files made available in the core starterkit_theme, or possibly, to have its own copies of all 24 of them.

natts → created an issue.

natts → created an issue.

Just checking if anyone has contacted the Security Team → to review the patch, so that the project can get a new maintainer and the patch can be released? The theme is (still) stuck in limbo until this happens.

Just checking if anyone has followed this step (contacting the Security Team → ) to review the patch?

I wasn't the author of the Private Files check, so I don't know which is the correct version of the Filesystem class to be used by it.

It wasn't a permissions issue on the root vendor directory.

A version of the Filesystem class is indeed in core, but the PrivateFiles.php check in this module wants to use the Symfony version:

<?php

namespace Drupal\security_review\Checks;

use Drupal\Core\Link;
use Drupal\Core\StreamWrapper\PrivateStream;
use Drupal\security_review\Check;
use Drupal\security_review\CheckResult;
use Symfony\Component\Filesystem\Filesystem;

/**
 * Checks whether the private files' directory is under the web root.
 */
class PrivateFiles extends Check {
...

So as a workaround, I had to require the component in Composer ('composer require symfony/filesystem') to get that specific version of the class into my codebase.

If the check should be using the Drupal core version, not the Symfony version that is stated, then I would think that last use line of PrivateFiles.php needs updating to:

use Drupal/Core/Component/Filesystem/Filesystem;

natts → created an issue.