Closed plugins aren't available to install

[ethanclevenger91]

This suggests that while this plugin is currently closed (temporary, per the repo), it should still be available to install via Composer. But when I attempt to install it:

➜  public git:(main) ✗ composer require wpackagist-plugin/directorist

In PackageDiscoveryTrait.php line 361:

  Could not find package wpackagist-plugin/directorist.

  Did you mean this?
      wpackagist-plugin/directorist-wpml-integration

It's unavailable. This is destructive in a situation where I've already required this package and on a fresh, cache-less composer install, it will fail to resolve.

Potentially the issue here is that ultimately, the SVN repo is referenced rather than mirrored, and WP.org is not currently making those endpoints available?

Ideally, something like a temporary closure should continue to function, whereas a permanent closure would use the established Composer functionality around abandoned packages. Not sure if the WP repo API offers that kind of granular information in that scenario.

[NoelLH]

Hey @ethanclevenger91 – the process definitely relies on what's in SVN. So I don't see what we can do really if a version is unpublished by its author or by WordPress.org. There are already some questions about running costs with just the metadata traffic we send out, so I don't think mirroring is ever likely to be an option.

I didn't see what happened with this plugin while it was unavailable – it now appears to be back? – but I'm also pretty sure there is no special metadata the WP API would supply to distinguish this case.

I'd also be a bit nervous about any method that does keep unpublished versions mirrored silently, since one reason I have encountered recently for a plugin being suspended was WordPress spotting a new piece of frontend malware embedded in a previously legitimate plugin. While it's annoying, composer install breaking and alerting me to this was still the best feasible outcome. (I would also recommend using more proactive malware scanning in parallel if you are not 100% confident in any plugin.)

[ethanclevenger91]

Thanks for clarifying. yeah - adding a mirroring component to WPackagist seems wrong. I think this is a shortcoming in the WP repo system. Most other platforms "archive" libraries rather than make them completely unavailable.

[ethanclevenger91]

@NoelLH I've run into this again with https://wordpress.org/plugins/hotjar/, and I noticed that despite the plugin being closed, I can pop open SVN and could pull down an old version if I want.

Is there a shortcoming perhaps in the WP plugin repo API preventing that from also being available on WPackagist?

[NoelLH]

Hey @ethanclevenger91 – the update process does definitely use the WordPress.org API too, so I think it's expected that Wpackagist would stop surfacing a plugin as active while it's suspended on WordPress.org itself.

[ethanclevenger91]

@NoelLH Thanks for clarifying. I'm bringing this issue to maintainers. The behavior is destructive and I think the API could handle this in a more sophisticated way.