Request for feedback: Should this plugin exist?

[junaidbhura]

Hello everyone 👋

I'm the author of this plugin.

The original idea behind this plugin was to build a solution to fill the gap in WordPress world for package management for Pro plugins.

But as time has progressed, it appears there's no real consensus in the WordPress community about how this should be handled.

There should ideally be a standard or protocol for this created by WordPress core itself, so everyone can follow the same rules.

To add to this complexity, vendors like WP All Export / Import and others add Cloudflare to limit pings to their infrastructure, and rightly so, which makes this plugin unreliable for production use.

I have personally stopped using this plugin and have stopped recommending its use to others. I've found its actually more reliable to have private Git repos of plugins, and to just add those to any projects I'm working on. This way there's a near 100% guarantee of success every time. And that's what it comes down to.

Is it really worth spending our time to continue to support this solution to save just a little bit of engineering time? Or are we just adding more complexity to the WordPress world?

Please let me know what you think, and how you use this plugin, and what problems it solves for you!

[junaidbhura]

@mcaskill Lemme know what you think!

[justlevine]

When it works, it works great, and every plugin I don't need to manually upload and serve myself is a win in my book.

I understand if you don't feel it's worth maintaining tho 🤷‍♂️

[mcaskill]

There should ideally be a standard or protocol for this created by WordPress core itself, so everyone can follow the same rules.

Absolutely.

To add to this complexity, vendors like WP All Export / Import and others add Cloudflare to limit pings to their infrastructure, and rightly so, which makes this plugin unreliable for production use. […] I have personally stopped using this plugin and have stopped recommending its use to others.

I have also, recently, stopped using this Composer plugin because it was not working reliably for other WP plugins (Ninja Forms, PublishPress) as we moved from development to staging on a distributed server. I've moved most WP plugins to ZIP files stored in the project's VCS repository to avoid the risk of an external private Composer repository failing to connect. I've also had to fork a few plugins (Ninja Forms), so they've become their own repositories.

Is it really worth spending our time to continue to support this solution to save just a little bit of engineering time? Or are we just adding more complexity to the WordPress world?

I am torn. I don't know. When it works, it's convenient. We are indeed adding a false sense of ease (in the form of more complexity) to avoid the complexities introduced by others (the commercial WP plugin vendors). The past few client projects I've worked on have made me question Composer's usefulness with WordPress.

---

If this Composer plugin were to continue, an additional maintainer could be helpful if you are disinterested.

Regardless if this Composer plugin continues to be maintained or is archived, I would suggest adding a notice stating its not recommended for production due to the fickle nature of the supported vendors.

If this plugin were to continue, I would suggest adding an issue template stating that reporting issues about vendors' availability will be closed.

I would probably polish up my open pull requests, propose we have those merged. Maybe add an option to allow minor/patch versions to be installed; the version blocking has been very useful but is very annoying for WP plugins that frequently update, especially across collaborators.

[junaidbhura]

Thanks @mcaskill and @justlevine

The big takeaway here is that this plugin is unreliable for production use on critical sites.

Given that both @mcaskill and I don't professionally recommend it anymore, I think we should archive this project and mark it as read-only.

@mcaskill Lets leave the PRs open here for historic purposes, but maybe not merge it in. Don't want to introduce any inadvertent issues on the eve of decommissioning this project 🥲

We have a responsibility to encourage people to use more robust solutions, so perhaps not accept any further patches or fixes.

Let me know if you are on board with making this repo read-only effective immediately.

[jameelmoses]

For the non-WPAI plugins (e.g. ACF and Gravity Forms), I've never had a single issue using this plugin on literal dozens of sites. I'd hate for this to be abandoned because of restrictions/limits for specific plugins.

[alapiere]

Composer user here, I've spent hours/days finding the sweet spot for handling website repository with premium plugins; so I've considered this plugin, but ended out rejecting it as part of my flow, because:

• it could never be a comprehensive list of Premium plugin, so partial support is not much usefull..
• it can never be an acceptable solution for premium plugin editor, so it can not be reliable
• premium plugins editor move more and more towards direct composer support (ACF, WP Migrate, freemius, ..)
• For the others, either ReleaseBelt, or Satispress can be generic solutions. Using satispress with great success

But a huge thank you for contributing to the ecosystem !
my 2 cents

[jmotes]

@junaidbhura I don't know if I can fully answer your question (should this plugin exist?). I really appreciate the work you've put into this project and it's been very helpful in the past. And, we are still using it for Gravity Forms and ACF without too many issues. I saw ACF finally put out composer support and I'll be switching over to it before long, so Gravity Forms is our only use for this repo currently.

I thought I'd mention the solution I've landed for the plugins we use that don't have reliable composer support incase it's helpful to anyone else here. I don't think this is an ideal solution for the future of WordPress by any means, but it helps us continue on until companies adapt a better standard (or support composer).

I uploaded all of our premium plugins to Azure Blob Storage, making sure to append the version to each zip file, then added the list of them in a text file in the repo.

Then I added a step similar to this to our GitHub Actions build workflow:

- name: Download plugins from storage
  run: |
    cd $GITHUB_WORKSPACE/wp-content
    mkdir -p temp
    while IFS="" read -r p || [ -n "$p" ]
    do
      az storage blob download \
        --account-name ${{vars.STORAGE_ACCOUNT_NAME}} \
        --container-name ${{vars.STORAGE_CONTAINER_NAME}} \
        --name "$p" \
        --file "temp/$p" \
        --account-key ${{secrets.STORAGE_ACCOUNT_KEY}}
    done < plugins-from-storage.txt
    cd temp
    unzip -q \*.zip
    rm *.zip
    mv * ../plugins/

If we ever need to update the plugin, we have to (1) upload the new zip file to the container and (2) update the version # in the text file.

[davidwebca]

I am on the same boat as everybody. I love it when it works and it saves me so much time that I'd hate to see it go unmaintained. Obviously, we should push WordPress to have official guidelines, but in the meantime, I'm still using this for multiple plugins in the list. I've hit some of the issues mentioned, but not very often and I'm still able to direct people here to read about those issues and learn how to avoid them.

I personally like how WP Engine / ACF has implemented the http-basic auth.json method for private repositories. The official version is pretty pricey, but there's Repman that offers the same functionality for free and has the advantage of being a proxy to Packagist which is an extra layer of security (packages that are taken off of packagist will stay on repman). I can't vouch personally since I haven't gotten the opportunity to use them yet, but heard good things. https://repman.io

[Twansparant]

@junaidbhura I'm still actively using your plugin for every wordpress project I'm running with composer in Trellis. Almost all of my projects require at least Gravityforms and/or WPML plugins, some of them require WPAllExport. All of them I'm installing with the help of your plugin!

The only premium plugin that offers reliable installation through composer is ACF. For Gravityforms, it has been on their roadmap since 2020.

There should ideally be a standard or protocol for this created by WordPress core itself, so everyone can follow the same rules.

👆 This exactly, it's 2024 and there is still no official way to install WP with composer, ridiculous really.

For other premium plugins, I am following the private repo route, but to be honest, this is such a lot of work to maintain.
If your plugin would be abandoned, I would have to repeat this process for a dozen of plugins...

I also don't think your plugin is that unreliable for production sites, only wpallimport doesn't allow me to install versions lower than the current version, but for the others it works fine tbh.

Anyway, I appreciate your hard work and devotion to this plugin and hope there will be a way to keep it going!

[mcaskill]

We are also still using this in our projects because we haven't found a better solution (mainly for ACF Pro, ACF Extended Pro, Gravity Forms, and Polylang Pro).

ACF Pro has recently started causing me trouble. It appears they closed their original URL for downloads in favour of a new URL but that one does not work with Composer (using cURL) for unknown reasons. Was going to test it again soon. Unsure what happened but its irritating.

See comment in #71 for details.

[mcaskill]

@junaidbhura After a new discussion with my colleagues about the practicality of this plugin versus its flaws (mainly caused by the third-parties themselves): we would like to take over maintenance.

Our short term plan is to ensure third-party URLs are up to date and continue to improve error handling and reporting in order to hopefully mitigate redundant issues when a third-party fails and provide participants with greater information to diagnose issues with the plugin.

I would recommend we keep the package name intact and to continue hosting it under your GitHub account if that's no trouble. You would just need to add me as a collaborator/maintainer. Alternatively, if you want to dissociate from this plugin, I can fork it and you can mark your package as abandoned in Packagist in favour of ours (once we've decided if its to be under my name, my agency's, or other).

[junaidbhura]

Hey @mcaskill thanks for your valuable contribution to this plugin over these years! :)

I would prefer that you fork this plugin and maintain it as needed in your organisation's GitHub and Packagist account. I can mark it as abandoned once you tell me which one to mark it abandoned in favour of.

My only request is that you add a credit to this Git repo in your new plugin!

[mcaskill]

Sharing this here to include all those interested/concerned by this package, any continuation, and alternative solutions, in the context of where things are in 2024.

1. ACF Pro:
   • Support for ACF Pro is currently broken.
   • As per the vendor (see comment in #71 for details) the recommended solution is the official Composer repository.
2. Gravity Forms:
   • Still no official Composer support (see/upvote feature request).
   • Official alternative to this package:
     • WP-CLI package: gravityforms/gravityformscli (2024-02; unpublished)
   • Unofficial alternatives to this package:
     • yeswedev-team/gravityforms-composer-installer (2023-03)
       • Forked from gtap-dev/gravityforms-composer-installer (2020-11)
         • Depends on ffraenz/private-composer-installer
     • piotrpress/composer-gravityforms (2023-12)
3. WPML:
   • Still no official Composer support.
   • Unofficial alternatives to this package:
     • lucguerraz/wpml-installer (2023-01)
       • Based on pernod-ricard-brandcos/wpml-installer (2021-05; unavailable) and enelogic/wpml-installer (2019-02).
4. Easy Digital Downloads (ACF Extended Pro, Ninja Forms, Polylang Pro, PublishPress Pro, WP AI/AE Pro):
   • Unofficial alternatives to this package:
     • kilbourne/composer-edd-plugin (2021-10; unpublished)
       • Forked from lubusin/composer-edd-plugin (2020-06)

For both Gravity Forms and EDD plugins, work could be restarted on ffraenz/private-composer-installer#45 as an alternative to a fork of this package.

[oxyc]

I just wanted to thank everyone for your work here! I wasn't aware of these options at all until recently.

Personally I decided to use the work done here but apply it to github actions that mirror the plugins source code by downloading, committing and creating releases. So I have a separate repo for each plugin but I can more easily monitor updates and I dont need to rely on their infra being online to deploy. If it fails at some point, I can always commit the updates manually. Also nice is that I can scrape the changelog and add it to release for dependabot summaries.

I published the workflows in https://github.com/generoi/github-action-update-plugins if anyone is interested. It's still experimental and I'm waiting for a few version updates to get published before I use it in production myself.