Open szepeviktor opened 4 years ago
@ffraenz What do you think about supporting plugins distributed with EDD?
These are the steps.
{%EDD_SELLER_WEBSITE_URL}?edd_action=get_version&item_id={%EDD_ITEM_ID}&license={%EDD_LICENSE_KEY}&url={%EDD_REGISTERED_WEBSITE_URL}
as JSONSeems possible to me.
I was thinking about this a couple of weeks ago. Specifically, I was wondering how one would also support non-EDD APIs. The following is what I came up with, it's clunky but a practical solution:
GRAVITY_FORMS_KEY='MyLicenseKey'
POLYLANG_PRO_KEY='MyEddLicenseKey'
POLYLANG_PRO_URL='MyEddRegisteredUrl'
POLYLANG_PRO_USERNAME='MyPolylangUsername'
POLYLANG_PRO_PASSWORD='MyPolylangPassword'
[
{
"type": "package",
"package": {
"name": "wpsyntex/polylang-pro",
"version": "2.8.2",
"type": "wordpress-plugin",
"dist": {
"type": "zip",
"url": "https://www.polylang.pro/?edd_action=get_version&item_name=Polylang+Pro&license={%POLYLANG_PRO_KEY}&url={%POLYLANG_PRO_URL}&version={%VERSION}"
},
"extra": {
"private-composer-installer": {
"http": {
"method": "POST",
"username": "{%POLYLANG_PRO_USERNAME}",
"password": "{%POLYLANG_PRO_PASSWORD}",
"response-type": "json",
"download-url-key": "download_link"
}
}
},
"require": {
"composer/installers": "^1.4",
"ffraenz/private-composer-installer": "^5.0"
}
}
},
{
"type": "package",
"package": {
"name": "gravityforms/gravityforms",
"version": "2.4.20",
"type": "wordpress-plugin",
"dist": {
"type": "zip",
"url": "https://www.gravityhelp.com/wp-content/plugins/gravitymanager/api.php?op=get_plugin&slug=gravityforms&key={%GRAVITY_FORMS_KEY}&version={%VERSION}"
},
"extra": {
"private-composer-installer": {
"http": {
"method": "POST",
"response-type": "json",
"download-url-key": "download_url_latest"
}
}
},
"require": {
"composer/installers": "^1.4",
"ffraenz/private-composer-installer": "^5.0"
}
}
}
]
Inspired by Composer's custom header authentication
@ffraenz It would be nice to make private-composer-installer extendable and develop these features in a separate plugin.
I think both approaches are very interesting.
The configuration array I introduced in #25 may be exploited to offer a location for custom environment loaders that can be described in a modular way similar to what you suggested above. Tough, we'd need to design it in a way that makes this feature easily accessible. An alternative would be build in support for certain vendors.
build in support for certain vendors.
Instead we can provide a mechanism to get the download URL by code e.g. from an API: gravityforms, polylang, envato Some kind of hook maybe ...
I don't think it's should be make extensible because many users won't accept pulling many levels of dependencies with all the gotchas there is wrt of composer install/update
sequence (see, eg, merge-plugin).
But it should be rather support most known-cases and optionally be generic enough (URL + payload + placeholder?) to manage custom cases.
About the generic handler proposed by @mcaskill it's probably the way to go:
But to be truly generic you may miss:
That's why implementing known providers (one provider being < 10 LoC in a PHP method) is probably quicker, simpler, easier to configure and would serve the vast majority of users turning into this composer plugin.
Eg: Instead of type: package
, is it possible to register another repository type
(like gravityforms
, edd
, ffraenz/private:gravityforms
, name it) so that the overall user's configuration is made even simpler?
@ffraenz What do you think about supporting EDD?
Basically you POST once and receive the temporary download URL.
This is the documentation of plugin licensing https://docs.easydigitaldownloads.com/article/384-software-licensing-api the Getting version information section