[Bug]: release source ships without vendor folder, composer install fails due to impossible require-dev

[ross-mulcahy]

Description of the bug

Versions 0.3.0 and 0.3.1 cannot be installed from the release source or rebuilt with Composer. Users see the admin notice:

No suitable autoloader found. Multisite Global Media cannot be loaded correctly.

Reproduction instructions

Versions 0.3.0 and 0.3.1 cannot be installed from the release source or rebuilt with Composer. Users see the admin notice:

No suitable autoloader found. Multisite Global Media cannot be loaded correctly.

Root causes

1. Release source ships without vendor/. The source archives for the 0.3.0 and 0.3.1 tags do not contain vendor/autoload.php. The bootstrap in multisite-global-media.php requires exactly plugin_dir_path(__FILE__) . '/vendor/autoload.php', so the plugin fails to load on any install that wasn't built with Composer first.

2. composer install fails on a clean clone. composer.json in master declares:

   "require-dev": {
       "phpunit/phpunit": "^12.5.22",
       "woocommerce/woocommerce": "^6.6.0"
   },
   "config": {
       "platform": { "php": "7.0.0" }
   }

   • phpunit/phpunit ^12.5.22 requires PHP >= 8.3, which contradicts config.platform.php = 7.0.0.
   • woocommerce/woocommerce ^6.6.0 is not resolvable on Packagist (max published is 5.x).

   Composer refuses to resolve the graph, even with --no-dev, because it still evaluates dev requirements during resolution. So users cannot regenerate the autoloader themselves from the tagged source.

3. composer require bueltge/multisite-global-media fails on modern projects. The plugin pins composer/installers: ^1.2. Any project already using composer/installers v2 (common with modern WP scaffolding) gets a resolver conflict and has to be told to downgrade with -W.

Expected behavior

Steps to reproduce

curl -L -o src.zip https://codeload.github.com/bueltge/multisite-global-media/zip/refs/tags/0.3.1
unzip src.zip && cd multisite-global-media-0.3.1
composer install --no-dev --optimize-autoloader

Result:

Your requirements could not be resolved to an installable set of packages.
  Problem 1
    - Root composer.json requires woocommerce/woocommerce ^6.6.0, found woocommerce/woocommerce[... 5.9.1] but it does not match the constraint.
  Problem 2
    - Root composer.json requires phpunit/phpunit ^12.5.22 -> satisfiable by phpunit/phpunit[12.5.22, 12.5.23, 12.5.x-dev].
    - phpunit/phpunit[12.5.22, ..., 12.5.x-dev] require php >=8.3 -> your php version (7.0.0; overridden via config.platform, actual: 8.3.6) does not satisfy that requirement.

Installing the plugin directory as-is into wp-content/plugins/ then shows the autoloader admin notice because vendor/ was never created.

Environment info

Environment

• Plugin versions affected: 0.3.0, 0.3.1
• Composer: 2.7.x
• PHP: 7.x, 8.x (both fail, for different reasons on the dev-deps side)
• WordPress: multisite, any recent version

Additional context

Suggested fixes

• Attach a built release zip (with vendor/ included, produced via composer install --no-dev --optimize-autoloader) to the 0.3.x GitHub release. Earlier releases (e.g. 0.2.0) did this and the README's installation instructions still assume it.
• Fix require-dev so a fresh clone can run composer install:
  • phpunit/phpunit: constrain to a range compatible with config.platform.php, e.g. ^9.6 for PHP 7.x, or bump the platform.
  • woocommerce/woocommerce: use an existing version range (e.g. ^5.9 or ^7.0, depending on what's actually being tested against).

Happy to open a PR for the composer.json changes if helpful.

Workaround for other users landing here

Build the autoloader locally by temporarily removing require-dev before running Composer:

jq 'del(."require-dev", ."autoload-dev", .scripts)' composer.json > tmp && mv tmp composer.json
composer config --no-plugins allow-plugins.composer/installers true
composer install --no-dev --optimize-autoloader

Then restore composer.json and deploy the plugin folder (with the generated vendor/) to wp-content/plugins/multisite-global-media/.

Code of Conduct

• I agree to follow this project's Code of Conduct

[bueltge]

HI @ross-mulcahy Thanks for this helpful feedback. Would you fix this from your machine; because I'm currently the most of the time away from a dev keyboard? I would add you as contributor that you have the possibility to leave a new tag.