New Plugins Directory

[neokoenig]

Currently in the works is a redux of the old cfwheels plugins site.

Overview

The directory lists cfwheels plugins (and possibly more in the future, such as boilerplate apps, modules) and provides a way of getting that data via JSON for use with CommandBox, or by browsing the site. Plugins are filterable by Category and Owner.

Each listing includes information automatically pulled from gitHub; Descriptions, readme, and releases/downloadable assets.

Assuming this all goes well, this could open the door for a cfwheels command line interface for CommandBox, allowing plugin installation, package installation, more automated testing, scaffolding etc.

A New Standard for plugins.

In order for plugins to be added to the directory, they must satisfy some basic requirements.

1. Your plugin needs to live in a public gitHub (http://github.com) repository.
2. You need to use gitHub Releases (https://help.github.com/articles/creating-releases/).
3. Each release requires an attached .zip file of the ready-to-go plugin, named correctly.
4. The zip file name should match yourPlugin-VERSION.zip, and in the zip root, there should be a matching .cfc named after the plugin Name
5. After submission, add an optional 'webhook' to your gitHub repository to ensure new releases and updates are recorded.

See an example of a 'properly' setup repository: https://github.com/neokoenig/cfwheels-plugin-example

This really is the minimum ‘standard’ which I propose new plugins should adopt. Without a release (with an attached binary) it’s basically impossible to know what the definitive version of the plugin should be, as different repos have different standards (i.e, not using releases, or having src folders etc;)

Pros:

• Quick to add a new plugin
• Data is pulled in automatically except categories which are assigned on entry
• Downloads are provided by github; we’re just providing the link. We can also get download figures from the API.
• Updated readmes, descriptions and new releases can be auto pulled in.

  Cons:

• Some / a lot / of plugins may well require creating a release on their repos. We could however, fork them over if needed and do the release ourselves if the plugin is of suitable importance
• Some data, such as compatible wheels versions, we can’t get from GitHub; we’d need to parse the actual plugin cfc to get the init() function, which isn’t really practical for all the usual reasons.

  Progress:

• [x] Setup example new plugin repository style
• [x] Setup initial local test site / proof of concept
• [x] Deploy Alpha version for internal core team comments
• [ ] Unit Tests
• [ ] Deploy Beta version for public comments
• [ ] Release

[neokoenig]

NB, on hold for now.

[neokoenig]

Dropping, as we're going full on forgebox + commandbox for plugins