Automated Drupal 11 compatibility fixes for juicebox

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 → these changes make this module compatible with Drupal 11! 🎉
Therefore these changes update the info.yml file for Drupal 11 compatibility.

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.9
3. palantirnet/drupal-rector: 0.20.1

The last submitted patch, 2: juicebox.4.0.0-alpha1.rector.patch, failed testing. View results →
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

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 → these changes make this module compatible with Drupal 11! 🎉
Therefore these changes update the info.yml file for Drupal 11 compatibility.

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

The last submitted patch, 5: juicebox.4.0.x-dev.rector.patch, failed testing. View results →
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

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.3.1
2. mglaman/phpstan-drupal: 1.2.11
3. palantirnet/drupal-rector: 0.20.1

The last submitted patch, 7: juicebox.4.0.x-dev.rector.patch, failed testing. View results →
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

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 → these changes make this module compatible with Drupal 11! 🎉
Therefore these changes update the info.yml file for Drupal 11 compatibility.

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.1
2. mglaman/phpstan-drupal: 1.2.11
3. palantirnet/drupal-rector: 0.20.1

The last submitted patch, 9: juicebox.4.0.x-dev.rector.patch, failed testing. View results →
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

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 → these changes make this module compatible with Drupal 11! 🎉
Therefore these changes update the info.yml file for Drupal 11 compatibility.

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

The last submitted patch, 11: juicebox.4.0.x-dev.rector.patch, failed testing. View results →
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

Would it be possible to integrate the patch into a new module release? I know that there are other outstanding bugs, but this particular change is stalling the upgrade to Drupal 11.

I've tried the patch and Upgrade Status then reported the module as ready for Drupal 11. However, when I tried the upgrade, I think the composer was still grabbing information from the juicebox site and concluding that Drupal 11 upgrade cannot proceed because of the problems.

If you don't intend to integrate this patch into a release soon, is there a way to move to Drupal 11 after applying the patch, without losing data (ie. galleries) that are already on the site?

Thanks,
Milan

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

RTBC +1

fkelly12054@gmail.com → made their first commit to this issue’s fork.

In order to make tests run, we need to integrate gitlab-ci.yml into the branch we are trying to test. A few days ago I put a gitlab-ci yml into the 4.0.x branch but that's not sufficient. We somehow need to replace the drupalci.yml file (Now obsolete) with a gitlab-ci.yml file in the branch we are trying to use for the update.

I am not familiar with all the steps and "privileges" needed to do this. The code that milan, shashi and manishaity are proposing may do this but we need to correct an up-to-date gitlabci.yml file to make it happen.

I will ping (email) our senior maintainer, Luke, to see if he can help move this along.

Personally I am spending all my Drupal time trying to find/develop an alternative recommended approach to using Juicebox for slideshows within Drupal. Nearly 10 years ago the Drupal wizards switched over to using a media module instead of just ftp'ng jpg and xml files up to sites/files. All the recent developments for slideshows are using media. I think that the patches now pending may get us to a stable Drupal 11 release but I recommend that we plan to make Juicebox obsolete after that.

Sorry for the delays and for my lack of expertise.

The update bot has messed up the support ranges here.

The deprecation helper service was introduced in Drupal 10.1.3, but it has the module support range specified as >=10. That means that 10.0.0 through 10.1.2 users would have their sites killed by this.

The support range has to be at minimum ^10.1.3 || ^11 here. I strongly recommend using ^10.3 || ^11 since that's what we're able to test on though...

Setting back to needs work. If no one else picks this up before I'm able to, I'll make the commit myself, but in the meantime feel free.

This module does, indeed need work, as there are missing schema definitions.

Leaving NW so that someone can look into the test failures, or I can pick them back up when I'm able.

Green on 10.4.0, 11.0.8, and 11.1.0.

Testing on PREVIOUS_MAJOR, PREVIOUS_MINOR, and CURRENT seems very logical to me. Setting to Needs Review for manual testing.

luke.leber → closed merge request !12

luke.leber → changed the visibility of the branch 3433346-automated-drupal-11 to hidden.

luke.leber → changed the visibility of the branch 4.0.x to hidden.

I've manually tested the common use cases for this module against 11.1 and 10.4 including...

1. Media reference field configured to display juicebox formatters
2. Image field configured to display juicebox formatters
3. View configured to display content as juicebox galleries

Given we have green tests and a solid manual test, I'm going to merge this in and cut 4.0.0-alpha2 for folks waiting. If anything did manage to slip through, I'll be available to triage things throughout the week after the day job.

Stand by for 4.0.0-alpha2 as soon as the main pipeline goes green.

I have run all the code in Juicebox through PHPCS locally. Using the latest version of coder. I also applied many changes suggested by PHPstorm ... most of them cosmetic and/or spelling type "things".

I don't want to mess up the merge process so would like some direction. Where should I put the changed files. A new merge? And for what version?

I can see that there are other tests that we have failures on besides PHPCS, but this should be a start. Running "C:\webpage\compg_6>phpcs --standard=Drupal web\modules\contrib\juicebox" from the DOS prompt comes back clean.

The program named JuiceboxGalleryInterface was a real nightmare. Some of the code in it was deprecated by PHP changes about 8 years ago.

A first step is probably to get all of the changes needed in place that Gitlab needs to get all of the jobs green. That's a standardized set of tooling that everyone can share. I think https://www.drupal.org/project/juicebox/issues/3351683 📌 [PP-1] Resolve all coding standard violations Postponed is the place for that work I think. Any commit made to the issue fork over there will automatically run those tests.

Koustav Mondal self-assigned that issue to them self, but hasn't made any commits in a week, so IMO it's fair game for anyone to commit to.

Things like phpstorm configuration will probably vary from person to person, but the gitlab tests are a shared configuration between everyone. They should probably be resolved first before making any other changes so that everyone's on the same page with the standard checks.

After the gitlab checks are all passing, so long as further changes don't make the checks fail, they can probably be applied in a follow-up.

Automatically closed - issue fixed for 2 weeks with no activity.