The symfony plugin system is the easiest way to contribute to the symfony project. Plugins are easy to write, easy to package, ease to install, and they can override everything in the framework.
But how do you answer questions like these: Is there a plugin to add the "foobar" feature to my project? Does my favorite plugin work with symfony 1.1? What are the plugins compatible with Doctrine? Who is the leader of this plugin? How can I contribute to a plugin?
I can go on and on. It is not easy to answer any of these questions with the current plugin management system, aka Trac. Trac has served us quite well for over the last two years, but with more than 200 available plugins, it was clear that we needed a better, dedicated system.
So, I am pretty happy to announce that I have just deployed a new version of the symfony project website with a brand new "Plugins" section (look at the top menu entries) to replace the Trac plugin management system.
Features
Here is an overview of the main features of the new system:
The plugin homepage lists all the available plugins. You can filter them by the symfony version, by the ORM tool you use, or by author or plugin name.
Each plugin has a dedicated page with some general information, the license text, the installation process, the README file, the dependencies, the list of all releases sorted by symfony version, a contribute panel, and an admin panel for the plugin developers. The page is even customized for each plugin version.
All information are linked together which means that you can easily find all the developers of a plugin, or all plugin from a developer, ...
The plugin lead developers have access to an admin panel to manage their plugins (description, categories, ...), to upload new releases, and to manage the plugin team.
Each plugin can have several people working on it with three different roles:
developers: They have access to the plugin repository (if the plugin is hosted on the symfony repository)
packagers: They can upload new releases and delete old ones
leaders: They can do everything with the plugin
From now on, you have to ask the authorization and be accepted by the lead developers to work on an existing plugin. The process is very easy because everything is done online in the contribute and the admin panel. So, everything is automated, from the creation of your account to the SVN authorization.
The plugins are now categorized by the lead developer directly in the interface. And, when a significant amount of plugins will be categorized, I will enable the category filtering on the homepage.
As all the trac accounts have been migrated to the symfony website, you can login today with your existing Trac account. So, the same account is now used for Trac, plugins, and Subversion.
Plugin developer notes
With the migration, some changes have occurred. Here are the main points you need to be aware of as a plugin developer:
The information displayed on the website comes from the
package.xmlfile. So, all plugin leaders are encouraged to check their plugin page and fix their package file if needed.The license panel displays the
LICENSEfile of the PEAR package if it exists. If not, please add aLICENSEfile at the root of your PEAR package with the license text.The readme panel displays the
READMEfile. The official format of this file has changed from the Trac wiki markup to Markdown as it is the format used everywhere for the symfony documentation. There is an on-the-fly conversion from the Trac wiki markup to Markdown but as the conversion is far from perfect, you are encouraged to convert your README files to the Markdown syntax.The import script automatically associated the plugin leaders with their plugins, but it only worked if you have associated an email with your trac account and if this email is the same as the one used in the
package.xmlfile. About 85 plugins don't have any leader for now. If you are a leader for one of these plugins, please send me an email with the plugin you claim and your username (fabien.potencier [(at)] symfony-project.com).Some plugins have not been imported because of some errors. If your plugin is not listed in the new system, please have a look at the plugin error page to know the reason. If you don't know how to fix the problem, send me an email and I will try to help you out.
The plugin Trac pages are redirected to the new application, so the transition for the end users is quite easy.
The forge
The new system does not replace the current Trac ticketing system, and it does not provide a dedicated Subversion repository for plugins. That's because the system is not a replacement for the symfony forge project. We are still working on the symfony forge to provide tools for your plugins: dedicated Subversion repository, ticketing system, wiki pages, and more... Stay tuned!
I hope that the new system will ease the plugin management and will give more visibility to all the great symfony plugins we have.
Look great. Love the look and the search bar with check boxes is a nice touch.
That's a great tool. Thanks for your work!
This is a great improvement in the plugin section. Seems really useful, thanks for all the effort!
I always thought that if a change happens, it's for better. But this isn't, the listing of the plugins was a lot better in the previous version. :(
Really useful. Merci beaucoup ;-)
That's great - I've explained to people a couple of time on IRC that there's currently no real organization to the plugins, and now there is. People will be very happy :D
Looks really good. Thanks!
Great work. Thanks Fabien.
Great work - much better information, particularly on compatibility.
Now that it's paged, could the search box also search the description field, or a category filter? i.e. a search for 'validation' should return me sfPokaYoke, or 'javascript' should return all related plugins.
Great work. But i miss some plugins like sfExtjsThemePlugin or sfExtjs2Plugin. They are also not listed at the error page.
@Carsten: This is because those plugins do not have any PEAR package yet.
huge step for the symfony project. absolutely huge.
Looks great. Thank you!
This is absolutely great. Thanks!
Great work Fabien ! Also, I was wondering how the search criterions work. i.e : chacking only the sf1.1 returns ckWebServicePlugin which is sf1.0. Another thing is, checking sf1.1 and doctrine gives the same number of results as checking only sf1.1. Are the checks ORed ?
Just great ! It will be now a piece of cake to manage and maintain our plugins. :)
Indeed, perhaps it could be cool, to have "lists" as before in the wiki, to quickly see all plugins available for a category. (without pagination)
Great step in the positive direction! Looks very organized.
Adding a popular downloads section would add to value IMO.
It would provide a quick snapshot on what plugin is being used more throughout the symfony community.
Thanks again!
I don't get it. Surely we need a system for tagging plugins?? A very simple, tag based, drill down search??
I was searching for a doctrine CMS plugin, as I remembered seeing one. Turns out the only place I could find it is in the trac repo. I could only find the repo using google. Here's the link ,for anyone intrerested : http://trac.symfony-project.org/browser/plugins/sfDoctrineSimpleCMSPlugin
Hi, since a couple of days, every time I tried to navigate the site an error 500 is displayed. It only happens when I use Safari 3.1 on a Mac.
This is just awesome ! Thanks for this nice new tool :)
This is a very good news, but why god use pear package ? I just lost more than 1 hour on packaging a little addon. And I can't figure why my readme isn't take in account...
Imho Pear is the worst thing that happened to php. Screw their how to make package documentation.
tcourbon++
Great, this is what I was hoping for! So thanks a lot for all this.
Just one enhancement (I hope it's a little one) would make it perfect: a printer-friendly format that concatenates all information from all tabs ("Plugin info", "License", "Installation", "Readme" etc etc.) onto one single printable page. This would avoid printing out each tab individually, as needed now. Maybe it's basically a matter of adapting the CSS for printing mode? Cheers RAPHAEL
it seems another plugin is missing : sfDoctrineGuardPlugin .
It seems that sfAjaxUploaderPlugin is missing too. Besides the 'Plugin' link it doesn't appear in the forum header
Hi Fabien,
This morning, I was looking for the documentation plugin in your great new plugin homepage. Difficult to find it because the "project management" category whose sfPHPDocumentorPlugin belongs to disappeared. Have you planned to set this category again ?
regards,
im in the process of evaluating various web framework. i cant tell you how frustating your move is.
i do understand you tried to improve the interface to the plugins and plugins is a big advantage of symfony. But you did so without properly testing the new version. which is quite buggy.
i do understand that bugs are part of software developement. but additionnaly you disabled the old list which contains a lot of documentations and which was working.
But please understand, that symfony users are now without documentations due to your choise to disable the old working version.
To me, your attitude on this has been totally unprofessional!! please reenable the working version with the docs while the one is beeing debugged
@jerome etienne: What does not work? If you found some bugs, please open tickets for them to be fixed.
@jerome etienne:
see http://www.symfony-project.org/blog/2008/08/07/some-news-on-the-new-plugin-system
@fabien
thanks for your reactivity
@jerome etienne: your netiquette clearly needs some work.
You may not like a particular move, but you appear to be forgetting that you are getting the benefits of this software and associated services for free. Accordingly, rather than offering thanks with constructive criticism, you have just been rude instead. Let me suggest you should try to be nicer in your posts, if you intend to be part of the symfony community.