Skip to content

Conversation

@moseshll
Copy link
Contributor

@moseshll moseshll commented Jan 20, 2026

  • Remove PEAR from the Dockerfile
  • Install composer with other PHP dependencies
    • composer.json and composer.lock (it's a big one!) are our Gemfile analogues.
  • Use standard autoload line in place of PEAR requires: require_once 'vendor/autoload.php'
  • Add Playwright tests to make sure some of the less commonly used API endpoints are not broken by the composer transition
  • Installation of dependencies to vendor/ (à la bundle install) should not need to be done manually since I have added a lightweight composer service as a dependency for vufind and phpunit in the docker compose. This should work inside the babel project without modification, I hope?
    • There is weak evidence (a possibly hallucinatory Google AI summary) that composer install does not wipe-and-reinstall if vendor/ matches the data in composer.lock, making it a near-noop. If so then this approach should not be burdensome so long as it's reliable.
  • Remove apparently-unneeded PHP extensions installed by the Dockerfile.
  • TODO: stage on dev-2 -- composer is not obviously available there (which composer returns nothing)
  • TODO: deploy script must invoke composer
  • NOT TODO: we are using an old version of phpunit but it does not appear to be a zero-effort upgrade path, so out of scope.

Note: do not merge until we have composer available on the relevant VMs

…h need for messing around with the include path.

- We should have most of PEAR taken care of.
- `test/RecordUtilsTest.php` was having trouble with the `global $htstatus` that PHPUnit wants to set to null.
- PHPUnit vendored (and slightly version bumped, although it is still a couple major versions old).
- Fix two warnings/errors in HTID.php exposed by playwright tests.
…ry to only invoke it when needed.

- Will this get in the way by running too often?
header('Content-type: text/html; charset=UTF-8');
echo "<h1>Not found</h1>";
echo "'$id' is not a valid record identifier.";
echo "'$htid' is not a valid record identifier.";
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bug exposed by playwright tests



header("Location: /Record/$id", true, '301 Moved Permanently');
header("Location: /Record/$id", true, 301);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bug exposed by playwright tests


require_once 'vendor/autoload.php';
require_once 'sys/LoggingPager.php';
require_once 'Pager/Pager.php';
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is Pager/Pager.php PEAR or a built-in? May be able to remove it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's PEAR plus our own subclass Pager_LoggingPager that is indeed used, but I don't know what it brings to the table vs the base PEAR class. It doesn't seem to actually do any logging.



$HT_COLLECTIONS = eval(file_get_contents('__DIR__/../derived_data/ht_collections.php'));
global $htstatus;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

phpunit has a reputation for not playing nicely with globals. These tests apparently broke because we updated the version slightly with composer. This two-line declare/assign is needed to keep the variable from becoming null inside the individual tests.

profiles:
- playwright

composer:
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Run this before another of the PHP services (vufind, phpunit) to make sure the dependencies are there.

@moseshll moseshll marked this pull request as ready for review January 21, 2026 15:50
Copy link
Member

@aelkiss aelkiss left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Haven't tried this out yet but just looking at what's here:

  • Doing the composer install in this way via docker compose looks pretty slick and could be an approach we take with the bundle install in ruby-land.
  • Generally with bundler in ruby we've used a separate volume in the docker compose rather than installing them in the working directory. There are pros and cons either way. If we add them in the working directory we need to make sure the vendor directory is ignored in .dockerignore.
  • As far as deployment, I would probably expect we'd do the composer install in test.catalog as part of staging, then deploy everything.

@aelkiss
Copy link
Member

aelkiss commented Jan 21, 2026

Another thought is that there are a bunch of Debian packages we're installing (php-curl, php-gd, etc) that might be better installed via composer, but so long as things work as expected like this, migrating those could be a second phase of work.

Copy link
Contributor

@liseli liseli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've started the Catalog application locally, and all the features are working smoothly. I'll go ahead and approve it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants