Handling of plugins

[matthewbdaly-mission]

I'm sure the whole Automattic - WPEngine drama isn't exactly news to anyone, but one potential consequence occurred to me.

The post at https://wptavern.com/developers-remove-plugins-from-wordpress-org-repository-after-acf-controversy mentions that a handful of plugin providers are making plans to migrate away from hosting their code on wordpress.org, and at this point it wouldn't be a huge surprise if more did the same. Since WordPress Packagist mirrors that, there's potential for disruption to sites using these plugins.

My question is, how would this be handled in principle? I had a search through the issues to see if it made any mention of how removed plugins are handled, but couldn't find anything. I'd imagine that seeing as this mirrors the Wordpress plugin and theme directories, then any plugins or themes which disappear from those would be marked as abandoned.

Obviously, in an ideal world, for those that are going to be available through an alternative means such as a GitHub repository, they would be published direct to Packagist and WPackagist would mark them as the replacement so switching would be a simple matter of changing the repository name. However, I fully appreciate that that isn't likely to happen given that it's almost certainly going to be a manual task, and some plugins might use other means. I don't imagine the number of plugins affected are likely to be huge, and doing a Google search for the new plugin repository and updating our project's composer.json isn't a big task.

[matt-bernhardt]

WPackagist, as I understand it anyway, is a bridge between the Wordpress directory and the Composer ecosystem, allowing folks who deploy Wordpress via composer.json to declare their plugins and themes like any other dependency.

If an author takes their plugin or theme out of the directory and publishes it directly to Github, wouldn't it be possible to update that entry in my composer.json to point to the new Github repo?

[matthewbdaly-mission]

@matt-bernhardt Yes, it would be entirely possible to do that in those circumstances. What I'm more concerned about is the possibility of the packages not being flagged as abandoned, and anticipating the potential chore of migrating to a different installation method for packages which are going to move to be only available directly from the vendor.

The ideal situation would be something like this:

• Plugin author migrates plugin from Wordpress directory to Github and publishes it on Packagist
• WPackagist updated to mark plugin as abandoned with link to replacement Packagist version
• I run composer update on a project, note that the package is abandoned with a link to the replacement, and update that entry to point to the new Packagist version

However, I fully anticipate this might not be practical. Since, as you mention, WPackagist simply mirrors the Wordpress plugin and theme directories, it doesn't sound like there's any consistent way it could pick up any new repository details. In addition, in many cases the plugins aren't going to be published via GitHub or a similar service and made available directly on Packagist, but will instead be made available via the vendor's own site.

For instance, the plugin mentioned in the article above has a blog post about their plans where they mention that users need to re-download it from their site, and then future versions will be installed using the standard Wordpress update mechanism. This strikes me as a more typical scenario, and unfortunately doesn't really help those using Composer to install plugins.

As a result, it sounds to me like the following scenario is more likely to happen with plugins which take similar steps:

• Plugin author removes plugin from Wordpress directory and publishes it via their own site
• WPackagist updated to mark plugin as abandoned without a replacement specified
• I run composer update on a project, note the package is abandoned, and no replacement is specified. I therefore have to use one of the methods historically used for premium plugins (eg add them as a zip to the repository or publish them with a private Composer repository)

It's not that we can't do this, but it is a potential chore, and I'm hoping to clarify what's likely to happen with plugins that do something like this so we can anticipate dealing with it on future work.