Account created on 17 March 2011, almost 14 years ago
  • Technical Team Lead, Customer Support at Vardot 
#

Merge Requests

More

Recent comments

🇺🇸United States lhridley

Postponing until 3.x branch work is nearing completion. This branch is under active development, but not yet ready for use.

🇺🇸United States lhridley

Thank you both for catching that! I made the change on the 2.3.x branch but forgot to backport it to the 2.2.x branch. I've committed the change on the 2.2.x-dev branch now, and I'll cut a bugfix release later today.

🇺🇸United States lhridley

So, I just tried to duplicate this issue with a fresh D11 site install, walking through the steps that the OP outlined. I am not able to edit the "Authored by" field through the UI, even though it is set to translatable in the configuration. This appears to be the case whether or not the "Hide non translatable fields on translation forms".

The test users in this test case are testuser1 (language English), testuser2 (language Spanish), and testuser3 (language English)

Basic page is configured for translations, and content type is configured to display the author by and authored on date on the Basic page entity. Revisions are being tracked.

English content (original) created by testuser1.
Spanish content translated by testuser2.
English content is revised by admin user (user 1).

testuser1 always shows as the author for the English version, and testuser2 always shows as the author for the translated version. Once the initial nodes are created, even with revisions to the English content by the "admin" user (user 1) the authored by field remains unchanged.

So...I can only draw the conclusion that the "Authored by" field is no longer exposed for translations (which seems logical to me).

However, if this is the case, then the "Authored by" field shouldn't appear on the translation configuration options for the content type.

🇺🇸United States lhridley

From what I've been able to determine, there are no tests in Core that actually pass a value for the first parameter, $match. All calls that I can locate call this method with no values passed for the parameters, instead taking the default values. I limited my search to Drupal Core versions 10 and 11.

The Core Kernel test that exists calls the method without any parameters, so default values are used.

In addition, all of the tests that I have located are in core modules that have bundles, so I don't think that a test exists for this.

So, this begs the question:

* Are there Core or contrib entities that exist without a bundle?
* Do we need a test for this in Core?

If the answer to both is no, then:

* what is the purpose of the first parameter, and what is a use case where a value would be passed?
* If it has no real world purpose, should the API be changed to remove it?

🇺🇸United States lhridley

It appears that the use of Symfony\Component\HttpKernel\Event\FilterResponseEvent was removed in Drupal 9.0.0, and replaced with Symfony\Component\HttpKernel\Event\ResponseEvent in 9.0+.

The class, https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Http%21KernelEvent.php/class/KernelEvent/9 appears to be a port of the Symfony 5.3 KernelEvent, with some added code for forward compatibility with Symfony 6.

This class, Drupal\Core\Http\KernelEvent, was removed from Drupal core with version 10.0.0.

Since the code in question in this issue has been deprecated and removed from Drupal Core, I'm going to close this issue as outdated.

🇺🇸United States lhridley

From the stackdump you included in your bug report, it appears that this is a bug with the drupal/flysystem_gcs module, which provides the adapter for Google Cloud Storage. That module is maintained by a different maintainer.

I am moving this issue to that project.

🇺🇸United States lhridley

Updated README on both 2.3.x and 3.0.x branches.

🇺🇸United States lhridley

Updating issue for attribution

🇺🇸United States lhridley

This sounds like this is specific to changes with the S3Client in the AWS PHP SDK. This question / bug needs to be addressed by the maintainer of the submodule Flysystem S3, which can be found here: https://www.drupal.org/project/flysystem_s3

Also you might get some guidance in the Flysystem Channel on Drupal Slack, which can be found at `#flysystem`. One of the maintainers of the flysystem_s3 module is there on a regular basis, as well as community members getting involved in maintaining the module and the related modules in the ecosystem.

🇺🇸United States lhridley

@steven-snedker The project page has been updated to link to the current version's README file, and documentation has been cleaned up a bit.

I'm happy to take any constructive criticism on the documentation if you'd like to provide replacement text for the current README, I can generate a patch and update it, providing credit for the updates to you.

🇺🇸United States lhridley

Fixed in Release 2.2

🇺🇸United States lhridley

2.2.x will not be updated for D11 compatibility. It has been updated to get all unit tests running and will sunset when Drupal 10 reaches EOL. the 2.3.x branch will be the first branch compatible with D11. The work on 2.3.x-dev is currently testing as compatible, some functional testing remains before an alpha release will be cut.

Closing this issue as wont'fix.

🇺🇸United States lhridley

Fix in version 2.2.x, will need to be ported to 2.3.x+.

Also test coverage will need to be expanded to cover the new classes that have been added.

🇺🇸United States lhridley

@xurizaemon I've also got tests working on the 2.2.x branch, those were pushed up earlier today. I'm using this as a baseline for the 2.3.x refactor that is currently not working.

The following test coverage does not exist for the 2.2.x or 2.3.x branches, listed in priority order:

* https://www.drupal.org/project/flysystem/issues/3499242 📌 Create a Functional test for replacing Drupal Core's "assets://" stream wrapper with a Flysystem implementation. Active (highest priority, can be implemented for 2.2.x or 2.3.x branch)
* https://www.drupal.org/project/flysystem/issues/3497811 📌 Add test coverage for Drupal\flysystem\Form\FieldMigration Active (exists on the 2.3.x branch only)

I really want to have the first set of tests covering using a Flysystem adapter to replace Drupal Core's assets stream wrapper written and working before embarking on the D11 compatibility, as well as picking back up the 3.0.x refactor to implement League/Flysystem v3 Library.

But, that is a significant body of work, so for expediency I was going to plan on implementing D11 compatibility with League/Flysystem v1 in 2.3.x, and save upgrading to League/Flysystem v3 for a 3.0.x release.

If you'd like to jump in on the functional tests for replacing the Core "assets" stream wrapper with a Flysystem Stream Wrapper (the Local adapter is included in the Drupal Flysystem main module) that would be super awesome.

🇺🇸United States lhridley

@xurizaemon -- if you can fix the linting and cspell checks please do so; however the phpstan issues are related to some functional bugs that I introduced when in pulled in the Twistor/FlysystemStreamWrapper code into the project and refactored it to remove all of the unnecessary static calls. I am tracking those issues down now, no need for both of us to work on the same thing.

🇺🇸United States lhridley

@xurizaemon Pursuant to your original posts about removing the CollectionOptimizer tests, I have spent a few hours reviewing the implementaiton of the Lazy asset optimizers in Drupal Core, and their intended use vs the Flysystem asset optimizers, and have reached the same conclusion, that the Lazy optimizers are not needed once the core Lazy optimizers are implemented, as their sole intention is to consolidate and write optimized css and js files (with "optimized" meaning minified and aggregated css and js files) to the "assets://" stream wrapper. Defining a replacement stream wrapper for "assets://" is within the purview of Flysystem, and perhaps a better use of effort would. be to evaluate whether a Flysystem adapter can be used as a replacement for Drupal Core's Asset Stream Wrapper.

I'm still in the camp of removing the Lazy optimizers and any associated tests from Flysystem, as they don't appear to be needed. However, a functional test that replaces the core "assets://" stream wrapper with a Flysystem stream wrapper does seem to be a more relevant set of tests to me, to evaluate that in fact replacing the core stream wrapper does in fact work properly.

Therefore, I'm closing this issue again, and opening an issue to create a functional test for replacing the defined core "assets://" stream wrapper with a Flysystem implementation using a Flysystem adapter.

Production build 0.71.5 2024