Download and install plugins from (central) repository from within Piwik admin UI

[vipsoft]

Proposal:

The client is a Piwik plugin. The server, hosted at ActiveAnalytics.net during development, will be moved to plugins.piwik.org.

Offer delta releases which package only the changed files; the update script would remove any files deleted from the distro.

Related tickets:

• #607 - simpler way to install plugins
• #728 - manual update check
• #936 - periodic UpdateCheck for 3rd party-plugins
• #1043 - developer infrastructure

Out-of-scope for the first iteration of this plugin and ticket:

• rate the plugin; report problems; make donations
• price, checkout, and digital delivery for non-free plugins
• plugin submission policy
• use of continuous integration server and plugin unit tests to spot problems before a core Piwik update
• plugin licensing issues (see  http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins)

[vipsoft]

screenshot

[matt]

Anthon, I would like to see such an effort hosted by Piwik itself, for example on a subdomain at plugins.piwik.org ? I would gladly let you lead this project. I believe there is an enormous value in having such a feature in Piwik; this is what made Wordpress what it is now. This also very much in line with our objective to increase the number of third party plugins. Let me know your thoughts :)

[jimbo]

As someone new to piwik, it took me a while to find the plugins at trac. That's why I would like to have such a central plugin to find and install plugins.

BUT: I would prefere it to be hosted by piwik, not by a third party. A plugin like this has quite some power over my system, being a kind of gatekeeper. And although I have no reason to mistrust VIPsoft or ActiveAnalytics.net (never heard of them before, so no offense, guys), I would rather trust piwik.org.

[vipsoft]

jimbo: you missed the part about "during development".

[kaystrobach]

I took a look on the powerup website, functionality looks nice, but there should be an restriction which allows only users with trac logins for piwik.org to upload plugins.

Then there should be an option to reserve Pluginnames, during the first phase of development - as there won't be and upload at first ... .

Additionally the user should be forced to upload the code to a piwik.org server, and not specify a download url. Reasons:

• External Servers may share infected downloads
• External Servers may be down
• External Download Sources can't be checked with unit tests
• With one Server and perhaps some mirrors the download experience is always the same, that is the goal of apple's appstore and the one of wordpress as well.
• Payment can be handled centrally, so that there is a rule, the commercial plugins need to spend a small amount to the piwik team to ensure further development
• ...

Great work so far - go on ;)

[kaystrobach]

oh and i forgott to say, that developers should sign a copyleft agreement to have the rights of the opensource plugins ...

Sth. like  http://www.tine20.org/licenses/metaways_icla_1.1.pdf

Best regards Kay

[matt]

Kay, all good points. We're discussing internally how the plugin repository should work and this is a work in progress :) but certainly a great idea!

[vipsoft]

At the moment, I want to focus on getting the plugin and backend server working to my satisfaction.

Policies and hosting infrastructure are relevant discussion, but not in this ticket.

[kaystrobach]

@vipsoft: absolutly a great idea and that's why i spend the time to give feedback ;) of course software is work in progress, i just wannted to provide some feedback to make id eveb better ;)

Best regards Kay

[matt]

I talked with Piwigo project lead, who built the system to host Piwigo's plugins. A few points:

• they are using the open source PEM project to handle plugins hosting;
  • adding plugins, version history, screenshots, description, download, etc.
  • REST API to fetch all the data (eg. from a piwik client plugin) like: list of versions, compatibility with piwik core versions, fetch download stats, etc.
  • Several ways to upload a plugin: submit the zip, submit zip via external URL, or submit zip by giving the SVN path
  • it also provides a UI used to list plugins on the project website.
    • Piwigo example:  List of all plugins and  an example plugin page
    • Another example:  Listing of plugins
• they have seen a huge increase of activity on the project once they enabled this tool with ability for any plugin to be visible on all Piwigo installs (gives credibility to the plugin author)
• they don't moderate a priori the plugins, only a posteriori. I don't think though that we can afford to do this before 1.0 as our API is not stable yet.
• they host the plugins on the same repo as the main core repo (increases the general SVN activity, plus only one repo to maintain).
• currently there is a manual process where new plugins paths are created when the plugin author is interested to get a SVN. However, the system sends an email with the command line to execute to init the SVN so that it is nearly automated. Maintainer can then send the email with password and path to the plugin author.

PEM project is open source and available at:  https://gna.org/projects/pem/ Piwigo project lead is also dev of this software and they are planning to improve the UI aspect of the "plugin listing page" to make it a bit easier to navigate. But other aspects are working and in production for a few years now.

I think this solution could help us a lot and save us of similar features. The project is active and in production, and I didn't find other similar projects while searching for it.

What do you guys think?

[vipsoft]

The Typo3 extension manager is also a potential candidate:

•  http://forge.typo3.org/projects/show/typo3v4-em

[vipsoft]

GA Application Gallery:  http://www.google.com/analytics/apps/

[vipsoft]

Designate "Piwik Labs" for plugins in alpha/beta/preview state that users can test drive and provide feedback.

[matt]

Maybe we can just flag Alpha/Beta plugins clearly as being non stable, the other state being 'stable' ? They could both be listed in the same UI, etc.

[vipsoft]

Add ability to install third-party libraries (./libs), e.g., HTMLPurifier. This keeps the core distribution smaller, and allow for independent updates (i.e., not tied to Piwik's release schedule).

Whether or not we track the dependencies is debateable. For example, the HTMLPurifier stubs will use a mock object if the library isn't installed.

Another example would be Zend Framework. It has a large footprint, so we include only a subset of the components. If the Example plugins were moved to the repository, then Zend_Feed, Zend_Uri, Zend_Validate, ... could be separate.

[halfdan]

As an addition to Alpha/Beta/Stable we should add a "Reviewed" state for plugins that were reviewed by at least one Piwik developer. This would add additional credibility to some plugins. Could also be offered as a service by trusted Piwik consultants.

[matt]

problem is that the 'reviewed' state should be reset at each plugin release (since we would have to re-review each release)

[kaystrobach]

in TYPO3 there reviewed extensions - but correct there is a review needed for every release.

Additionally there is a discussion about common / suggested plugins. - What about such a state? (Doesn't need to be reviewed every release, but regularly ... )

Regards Kay