sfGuard and the new plugin system
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 (
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!
Comments are closed.
To ensure that comments stay relevant, they are closed for old posts.