Get tests passing on Gitlab CI

FINALLY! A green run that actually runs the tests.

Setting to NR.

Given these are test-only changes, I'll merge this in tomorrow evening if it hasn't been reviewed by then so we can move onto the Drupal 11 compatibility issue with confidence and get that one finished up by the weekend. 👍

I can see that you have a gitlabci.yml in the 4.0.x-dev version and that it runs the tests okay. So, if it helps, I'll change the status to rtbc. If I understand the process correctly we need a gitlabci.yml that updates the one I did about a week ago in the 4.0.x directory.

Educate me if I misunderstand this process and I will be as much help as I can. If we can get a working 4.0.x version (or whatever we call it and including Drupal 11 changes, I can run it locally for further testing). Looks like 10.4 is released and I'll update my sites to that (both locally and live (hosted) and give the latest Juicebox version a try there.

luke.leber → credited cmlara → .

luke.leber → credited drumm → .

luke.leber → credited moshe → .

Now that I've merged this in,pulling in the 4.0.x branch on a dev site via composer require drupal/colorbox:dev-4.0.x will pull in the latest development build for the 4.0.x branch.

Subsequent patches can be applied on top of that. I'll see you over in the Drupal 11 issue.

copy and paste gone awry? From #12?
require drupal/colorbox:dev-4.0.x

composer require 'drupal/juicebox:4.0.x-dev@dev' You mean?

I used the latter earlier this morning and it installed the latest Juicebox just fine. Unfortunately my local (Wampserver) test site has some other problems so I have work to do before I can test.

Having the composer install process available to all of us is a great convenience. Thanks Luke!

Updated my "production" site (fkelly.org) to 4.0.x-dev alongside updating it to Drupal core 10.4.0. The good news is that the update "generally" worked. Afterwards I manually compared code. I thought it was strange that the code in my hosted fkelly.org site, the display of modules in the "extension" screen and even drush pml didn't show a version for Juicebox. On my local system there is a version of info.yml:

# Information added by Drupal.org packaging script on 2024-12-19
version: '4.0.0-alpha2'
project: 'juicebox'
datestamp: 1734574881

Looking at info.yml files for other contrib modules, the version info seems to be present. So I'm not sure whether this is a problem or not.

At any rate the version info is missing from the code in the hidden branch juicebox-3433346. I guess that if the packaging script is going to add it then we don't want it in the file? Otherwise, the coding changes in the recent commits are now on my production system. And Juicebox 4.0.x-dev seems to work in testing I've had time for so far. At any rate, there is no version in the hosted version of the info.

I haven't gotten to testing any Drupal 11 versions yet. That may take a while since I need to install it locally.

I've been running phpcs locally and using its automatic fix feature (phpbcf option) and making the changes locally in my PHPstorm copies of the files. PHPstorm has a LOT of other suggestions too and I've been making them.

The JuiceboxGalleryInterface.php program has been giving me fits. I've literally spent hours on it. PHPCS doesn't recognize the doc comment at the top. If I let it (phpcs) try to fix it then it doesn't recognize its own fixes as valid. I've looked at how other Drupal programs handle this and don't get any bright lights shining on what to do. Literally spent 2 to 3 hours this morning on a half-dozen lines of code and probable a dozen approaches. Looked in the Drupal coder issue queue and the usual search engines.

From some of what I've fixed it seems like there are sections of code that go back to 2015 and Drupal 7 days. I think I've found fixes for those but am not sure they are even being used anymore.

Not sure if you @koustav_mondal are actively working on this ... if so we should coordinate efforts. If I can get the JuiceboxGalleryInterface program fixed I will be just about ready to push something up for a merge. This only takes care of a section of the test failures shown through various code inspection tools.

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