Support plugins served by EDD about private-composer-installer HOT 7 OPEN

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

from private-composer-installer.

@ffraenz What do you think about supporting plugins distributed with EDD?

from private-composer-installer.

These are the steps.

1. Get plugin data from {%EDD_SELLER_WEBSITE_URL}?edd_action=get_version&item_id={%EDD_ITEM_ID}&license={%EDD_LICENSE_KEY}&url={%EDD_REGISTERED_WEBSITE_URL} as JSON
2. Take 'package' element from the JSON
3. Download plugin ZIP from that URL

Seems possible to me.

from private-composer-installer.

@ffraenz It would be nice to make private-composer-installer extendable and develop these features in a separate plugin.

from private-composer-installer.

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.

from private-composer-installer.

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 ...

from private-composer-installer.

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:

• URL
• method
• content
• payload's key

But to be truly generic you may miss:

• authentication (for Basic auth)
• content type (json, form-urlencoded, ...)
• headers (for arbitrary headers)
• user-agent (in case this is needed)
• and possibly whether redirects are followed or not.
• and the fact that the payload may be in XML, YAML, ... or have decode a given key (gzip, base64, ...) or the object key be nested.

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?

from private-composer-installer.