🇳🇱Netherlands @Watergate

Watergate → changed the visibility of the branch project-update-bot-only to hidden.

Watergate → created an issue.

Watergate → created an issue.

Watergate → created an issue.

Added deprecation notice to \Drupal\vendor_stream_wrapper\Service\VendorStreamWrapperManagerInterface::creatUrlFromUri() and provided \Drupal\vendor_stream_wrapper\Service\VendorStreamWrapperManagerInterface::createUrlFromUri() as an alternative.

Watergate → changed the visibility of the branch 3452824-ensure-cspell-doesnt to hidden.

Spelling fixed!

Watergate → created an issue.

I'm closing this ticket as it seems to have become outdated.

I am closing this ticket as a Drupal 10-supported version has already been released. Any changes to support Drupal 11 should be placed in 📌 Automated Drupal 11 compatibility fixes for vendor_stream_wrapper Active .

Thanks @mondrake.

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

@lhridley, the issue is already created: https://www.drupal.org/project/flysystem_s3/issues/3446367 🐛 Use new static self in s3 plugin Needs review . We accidentally used the create button in the wrong browser tab. Nothing needs to be done here :)

I'm sorry for the changes; I undid them. I mistakenly thought that the merge request was missing commits (and rebasing would help to fix the tests).

The tests are not failing because of this patch; they are the same as found on https://www.drupal.org/node/2489154/qa → Outside the scope of this ticket, but we should fix the tests and move to GitLab CI ( https://www.drupal.org/about/core/blog/drupalci-and-all-patch-testing-wi... → )

About the changes provided in this ticket/merge request, it allows others to alter the (plugin) definition by implementing a hook (i.e., hook_flysystem_plugins_alter()). This is done in Drupal core in many classes that extend the \Drupal\Core\Plugin\DefaultPluginManager, see for instance: https://git.drupalcode.org/project/drupal/-/blob/11.x/core/lib/Drupal/Co...

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

In addition, this best practice is instructed to PHPStan via https://git.drupalcode.org/project/drupal/-/blob/11.x/core/phpstan.neon....

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

Merged the proposed changes.

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

Merged the proposed changes.

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

I've updated the merge request by restoring the \Drupal\micon_link\Plugin\Field\FieldWidget\MiconLinkWidgetTrait trait. In the latest release, the functionality of that trait was added directly in the \Drupal\micon_link\Plugin\Field\FieldWidget\MiconLinkWidget widget, but this was also used by the \Drupal\micon_linkit\Plugin\Field\FieldWidget\MiconLinkitWidget widget.

@Grevil, I've changed the ticket to "Needs review" (we use this functionality without problems).

Added merge request to add the composer.json file.

@mohd-sahzad, I just noticed that you have assigned this issue to yourself; perhaps you also wanted to add this file. I unassign this issue so that it is clear to others that they can review the suggested changes. Feel free of course to provide any feedback.

Watergate → created an issue.

I've updated the test provided by @johnchque and opened a "draft" merge request.

In the Gitlab CI pipeline, you can see that the test fails with the current Paragraphs implementation (while you expect it to pass; i.e., a "collapse all" shouldn't introduce any rows in the multi-value widget's table).

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

I've provided the proposed fix as a merge request.

Watergate → created an issue.

Watergate → changed the visibility of the branch 3429627-automated-drupal-11 to hidden.

Watergate → changed the visibility of the branch project-update-bot-only to hidden.

We dropped support for the 1.0.x branch and created the 2.x branch. The latter is compatible with Drupal 10 and Drupal 11.

Watergate → changed the visibility of the branch 3429627-automated-drupal-11 to active.

Watergate → changed the visibility of the branch 3429627-automated-drupal-11 to hidden.

If I'm not mistaken, 📌 Allow for deletion of a single value of a multiple value field Fixed solved this issue. Therefore, I am marking it as fixed.

I stumbled upon the same problem and can confirm that the patch solved our problem.

@psf_ thanks for the contribution!

I've looked at the merge request, and I'm wondering why we extend the field_types</codes> of the <code>ssch_formatter with your suggestions. And if I'm not mistaken, when these field types are used, there is no language value available, and the highlighting uses the automatic language detection mechanism, but when we do this, we have to point the user to https://github.com/scrivo/highlight.php?tab=readme-ov-file#automatic-lan....

Now that I have read the automatic language detection mode instructions of the scrivo/highlight.php again, I think it might be better not to provide the user with the option to use "regular text fields" and the one provided in this module. Maybe extending the module's README.md with a note on this automatic language detection mode (and also in the service itself) is better.

A Drupal 10 compatible version has been released using the 2.x branch. The 1.x branch still exists, which is an unsupported Drupal 9 compatible version. It will be cleaned up in the future.

Drupal 10 compatible version has already been released.

Although already marked as RTBC, I can confirm it resolves our problem as well.

@clemorphy, thanks for testing. You can download a plain diff from the merge request. See the plain diff link under the issue fork list at the top of this page (left beside the green "MR !25 mergeable"). For additional information, see https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-dr... →

When performing ./vendor/bin/phpunit --configuration web/core --filter 'testFindCallerFromDebugBacktrace$|testDiscoverService' web/core/tests/Drupal/Tests/Core, after applying the changes of the merge request:

PHPUnit 9.6.15 by Sebastian Bergmann and contributors.

Testing /var/www/app/web/core/tests/Drupal/Tests/Core
...                                                                 3 / 3 (100%)

Time: 00:00.154, Memory: 70.00 MB

OK (3 tests, 3 assertions)

Watergate → created an issue.

I've updated the merge request so that this Micon Linkit sub-module is installable on Drupal 10. I've mimicked the Micon Link module's core_version_requirement, as this is a dependency.

Do I understand correctly that this issue is not postponed as ✨ Linkit for Link field Fixed is fixed?

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

The patch of #29 didn't apply to Drupal 10.2. So, I've updated the patch.

I've removed the proposed changes in the FormElement class, as they have already been added to Drupal (10.2).

The points made by #2863308-24: Content language negotiation not working for entity autocomplete → must still be addressed.

I understand that having a composer.json is not required.

From Add a composer.json file → :

It is better not to provide a drupal/core version requirement in composer.json because Drupal's composer facade will generate the appropriate metadata based on the info.yml file.

And although Drupal 8 (and Drupal 9) are EOL, I would suggest to apply the patch of #5. Create a release compatible with all versions and consider creating a 2.0.0 version of this module that only supports Drupal 10.

Marking RTBC for the patch provided in #5; let me know if further help is needed.

Applied the change.

I will add the change in 📌 Downgrade core_version_requirement for Media diff UI plugin sub-module Active .

Watergate → created an issue.

Watergate → changed the visibility of the branch 2.x to hidden.

Watergate → changed the visibility of the branch 1.0.x to hidden.

Sorry, I now understand that the Media diff UI plugin sub-module uses deprecated functionality in Drupal 10. I will, therefore, change the core_version_requirement for that specific sub-module. In case the Media diff UI plugin sub-module is needed in a Drupal 10 installation, the 2.0.0-alpha1 version of this module can be used, but the introduced access changes should be reviewed closely (as indicated in #3369369-11: Automated Drupal 10 compatibility fixes → ).

Changes are merged.

I have updated the merge-request, by reverting the commit that changed the access checking. So that we can create a Drupal 10 compatible release using the 1.0.x branch, and continue the work for new functionality on the 2.x branch.

I can confirm the patch applies cleanly on a Drupal 10.1 installation.

@Mingsong, you can add me as a maintainer. I will create the Drupal 10 compatible release and help where needed.

@Mingsong, thanks for your reply. I understand your point that "dev"-versions shouldn't be used in production. But the functionality of 📌 Remove deprecated MediaRevisionAccessCheck in Drupal 10 Fixed , which has been merged already, is blocking a Drupal 10-compatible release for this module.

I propose rolling back the functionality that needs explicit testing, using that to create a Drupal 9 and 10 compatible release, and tagging it as 1.1.0. In combination, make a 2.0.0-alpha1 version compatible with Drupal 10 (and 9?), which contains the functionality that needs explicit testing. We can then use the project page and release notes to point users for feedback on the changed functionality (that is included as an alpha release).

Please let me know if you agree with the above proposition and need help.

For others who want to install this module in Drupal 10, I've attached a small patch to this issue, which can be used with the mglaman/composer-drupal-lenient and orakili/composer-drupal-info-file-patch-helper Composer plugins to ease Drupal10 upgrade.

I looked into this issue to get this module working with Drupal 10. While updating/applying the patch provided by the Project Update Bot in the issue fork, I noticed that in 📌 Remove deprecated MediaRevisionAccessCheck in Drupal 10 Fixed , the core_version_requirement already had been updated, but this is not included in a release yet.

Watergate → changed the visibility of the branch 3369369-automated-drupal-10 to hidden.

Watergate → changed the visibility of the branch 3369369-automated-drupal-10-1 to active.

Watergate → changed the visibility of the branch 3369369-automated-drupal-10-1 to hidden.

I can confirm the patch applies cleanly.

@orakili, thanks for the Composer plugin. It helped me/us a lot!

Does the #65 requires some manual action?

After applying the patch, everything should work as before. Using {{ content }} should still produce the same output as before. The extra functionality of the patch is that you can output specific blocks like {{ content.page_title }} and {{ content|without('page_title') }}.

Please let us know if you can reproduce the problem using a clean install.

Thanks a lot for the patch(es); this functionality was/is missing. I can confirm that everything works perfectly on Drupal 10.1.6.

I agree with the nitpick in #3178202-59: Render blocks later, so they can be placed individually in a region template → and think that @group Render makes the most sense (and is in line with the rest of the test classes in the namespace). I've updated the patch with the small change :)

I've implemented the suggested change and opened a merge request.

As stated in the issue description, the problem seems similar to #2478099: Unable to read EXIF data when uploading to S3 Bucket. → . I've opened a new ticket since that ticket is about the Drupal 7 version of the module, and there seems to have already been some work/updates in the Drupal 8 (9/10) port/version.

Watergate → created an issue.

The patch provided in #3126330-3: Apply image style dimensions with HTML attributes → didn't apply anymore to the latest version, so I've updated the code and created a merge request.

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

greggles → credited Watergate → .

Stumbled upon the same problem when attaching a paragraph → field to (fixed) block content.

I agree with @vidorado #3272253-5: Fixed blocks are not visible to guest users → that this "solution" might be too permissive/friendly. The infinite loop is indeed a problem; the solution might be to implement the same strategy as used by the BlockContentAccessControlHandler::checkAccess():

AccessResult::allowedIf($entity->isPublished())
  ->orIf(AccessResult::allowedIfHasPermissions($account, [
    'access block library',
  ]))
  ->orIf(AccessResult::allowedIfHasPermissions($account, [
    'administer block content',
  ]))

Where the $entity->isPublished() should be the referenced/included block content object.

The provided patch didn't apply cleanly anymore (to the latest dev-version), so I've opened a merge-request (already).

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

Added file name suggestion for the provided code fragment, improved grammar and solved typo's.

Works like a charm on both D10.0 and D10.1 :)

I have added the missing information in the config/schema/heading.schema.yml file and opened a merge request.

I agree that the compatibility claim in the potx.info.yml is currently incorrect.

If the 8.x-1.x version of this module should still support Drupal 8, and therefore Drush 8, then I would propose creating a 2.x version/branch for this module that supports Drupal core ^9.3 || 10 (and thereby Drush 10 and 11). The 8.x-1.x should be made compatible with Drupal 8 again (this means that the changes made in 📌 Drupal 10 compatibility fixes for potx Fixed should be partially rolled back).

If Drupal 8 support can be dropped in this module's 8.x-1.x version, the proposed commit tag would be a friendly gesture. To prevent confusion, the potx.drush.inc should be removed since only Drush 10 or higher should be supported.

Good point; I think you are right, @Eric_A. However, similar changes were already made in #3285613 (i.e., rewriting the deprecated code in the potx.drush.inc file, but for extracting strings from module files).

Let's use #3354887 to discuss which core and Drush (combinations) are supported and the most suitable strategy.

Watergate → created an issue.

I've updated the issue description based on the above comments.

Resolved merge conflicts on the original merge-request, so that it can be merged to the 3.x branch, and made some improvements (such as adhering to coding standards, ensuring the test proceeds, changing the name of the interface and adding a default implementation).

Added an extra merge-request for the 4.x branch, containing the same changes as for the 3.x branch.

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