V 1.3.15 breaks Drupal 10.0.9 installed using Composer via ZipArchive::open()

Created on 2 June 2023, about 1 year ago
Updated 13 September 2023, 10 months ago

Problem/Motivation

Perfectly fine working Composer install of Drupal 10.0.9 breaks when Single Content Sync 1.3.15 is installed by using the line composer require 'drupal/single_content_sync:^1.3' in a terminal view of the base directory, and then running database update.php.

Steps to reproduce

  1. Use Composer to install two instances of Drupal 10.0.9 on a VPS running Apache 2.4.57 and PHP 8.1.19 on Ubuntu 20.04 x64.
  2. Create a custom theme based on Olivero and add a custom logo. Inherit everything else.
  3. Create a dozen simple text pages with links to a sitemap showing the install UI structure.
  4. Test, find that everything works as advertised.
  5. Install Single Content Sync in both instances by entering the command composer require 'drupal/single_content_sync:^1.3' in a SSH terminal window.
  6. Go to the Test instance. Navigate to Content. Select all pages. Set Action to 'Export Content". Click on Apply to selected Items.
  7. Content will list items and ask you if you are sure. Click 'Export.'
    • Deprecated function: ZipArchive::open(): Using empty file as ZipArchive is deprecated in Drupal\Core\Archiver\Zip->__construct() (line 31 of core/lib/Drupal/Core/Archiver/Zip.php).
    • The value of Comments is empty because field type "comment" is not exportable out-of-the-box. Check README for a workaround.
    • We have successfully exported the chosen content. Follow the link to download the generate zip file with the content
    • Latest entry contains a Deprecated Function Debug Report (See attached File #1)
  8. Click on the text link in the Status Message and save zip file to local directory. My example was 28.4 K
    • My content-bulk-export zip file unpacked to the a folder full of the correct number of .yml files.
    • Each .yml file appeared to contain the definition of a 'page' node.
  9. Now move over to the clean install of 10.0.9 via Composer that is the empty Production install, the target for the export.
  10. Go to the Content page. It shows no content. Click on "Import Content."
  11. Browse to the saved content-bulk-export file and upload it as the designated source of the import. Click 'Import."
  12. The 'Importing entities' page will return the following error message:
    • An AJAX HTTP error occurred.
      HTTP Result Code: 500
      Debugging information follows.
      Path: /batch?id=11&op=do_nojs&op=do
      StatusText: 500 Service unavailable (with message)
      ResponseText: The website encountered an unexpected error. Please try again later.
  13. Click the link to the Error Page.
  14. You will return to the Import content page. The error message is The import process finished with an error.
  15. Latest entry contains am Exception Debug Report (See below
  16. Exception: Content source site has another UUID than current one (destination). Make sure that content has been exported from the same instance of the site or disable Site UUID check. in Drupal\single_content_sync\ContentSyncHelper->validateYamlFileContent() (line 192 of /home/nscfd10admin/public_html/prod/web/modules/contrib/single_content_sync/src/ContentSyncHelper.php).
  17. Return to the Test install with the content in it. Click on any content page. Click 'Edit' to bring up the page editor UI. The response is below.
  18. The website encountered an unexpected error. Please try again later.
    
    TypeError: Unsupported operand types: null + array in Drupal\Core\Config\TypedConfigManager->getDefinitionWithReplacements() (line 197 of core/lib/Drupal/Core/Config/TypedConfigManager.php).
  19. Loading the home page in Test now produces the following Warning:
  20. Warning: Undefined array key "undefined" in Drupal\Core\Config\TypedConfigManager->getDefinitionWithReplacements() (line 170 of core/lib/Drupal/Core/Config/TypedConfigManager.php).

So, in summary, loading Single Content Sync 1.3.15 into a clean install allows me to export a zip file generated by ZipArchive. An error message says that the export failed and a status message says it was successful. An attempt to import into the target system fails. The Test system is now broken in several strange ways, among them being that an attempt to Edit an existing page fails at a fundamental manner as a result of line 197 of core/lib/Drupal/Core/Config/TypedConfigManager.php.

This is all connected to the deprecation of ZipArchive (or its predessor) and the need to recode around it. In Drupal 10.0.9 their is either an instance of code that has not been fixed or there is a regression.

Proposed resolution

Determine exactly why /core/lib/Drupal/Core/Archiver/Zip.php(31): ZipArchive->open('/home/nscfd10ad...') is firing off the Drupal Error Handler and fix whatever that reason is.

Remaining tasks

TBD

User interface changes

None

API changes

TBD

Data model changes

TBD

πŸ› Bug report
Status

Closed: works as designed

Version

1.3

Component

Code

Created by

πŸ‡ΊπŸ‡ΈUnited States Cyberflyer

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

Comments & Activities

  • Issue created by @Cyberflyer
  • πŸ‡§πŸ‡ͺBelgium artycal

    Thanks for the detailed report. It seems there have been changes to the ZipArchive in the newest PHP versions. Will take a look at it asap.

  • πŸ‡ΊπŸ‡ΈUnited States Cyberflyer

    Thanks, Artycal.

    I will be out of the office on another project for next week.

    If you could sort this by Monday the 12, to where I can just unload the old version and replace it with the new in composer and not loose the work I've done to date that would be great!

  • πŸ‡ΊπŸ‡¦Ukraine nginex

    Hi @Cyberflyer,

    Thank you for detail report.

    You need to apply a patch from πŸ› Unable to open Zip archive using ArchiverZip Fixed , this patch was already commited to 10.1.x, but for older drupal version the patch is still needed.

    Besides, you have the following error "Content source site has another UUID than current one (destination).", it means that Site UUID check is enabled on /admin/config/content/single-content-sync and you can't import the content on a site with different uuid (usually different site envirnments use the same site uuid), you can turn off the check to test the import.

    Let me know if it helped.

  • Status changed to Closed: works as designed 10 months ago
  • πŸ‡ΊπŸ‡¦Ukraine nginex
Production build 0.69.0 2024