Export/Import throwing ZipArchive::open(): Argument #1 ($filename) cannot be empty in ZipArchive->open()

Created on 9 February 2023, almost 2 years ago
Updated 29 February 2024, 9 months ago

Problem/Motivation

During bulk export/import. Errors are being thrown for the libzip library no longer accepting empty files. The import functionality stops the user completely and it looks really broken. The issue has been found already and there is a dependency in core for it to be fixed. But until then, is there no work around or to get this to not stop the user during importing? They need to keep refreshing the page to get the import to work correctly.

Steps to reproduce

1. Go to the Import page
2. Choose a previously exported zip file with the assets
3. Press Import

Page throws white screen of death with:
The website encountered an unexpected error. Please try again later.
ValueError: ZipArchive::open(): Argument #1 ($filename) cannot be empty in ZipArchive->open() (line 31 of core/lib/Drupal/Core/Archiver/Zip.php).
ZipArchive->open('') (Line: 31)
Drupal\Core\Archiver\Zip->__construct() (Line: 57)
Drupal\Core\Archiver\ArchiverManager->createInstance('Zip', Array) (Line: 73)
Drupal\Core\Archiver\ArchiverManager->getInstance(Array) (Line: 159)
Drupal\single_content_sync\ContentSyncHelper->createZipInstance('/mnt/tmp/mtndecoupledode15/content-bulk-export-09_02_2023-11_19_0.zip') (Line: 467)
Drupal\single_content_sync\ContentImporter->importFromZip('/mnt/tmp/mtndecoupledode15/content-bulk-export-09_02_2023-11_19_0.zip') (Line: 127)
Drupal\single_content_sync\Form\ContentImportForm->submitForm(Array, Object)
call_user_func_array(Array, Array) (Line: 114)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers(Array, Object) (Line: 52)
Drupal\Core\Form\FormSubmitter->doSubmitForm(Array, Object) (Line: 595)
Drupal\Core\Form\FormBuilder->processForm('single_content_sync_import_form', Array, Object) (Line: 323)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 73)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 580)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 169)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 81)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 42)
Drupal\force_password_change\Service\ForcePasswordChangeRedirectMiddleware->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 713)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

πŸ› Bug report
Status

Closed: cannot reproduce

Version

1.3

Component

Code

Created by

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @idesigntocode
  • πŸ‡ΊπŸ‡ΈUnited States briantschu

    I think this is a duplicate of πŸ› PHP 8.1.x. compaitibility Fixed , which was merged into version 1.3.x-dev. Does using the dev version of the module, or applying the patches mentioned in comment #4 on that issue ( #3324392-4: PHP 8.1.x. compaitibility β†’ ) fix the error for you?

  • Status changed to Postponed: needs info over 1 year ago
  • πŸ‡ΊπŸ‡¦Ukraine nginex

    I could not reproduce this issue, it's kind of weird that method createZipInstance accepts correct file path to your zip, but afterwards it gets lost in Drupal core methods.

    Please let me know what Drupal core version do you use?

  • I also had the same problem on PHP 8.0 and 8.1.
    Works without a problem on 7.4
    Drupal version: 9.5.3

  • Hi @briantschu which core patch are you referring to?

    Hi @nginex I'm using 9.5.2 need to bump it to 9.5.3.

    I'm on PHP 8.0

  • Status changed to Active over 1 year ago
  • πŸ‡ΊπŸ‡¦Ukraine nginex

    Going to check with drupal 9.5.x as suggested

  • Status changed to Closed: cannot reproduce over 1 year ago
  • πŸ‡ΊπŸ‡¦Ukraine nginex

    I could not reproduce the issue. I used clean drupal core 9.5.3 installation with php 8.1

    I recommend you to debug getInstance method of ArchiverManager.php class.

    I assume that the code below returns empty value, there might be some issue with handling temporary files on your system.

    $this->fileSystem->realpath($configuration['filepath'])
    
  • πŸ‡¦πŸ‡·Argentina drupal-son

    Hi @nginex,

    I have the same problem.
    I'm using Single Content Sync 1.4.3, Drupal Core 9.5.11 and PHP 8.1.24
    I'm using Acquia hosting.
    I'm not using any Drupal Core patch for this purpose though.

    The weird thing is that the import works fine on dev, qa and uat environments but fails on prod environment.
    All the environments have the same configuration deployed.

    I can export on uat and import into dev or qa but I get the error when importing into prod.

    ValueError: ZipArchive::open(): Argument #1 ($filename) cannot be empty in ZipArchive->open() (line 31 of /mnt/www/html/MYCONTAINER/app/MYAPP/docroot/core/lib/Drupal/Core/Archiver/Zip.php)
    #0 /mnt/www/html/MYCONTAINER/app/MYAPP/docroot/core/lib/Drupal/Core/Archiver/Zip.php(31): ZipArchive->open('')

    I can see on the imported environment (dev, qa, and even prod) at `/admin/content/files` that my file has been uploaded as a temporary status.

    Thanks.

  • πŸ‡¦πŸ‡·Argentina drupal-son

    I can add more info, I guess this might be something related with how and where the temporary files are stored.
    Each Acquia environment have a different Drupal temporary folder configured, it works for all envs except for prod.
    Might be something at the folder level, permissions, symlink or something on how Acquia is handling that temporary folder at `mnt/tmp/MYCONTAINERENV` directory.

    Does this ring any bell?

    Thanks

Production build 0.71.5 2024