Use a different package for stream wrapper support

I think the correct status for this issue is Postponed.

Another option is m2mtech/flysystem-stream-wrapper, it's a fork of the twistor/flysystem-stream-wrapper package we're currently using and seems to have more downloads on Packagist.

Switching this for 2.1.x branch, let's apply there and work toward a total replacement using the updated Flysystem V3 for 3.0.x

Unfortunately just switching out the dependency is not an option without significant refactoring because ` m2mtech/flysystem-stream-wrapper` is a complete rewrite of `twistor/flysystem-stream-wrapper` with multiple change to the API.

Attached is a patch to port the code for the third party libraries that are dependencies for this module, effectively:

* twistor/flysystem-stream-wrapper
* league/flysystem
* league/flysystem-replicate-adapter

And remediating the ported code for PHP 8.1 compliance and D10 compliance.

Would love to be able to go back to utilizing external libraries, as this adds alot of additional code to maintain, and I'm not yet convinced the test coverage is here to support the ported code (I did also port several of the tests, but may have missed some).

It's a good starting point. Failing tests have been remediated, but ported code is not Drupal coding standards compliant..

I'm not sure copying the code of those libraries to this module is a good solution. We'll have to migrate to Flysystem V2 or V3 at some point, might as well do it now, right?

Oh, I agree, I'm looking to get the 2.1 branch stable for D10, then start working on the 3.0.x branch and using either Flysystem v2 or v3. That will be a breaking change because the APIs on V2 and V3 changed significantly from V1, with alot of refactoring along the way to eliminate the dependencies on abandoned third party packages.

Okay, makes sense.

Ran a code coverage report after applying this patch:

* Code Coverage for the original module code (not ported) is very good, exceeding 90%.

More test coverage could be used:

Drupal\flysystem\EventSubscriber\EnsureSubscriber
  Methods:  66.67% ( 2/ 3)   Lines:  92.31% ( 12/ 13)
Drupal\flysystem\Asset\CssCollectionOptimizer
  Methods:   0.00% ( 0/ 1)   Lines:  83.33% ( 10/ 12)
Drupal\flysystem\Asset\JsCollectionOptimizer
  Methods:   0.00% ( 0/ 1)   Lines:  83.33% ( 10/ 12)

For the Optimizers, the original maintainer extended Drupal Core classes instead of implementing Interfaces, so these statistics may be misleading, as test coverage may exist in Drupal Core for Methods that are part of the parent class.

At this time, I'm not going to port all of the tests for the ported code, primarily because the goal is to stabilize the module for D10, and focus on a rewrite for a new major version release using league/flysystem v2 or v3.

I'm going to merge this patch in "As Is" to the dev branch, but hold off for a bit on generating another release until this has had some time to percolate a bit.

Same with Coding Standards compliance for the ported code. Would rather focus time and energy on v3.0. However if someone wants to tackle coding standards, I'll accept patches!

Are you sure all this is actually necessary? Because I have a project which is running Drupal 10.1.1, PHP 8.1 and Flysystem 2.1.0-rc4 and everything is working as expected. The only patches I have applied are these:

twistor/flysystem-stream-wrapper

• https://github.com/twistor/flysystem-stream-wrapper/pull/15

flysystem

• #2661588: Support delivering local image styles until remote upload is complete
• #3371573: Call to undefined function file_create_url() in CssOptimizer
• #3376399: Support new lazy asset collection optimizers & deprecate the serve_* options

I think it would be enough to fix this on the 3.x branch.

Rethinking this one, which is why it's not yet part of a release.

I don't think this issue has anything to do with Drupal 10 / PHP 8.1 compatibility, as far as I know 2.1.0-rc5 is completely D10 compatible, except #3376399: Support new lazy asset collection optimizers & deprecate the serve_* options. This is just about getting rid of an abandoned dependency. Let's remove those tags and change this issue to target 3.x. If this does impact D10/PHP8.1 compatibility, please tell me how and maybe we can figure out another way to fix it.

I moved this back to "Needs Work", i have a revert patch running through tests currently, took a bit to make sure that I didn't lose other MRs that had been merged. I'll be updating the 2.1.x-dev branch with the revered code as soon as I get through with my team meetings today, in a couple of hours tops.

Reverted the refactoring while keeping other merged MRs. Closing this issue.

Why close? This still needs to happen in the 3.0.x branch, right?

Reopening this issue, as it is now relevant to the 3.0.x branch work. Will evaluate to determine what changes may be needed.

Closing as outdated. See latest 3.0.x dev branch code as of 2026 June 12, which is a complete rewrite of the existing codebase. Notes are in the README.md file as well as the DeveloperNotes.md file.