Composer Repo/Link for Pro Plugins
This doesnt neccesarily have to be a repo, it could just be a link to a versioned zip file.
Im sure its a major strurcture change, but, for instance, I can include ACF in my composer.json via the a link to a versioned zip file with my account key:
This is like, the lowest feature on the totem pole, but if you ever end up refactoring how pro files are distributed, it would be great if you would consider it.
Thanks for the suggestion and the comments. We’ll keep this open and see what kind of interest there is from other developers.
I would love to see the plugin have a version where we could combine the CSS and JS into one file each during the build process.
This would make me use tribe plugins more. It's out of our workflow to go to the website, login, go to the downloads page, download a zip, trash the old one, unzip, then muck up the repo with it. This doesn't seem terribly difficult to do, but it's one of those little things that screams quality and most likely will lead to increased adoption. Hey, think about it as a joint cost saving and marketing initiative. Composer caches things, and that's less wasted site bandwidth. Perhaps anyways. Then you can use your newfound street cred to market as a plugin made by developers for developers. No? Come on. I'm lazy. :)
Florian Schroiff commented
The process Delicious Brains use is great: https://deliciousbrains.com/wp-migrate-db-pro/doc/installing-via-composer/
The URL you use to get the plugin is https://deliciousbrains.com/dl/wp-migrate-db-pro-latest.zip?licence_key=[license key]&site_url=[site url]
This is a more developer-centric feature request, and it's not something your average user would be interested in.
I like managing my WordPress projects with Composer, as well, and the Pro version of The Events Calendar sorta throws a wrench in that plan.
Another example of a plugin which allows for Composer management of the pro version:
We handle dependency management with Composer: https://getcomposer.org/. We use it to bring in a specific version of Wordpress, and specific versions of all plugins, via a composer.json file that is committed to the project repo.
This helps keep versions consistent for every developer working on a project, and prevents someone updating, say, the Events Calendar plugin to version 3.9.2 when everyone else is working on 3.9.1. Version inconsistencies could cause a plugin crash or deactivation if you are using a shared development database.
Not only does this help keep versions in check, but it keeps repo sizes smaller, as all dependancies are added after you clone the repo and run `composer install`.
Most plugins in the WP plugin repo are mirrored as Composer packages on wpackagist: http://wpackagist.org/, including the Events Calendar plugin, however the Pro plugin is not available.
We use the pro version of ACF, which is not available on the WP plugin repo, however, they offer links to versions of the pro plugin that accept a user account key. So users who have paid for the plugin can download version 5.2 from their account with a link similar to:
This can easily be treated as a package in a composer.json file, and the version can easily be updated due to the link structure.
Our current workflow requires us to download the pro plugin, zip it, put it in an Amazon bucket, make the file public, and then point to the new link in composer.json. This kind of falls apart once it comes time for the client to purchase the pro version, as we can't easily integrate their account with the package.
It would be great if there was a way to point to Tribe based pro package that follows a versioning structure for downloading.
This is a bit long winded, if you need any clarity, let me know.