>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3565589. --> Reported by: [w01f](https://www.drupal.org/user/2488816) Related to !19 >>> <p><strong>Description</strong> </p><p> The <em>Export as recipe</em> action for an ECA model triggers a fatal error on Drupal 11 sites with S3FS enabled. Clicking <em>Export as recipe</em> results in a WSOD / unexpected error and the following TypeError:</p> <p><code>TypeError: Cannot assign Drupal\s3fs\S3fsFileSystemD103 to property Drupal\modeler_api\Form\ExportRecipe::$fileSystem of type Drupal\Core\File\FileSystem</code></p> <p>This prevents exporting recipes on any site where the <code>file_system</code> service is overridden by another implementation (e.g., S3FS).</p> <h2><strong>Steps to Reproduce</strong></h2> <p> <strong>1.</strong> Install and enable <code>eca</code> and the modeler / recipe export functionality (via <code>modeler_api</code>).<br> <strong>2.</strong> Enable S3FS so that the <code>file_system</code> service is provided by S3FS.<br> <strong>3.</strong> Open any ECA model in the UI.<br> <strong>4.</strong> Click <em>Export as recipe</em>.<br> <strong>Expected:</strong> A recipe export file is generated/downloaded.<br> <strong>Actual:</strong> Fatal TypeError and export fails.<br> </p><h2><strong>Root Cause</strong></h2> <p> In <code>modules/contrib/modeler_api/src/Form/ExportRecipe.php</code>, the class type-hints the filesystem as the concrete class <code>Drupal\Core\File\FileSystem</code>. When S3FS is enabled, the container returns an S3FS filesystem implementation (e.g. <code>Drupal\s3fs\S3fsFileSystemD103</code>) for the <code>file_system</code> service. Because the property/constructor is typed as the concrete class instead of the interface, PHP strict typing throws a TypeError.<br> </p><h2><strong>Solution</strong></h2> <p> Update <code>ExportRecipe.php</code> to type-hint <code>Drupal\Core\File\FileSystemInterface</code> instead of <code>Drupal\Core\File\FileSystem</code> for the property and constructor (and update the <code>use</code> statement accordingly). No container/service changes are required; <code>$container-&amp;gt;get('file_system')</code> remains the same.<br> </p><h2><strong>Patch to Upload</strong></h2> <p> <strong>File:</strong> <code>modules/contrib/modeler_api/src/Form/ExportRecipe.php</code></p> <pre>diff --git a/src/Form/ExportRecipe.php b/src/Form/ExportRecipe.php<br>index 1234567..89abcde 100644<br>--- a/src/Form/ExportRecipe.php<br>+++ b/src/Form/ExportRecipe.php<br>@@ -1,7 +1,7 @@<br>&lt;?php<br><br>namespace Drupal\modeler_api\Form;<br><br>-use Drupal\Core\File\FileSystem;<br>+use Drupal\Core\File\FileSystemInterface;<br>use Drupal\Core\Form\FormBase;<br>use Symfony\Component\DependencyInjection\ContainerInterface;<br><br>@@ -20,7 +20,7 @@ class ExportRecipe extends FormBase {<br>/**<br>* The file system service.<br>*/<br><br>protected FileSystem $fileSystem;<br><br>protected FileSystemInterface $fileSystem;<br><br>@@ -30,7 +30,7 @@ class ExportRecipe extends FormBase {<br>public function __construct(<br><br>FileSystem $file_system<br><br>FileSystemInterface $file_system<br>) {<br>$this-&gt;fileSystem = $file_system;<br>}</pre><h2><strong>Notes</strong></h2> <p> A similar FileSystem type-hinting issue has been fixed previously in another ExportRecipe implementation (ECA side), but the same interface-based typing is still needed here in <code>Drupal\modeler_api\Form\ExportRecipe</code> to support S3FS and other overrides of <code>file_system</code>. ::contentReference[oaicite:0]{index=0}</p>