Automated Drupal 11 compatibility fixes for media_bulk_upload

This is an automated patch generated using Upgrade Status and Drupal Rector. Please see the issue summary for more details. A merge request is also openend and updated.

It is important that any automated tests available are run and that you manually test the changes.

Drupal 11 Compatibility

According to the Upgrade Status module → , even with these changes, this module is not yet compatible with Drupal 11.

Currently Drupal Rector, version 0.20.1, cannot fix all Drupal 11 compatibility problems.

Therefore these changes did not update the info.yml file for Drupal 11 compatibility.

Leaving this issue open, even after committing the current patch, will allow the Project Update Bot → to post additional Drupal 11 compatibility fixes as they become available in Drupal Rector.

Debug info

This patch was created using these packages:

1. drupal/upgrade_status: 4.1.0
2. mglaman/phpstan-drupal: 1.2.7
3. palantirnet/drupal-rector: 0.20.1

This comment was forced and has ignored the check if a change was already posted. This is only done when we want to update the issue without waiting for changes to happen.

This is an automated patch generated using Upgrade Status and Drupal Rector. Please see the issue summary for more details. A merge request (MR) is also openend and updated.

It is important that any automated tests available are run and that you manually test the changes.

Drupal 11 Compatibility

According to the Upgrade Status module → , even with these changes, this module is not yet compatible with Drupal 11.

Currently Drupal Rector, version 0.20.1, cannot fix all Drupal 11 compatibility problems.

Therefore, these changes did not update the info.yml file for Drupal 11 compatibility.

The compatibility issues that Upgrade Status found after the Drupal Rector fixes were applied are attached to help you resolve them manually.

Leaving this issue open, even after committing the current patch or merging the MR, will allow the Project Update Bot → to post additional Drupal 11 compatibility fixes as they become available in Drupal Rector.

Debug information

These packages were used to generate the fixes:

1. drupal/upgrade_status: 4.1.0
2. mglaman/phpstan-drupal: 1.2.10
3. palantirnet/drupal-rector: 0.20.1

This is an automated patch generated using Upgrade Status and Drupal Rector. Please see the issue summary for more details. A merge request (MR) is also openend and updated.

It is important that any automated tests available are run and that you manually test the changes.

Drupal 11 Compatibility

According to the Upgrade Status module → , even with these changes, this module is not yet compatible with Drupal 11.

Currently Drupal Rector, version 0.20.2, cannot fix all Drupal 11 compatibility problems.

Therefore, these changes did not update the info.yml file for Drupal 11 compatibility.

The compatibility issues that Upgrade Status found after the Drupal Rector fixes were applied are attached to help you resolve them manually.

Leaving this issue open, even after committing the current patch or merging the MR, will allow the Project Update Bot → to post additional Drupal 11 compatibility fixes as they become available in Drupal Rector.

Debug information

These packages were used to generate the fixes:

1. drupal/upgrade_status: 4.3.2
2. mglaman/phpstan-drupal: 1.2.11
3. palantirnet/drupal-rector: 0.20.2

Rector fixes were pretty sketchy; took a stab at manually fixing them.

MR!17 Makes this module compatible with Drupal 11. Functionality is working as expected.

RTBC +1

There are, apparently, 3 branches, 3 merge requests, and 3 patches associated with this issue. Both !16 and !17 were updated recently when I wrote this comment. I code reviewed both branches.

!17:

1. adds a valid-but-unconventional core_version_requirement: '>=10.2',
2. adds a .gitlab-ci.yml (even though that wasn't part of the issue scope),
3. src/Form/MediaBulkUploadForm.php is missing a newline at the end of the file,
4. MediaTypeManager::getTargetFieldMaxSize() has a change that looks like:
   

   -return !empty($targetFieldSettings['max_filesize']) ? $targetFieldSettings['max_filesize'] : (string)
   format_size(Environment::getUploadMaxSize());
   +return !empty($targetFieldSettings['max_filesize']) ? $targetFieldSettings['max_filesize'] : (string)
   DeprecationHelper::backwardsCompatibleCall(\Drupal::VERSION, '10.2.0', fn() =>
   ByteSizeMarkup::create(Environment::getUploadMaxSize()), fn() => format_size(Environment::getUploadMaxSize()));
       

   ... in this change, I like the use of \Drupal\Component\Utility\DeprecationHelper, but it was missing a fallback value that is present in !16 (i.e.: ?? 0, see below)

!16 is identical to !17, except for the following things:

1. !16 has a more-conventional core_version_requirement - which notably didn't reflect the change in MediaTypeManager::getTargetFieldMaxSize() below,
2. !16 does not add a .gitlab-ci.yml (in keeping with the issue scope),
3. src/Form/MediaBulkUploadForm.php has the newline at the end of the file,
4. MediaTypeManager::getTargetFieldMaxSize() has a change that looks like:
   

   -return !empty($targetFieldSettings['max_filesize']) ? $targetFieldSettings['max_filesize'] : (string)
   format_size(Environment::getUploadMaxSize());
   +return !empty($targetFieldSettings['max_filesize']) ? $targetFieldSettings['max_filesize'] : (string)
   ByteSizeMarkup::create(Environment::getUploadMaxSize() ?? 0);
       

   ... I like the fallback (?? 0), but it is missing the use of \Drupal\Component\Utility\DeprecationHelper, which would drop support 10.2, as ByteSizeMarkup doesn't exist in 10.2.

My recommendation is that we...

1. Hide all the files associated with the ticket to reduce confusion (I will do this)
2. Close !13 and !16 (I will do this)
3. Change the core_version_requirement in !17 to something like core_version_requirement: ^10.2 || ^11
4. Add the newline to the end of src/Form/MediaBulkUploadForm.php in !17
5. Delete the .gitlab-ci.yml in !17
6. Add the fallback (i.e.: ?? 0) to the MediaTypeManager::getTargetFieldMaxSize() return statement from !16.

... if someone who isn't me could take on the last 4 tasks, then I can test again, and re-mark this as RTBC if it all works... my client wants this module updated to D11 so I have been assigned some time to help out in the next month or so.

mparker17 → changed the visibility of the branch project-update-bot-only to hidden.

mparker17 → changed the visibility of the branch 3431856-automated-drupal-11 to hidden.

Change the core_version_requirement in !17 to something like core_version_requirement: ^10.2 || ^11 (made this change)
Add the newline to the end of src/Form/MediaBulkUploadForm.php in !17 (added the new line )
Delete the .gitlab-ci.yml in !17 (deleted the gitlab-ci.yml)

@shashi_shekhar_18oct, thank you very much!

Quick process note: as a general rule, you shouldn't mark your own changes as RTBC → ("it works on my machine" is a cliché because it happens to all of us, regardless of our experience-level!).

So I'm moving it back to "Needs review" for now... but I have time to code review now, test on my own site, and if everything works, mark it as RTBC!

Thanks again!

Taking a look at the code in merge request !17, I found the following things that will need to be fixed:

1. There's still an instance of the old core_version_requirement: '>=10.2' in modules/dropzonejs/media_bulk_upload_dropzonejs.info.yml

... so I'm marking this as "Needs work".

Running manual tests, I couldn't get !17 to work on D11, so I'm marking this as "Needs work". I'm not yet sure if this is something that I'm doing wrong, or an actual problem with D11 compatibility. I'm going to test again on a different computer to see if my setup on this one is broken.

Here's what I did to test !17...

1. Install ddev (I tested on version 1.24.1)
2. Clone the module, issue fork, and branch:
   1. git clone https://git.drupalcode.org/project/media_bulk_upload.git && cd media_bulk_upload - clone the project
   2. git remote add media_bulk_upload-3431856 git@git.drupal.org:issue/media_bulk_upload-3431856.git && git fetch media_bulk_upload-3431856 - add a remote for the issue fork
   3. git checkout -b '3431856-d11_ready' --track media_bulk_upload-3431856/'3431856-d11_ready' - switch to the branch for merge request !17
3. Set up a test site for the module with the ddev/ddev-drupal-contrib plugin:
   1. ddev config --project-type=drupal --docroot=web --php-version=8.3 --corepack-enable --project-name=media-bulk-upload - create a ddev project for testing the module
   2. ddev add-on get ddev/ddev-drupal-contrib && ddev start && ddev poser && ddev symlink-project - run the setup steps for the ddev/ddev-drupal-contrib addon
   3. mkdir -p web/libraries/dropzone && curl -L -o web/libraries/dropzone/dropzone.min.js https://unpkg.com/dropzone@5/dist/min/dropzone.min.js - quickly download and install the latest 5.x version of dropzonejs
   4. mkdir -p temp-documents - create a folder outside the webroot to hold the bulk-uploaded documents before the media entities are fully created
   5. Go to https://media-bulk-upload.ddev.site/core/install.php in a browser. Confirm that I saw the Drupal 11.0.9 installer. Install the site with the "Standard" install profile.
   6. Go to /admin/people/create and create a user with the Content editor role. I gave mine the username test_editor.
4. Set up the module for testing:
   1. Go to /admin/modules and install media_bulk_upload and its dependencies
   2. Go to /admin/modules and install dropzonejs and its dependencies
   3. Go to /admin/config/media/media-bulk-config/add, and enter:
      • Label = File
      • Media types = Document
      • Form mode = - None -
      • Upload location = ../temp-documents (I tried various other values for this, see below)

      ... then click Save. You see the status message "Created the File Media Bulk Config."

   4. Go to /admin/people/permissions/module/media_bulk_upload, grant the Content editor role the following permissions:
      • dropzonejs -> Dropzone upload files
      • Help -> Use help pages
      • Media Bulk Upload -> File : Use upload form
      • Media Bulk Upload -> Configure Media Upload form
5. If you don't already have a bunch of files to bulk-upload for testing, you can generate 9 ".doc" files with the following command in sh or bash: cd ~/Desktop && mkdir test_media_bulk_upload && cd test_media_bulk_upload && for planet in Mercury Venus Earth Mars Jupiter Saturn Uranus Neptune Pluto; do echo $planet > $planet.doc ; done (if you use some other shell, your mileage may vary)
6. Test the basic module functions in Drupal 11:
   1. Log out of the administrator account, and log in as the test_editor Content editor user created earlier.
   2. Go to /admin/help/media_bulk_upload. Confirm that I can see a help page.
   3. Go to /admin/config/media/media-bulk-config. Confirm that I can see a "Bulk upload media" configuration page.
   4. Click Edit next to the File Media Bulk Config I created earlier. Confirm that I can see a "Edit File" form. Click "Save" without making any changes. Confirm that I can see the status message "Saved the File Media Bulk Config."
   5. Go to /media/bulk-upload/file. Confirm that I can see a "Multiple upload" form.
   6. Try bulk-uploading some of the files I generated earlier.
      • Expected behavior: the files were successfully uploaded
      • Actual behavior: I got an error, The file could not be uploaded because the destination "../temp-documents/" is invalid
        • I tried various other things for Upload location in the configuration... /var/www/html/temp-documents, sites/default/files/temp-documents, etc. These were reflected in the error message, suggesting they were properly saved; but I got the same error in each case.
7. Make sure there are no errors being logged:
   1. Log out of the test_editor user created earlier; and log in as the administrator again
   2. Go to /admin/reports/dblog to ensure our setup/testing did not result in any error messages related to this module.

Okay... when I tried this a second time on a different computer, my test case of the basic module functions worked perfectly. As far as I'm concerned, this means the module is working correctly.

@shashi_shekhar_18oct, if I could trouble you to change the core_version_requirement line in modules/dropzonejs/media_bulk_upload_dropzonejs.info.yml from core_version_requirement: '>=10.2' to core_version_requirement: ^10.2 || ^11 as you did before, then I'll do one last code review/test, then mark this as RTBC.

Thank you very much in advance!

I’ve made the requested changes: please review!

@cb_govcms, good catch, thank you!

@nghua, thanks for fixing the issues raised by myself and @cb_govcms. (I don't have permission to mark the thread that @cb_govcms started as "resolved" however)

I've code-reviewed the updated merge-request, and I'm happy with it. I also re-ran my test case from earlier on a freshly-cloned copy of the merge request, and it works for me.

I'm going to mark this as Reviewed and Tested by the Community. Thanks everyone!

This is an automated patch generated using Upgrade Status and Drupal Rector. Please see the issue summary for more details. A merge request (MR) is also openend and updated.

It is important that any automated tests available are run and that you manually test the changes.

Drupal 11 Compatibility

According to the Upgrade Status module → , even with these changes, this module is not yet compatible with Drupal 11.

Currently Drupal Rector, version 0.20.3, cannot fix all Drupal 11 compatibility problems.

Therefore, these changes did not update the info.yml file for Drupal 11 compatibility.

The compatibility issues that Upgrade Status found after the Drupal Rector fixes were applied are attached to help you resolve them manually.

Leaving this issue open, even after committing the current patch or merging the MR, will allow the Project Update Bot → to post additional Drupal 11 compatibility fixes as they become available in Drupal Rector.

Debug information

These packages were used to generate the fixes:

1. drupal/upgrade_status: 4.3.6
2. mglaman/phpstan-drupal: 1.3.2
3. palantirnet/drupal-rector: 0.20.3

The MR applies and I can update my project from D10 to D11 using drupal lenient.
But when I try to use media_bulk_uploads, I get this error:
Call to a member function guessMimeType() on null

comming from this piece of code:

      $show_alt = (boolean) $media_bulk_config->get('show_alt');
      $alt_required = (boolean) $media_bulk_config->get('alt_required');
 
      foreach ($uploaded_files as $uploaded_file) {
        $errors = [];
 
        // Validate file alt.
        $mime = $this->mimeTypeGuesser->guessMimeType($uploaded_file['path']);

The mimeTypeGuesser is never instantiated.

Hoping for a tag release soon to ease and speed up testing and updates in projects.

☝

Hello,

I contacted a maintainer and was told it was on their todolist.

+1 for RTBC! A tagged release would be great please!