Through the years, the symfony plugin system has evolved as one of the strongest feature of the framework. From the very basic system based on the symfony wiki found in symfony 1.0, to the fully web oriented management system introduced for symfony 1.1, it has never been easier to contribute and use symfony plugins. But from time to time, people ask for more. One of the most frequently asked feature was the introduction of a way to find good plugins. That's why we have recently introduced the popularity mechanism to ease beginners choose the "best" plugins out there. Then, someone asked for a task that automatically reports the plugins used by a project, and some others want a comment system for each plugin. With the growing enthusiasm around plugins, I wanted to provide more freedom and free people's creativity.

Today, I'm very happy to announce the immediate availability of the symfony plugins API. The symfony plugins API is a REST-style API for the symfony plugins available on the official symfony website. It provides a lot of methods to retrieve information about all symfony plugins. The official documentation describes the API in great details, and lists all the current available methods.

Be warned that the API is still in an alpha stage, and things can change based on your feedback.

So, what the API is good for? Jonathan is already using it in the Sympal CMS to provide Sympal plugins management. That means someone can also create a generic symfony plugin that facilitates the discovery and the management of plugins from within a symfony project. Or you can use it to create a catalog of symfony plugins as a desktop application. Of course, it can also be used to create the symfony task I talked above that reports the plugins used by the current project to the symfony website.

Be as creative as you want with the API, and tell us what you do with it.

Published in #Plugins

Lukas said on May 8, 2009 at 17:05

Grat news fabien!!! Thanks for your hard work!! Lukas from Argentina.

Jonathan H. Wage said on May 8, 2009 at 17:05

Thanks for this Fabien. It is awesome. I mentioned the need to him for Sympal and about 24 hours later he had something for me to use :)

Jonathan H. Wage said on May 9, 2009 at 00:25

Here is a simple class that will let you talk to the API and get back simple arrays of data.

http://svn.symfony-project.com/plugins/sfSympalPlugin/trunk/lib/plugins/sfSympalPluginManagerPlugin/lib/sfPluginApi.class.php

[php]
$api = new sfPluginApi('username', 'password', '/tmp');
$plugins = $api->get('plugins.xml');
print_r($plugins);

Rubino said on May 9, 2009 at 12:17

Very nice :)

I've a couple of features for consideration to the Plugin API...

Authentication: Extend the API approach to allow for the generation and use of application API keys under the User account. This allows deployed applications to continue functioning should the dev change their password. It will also facilitate better reporting of plugin usage (I use SfDoctrineGuard & sfApply in all my applications yet the current reporting is used/not used). It would also be handy to consider application instances - if I have a popular application that's used by a few clients that uses a handful of plugins - then if the users decide to update thier plugins around the same time the usage limit could be quickly exceeded. This could be simply addressed by using sessions - the plugin update process for an application could establish a session and the session would have it's own usage limit.

Machine Feedback: Sometimes a plugin has some teething issues - it would be handy to have a method that accepts an error report. This would allow passing the plugin author some detailed information about the issue via a plugin manager without having to visit the plugin page, determine who to send the error details to, open an email, etc.

It would also facilitate a CI approach to plugin releases - allowing for a validation cycle before the plugin author changes from beta to live, new releases - or when new iterations of symfony core are released.

Just some initial thoughts... :)

Rubino said on May 9, 2009 at 12:19

Ah - and any chance we can get the comment box here updated to something that's bigger and richer (WYSIWYG)? [and maybe a spell checker for when I've not had my morning coffee] :)

Rubino said on May 9, 2009 at 20:56

Would it be possible to include the download package for each release in the returned results for a package?

While the download package tends to follow a distinct pattern - it would make it reliable should the pattern for the download link change in the future.

Rubino said on May 9, 2009 at 21:00

This would also allow a method of publishing packages with the same version number but for different versions of symfony and possibly allow using svn (that's configured to use http) to provide packages in a more granular fashion (ie svnRoot\Tags\sf1.0\package-1.0.0.tgz & svnRoot\Tags\sf1.2\package-1.0.0.tgz)

Frank Stelzer said on Jun 5, 2009 at 01:32

This looks really nice and i like the architecture of the API. I wonder how you solved the routing. When every possible ressource pattern is mapped by a route then this api module(?) would have >= 10 routes?

Be part of the Symfony Plugins System

Comments

Become a Symfony contributor