Francois Zaninotto
When we introduced the plugin system in 0.6.0, we hoped that many contributors would post plugins about everything in the framework. Unfortunately, the limitations of the system (due to the lack of hooks in the code and to a few bugs) made it poorly usable. We then decided a major refactoring of the system, and it is now ready to be used. As it breaks backward compatibility for existing plugins, the new system is published in a symfony 0.9 version, tagged alpha.
In this version as in the next stable release, plugins are subdirectories of a plugins/ folder in the project. There is no more 'global' plugin. Plugins can now contain classes, helpers, configuration, tasks, modules, web assets, schemas and model extensions of their own. The features offered by a plugin are available in the project as if part of the framework. It is an ideal way to share code between applications and projects. Plugins are also the ideal tool to package and distribute everything, from a single helper to a full-featured module with its own data model and images.
In addition, if previously plugins required a PEAR channel to be distributed, they can now be installed by simply expanding an archive in the plugins/ directory of a project, or by creating and external dependence to a source code repository - for instance via svn:externals. The symfony wiki itself becomes a plugin broadcasting system - attach a plugin file to pages properly named to make the plugin available for the symfony command line.
The bad news is, all previous plugins are no more compatible with the new system. If you want to upgrade to symfony 0.9 for your project, you will have to uninstall your old plugins first, do the upgrade, and then reinstall the new plugins. The major symfony plugins have been updated to work with the new system (sfFeed, sfThumbnail, sfShoppingCart), and we invite all plugins contributors to rework their packages to make them compatible.
The plugin documentation has be rewritten, and a list of all plugins is available in the wiki. In particular, the sfGuard plugin, recently published, is a complete user authentication system with credentials and user management, containing its own model, generated admin and configuration. Not only is it a good way to understand how to make a plugin yourself, it is also a useful component needed by almost every application.
From now on, whenever you want to contribute a piece of code that is not meant to be integrated into the symfony core and that is too big for a snippet, you can package and publish it as a plugin very easily. Contributions are welcome; don't hesitate to enhance the symfony framework with bits of your own brightness!
Note: You need the latest Alpha version to take advantage of the plugin system. To upgrade, type
or upgrade via SVN
Blah, guess all my work on my RBAC system was in vain... whish I new this was coming down the pipe, oh well.
I'll install it and give it a whirl
Thank you Francois. I have been waiting for symfony to move in this direction for some time now. This is the perfect way to both extend and maximize code reuse.
well done.
Draven -> i'm really interested in your RBAC plugin. sfGuard does not have the "role" concept, which i need on many projects.
After reviewing the source code of the sfGuard Plugin I noticed, that I don't really like it.
You can define permission types, users, groups, grant the user and groups permissions. Thats good, for very small systems.
I need roles, apps, modules, actions (= permissions), a minimal needed user role for actions, sub-groups, actions implying other actions (edit action implies list action), granting and explicit revoking permissions to groups and users, module admins and module access ...
I wrote this all by myself, and now I'm a bit confused: is it better to transform all the code to a plugin, and source it out (so that I may publish it), or shall I let it be normal libs and part of my default model and part of my modules and so on?
Also, I'm not using credentials, only to check if the given user role is granted to access the backend.
Pierre,
If you use your system for more than one project and if it involves more than just a collection of classes, it is definitely interesting to create a plugin.
Pierre - That's my dilema as weel.
I have a fairly large lib set from my other projects which manages advanced ACL control, but I'd love to have a symfony plugin for such features.
This is awesome, can't wait for 1.0!
I have some problem with install with command line symfony plugin-install http://plugins.symfony-project.com/sfGuardPlugin
@Anton: you must specify where you want to install the plugin. Either local or global.
symfony plugin-install [local/global] http://plugins.symfony-project.com/sfGuardPlugin