Problem/Motivation
In #3414627: Convert StreamWrapperManager to use a service locator we modified StreamWrapperManager.
In install_begin_request() we define a minimal container to bootstrap the install system, including:
$container
->register('stream_wrapper_manager', 'Drupal\Core\StreamWrapper\StreamWrapperManager')
->addMethodCall('setContainer', [new Reference('service_container')]);
However, the setContainer method has been removed and the service locator (container) should be passed as an argument.
Question: why doesn't this fail?
Steps to reproduce
Proposed resolution
Merge request link
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
Comments
Comment #3
longwaveTesting what happens if we just remove file_system and stream_wrapper_manager entirely here.
Comment #4
spokjeSeems dead-as-dodo-code to me => RTBC (without the need for a followup...😈😇)
Comment #5
longwaveComment #7
larowlanDid some git ancestry
The stream wrapper manager was added in a bad reroll by me in #2028109: Convert hook_stream_wrappers() to tagged services. which was pointed out by @sun in comment 152. Crediting sun here for that all these years later.
The file system entry was added in #2050759: Move drupal_chmod and other code in file.inc to a Drupal\Core\File\FileSystem class around the same time (late 2014/early 2015)
Manually ran an install and verified this hunk is where we boot an actual container now, which contains the file system service.
$kernel->boot();loads core.services.yml which loads the actual file system service.So the subsequent use of the file system lower down is fine
crediting myself for this archeology work
Comment #9
larowlanCommitted to 11.x, thanks!
Comment #11
wim leersHm … this would be a delightfully simple explanation for #3416735: Stream wrappers not registered when installing module's default config and potentially fixes that altogether 🧐