Be part of the Symfony Plugins System

May 8, 2009 · Published by Avatar of Fabien Potencier Fabien Potencier

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

Help the Symfony project!

As with any Open-Source project, contributing code or documentation is the most common way to help, but we also have a wide range of sponsoring opportunities.

Comments

Avatar of Lukas
Lukas said on May 8, 2009
Grat news fabien!!! Thanks for your hard work!! Lukas from Argentina.
Avatar of Jonathan H. Wage
Jonathan H. Wage said on May 8, 2009
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 :)
Avatar of Jonathan H. Wage
Jonathan H. Wage said on May 9, 2009
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);
Avatar of Rubino
Rubino said on May 9, 2009
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... :)
Avatar of Rubino
Rubino said on May 9, 2009
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] :)
Avatar of Rubino
Rubino said on May 9, 2009
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.
Avatar of Rubino
Rubino said on May 9, 2009
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)
Avatar of Frank Stelzer
Frank Stelzer said on Jun 5, 2009
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?

Comments are closed.

To ensure that comments stay relevant, they are closed for old posts.