Additional tasks to streamline your workflow

The sfTaskExtraPlugin is a plugin maintained by the symfony core team. It adds a number of useful tasks to your symfony command line to help streamline your workflow. This plugin is relatively young, so I will just be discussing those tasks that we'll be using for today's Plugin Developers Day. I should also note this plugin requires symfony 1.2.

Plugin Tasks

We now turn our focus to easing the process of creating, developing and releasing plugins. The following tasks are included in sfTaskExtraPlugin:

  • generate:plugin
  • generate:plugin-module
  • plugin:package

New Task: generate:plugin

Very much like generate:app task, the generate:plugin task creates a basic plugin directory structure:

$ ./symfony generate:plugin myFirstPlugin

After running this command you should see the following plugin structure in your project's plugins directory:


As you can see, part of what this task does is setup a proper testing environment for your plugin, including an isolated symfony project to run your plugin's functional tests through. Once you've created your test scripts, you can easily execute them all by running the prove.php script before committing your code:

$ php plugins/myFirstPlugin/test/bin/prove.php

Building a robust unit and functional testing suite is a strongly recommended best practice, but if you would rather not bother you can simply include the --skip-test-dir option when generating your plugin.

New Task: generate:plugin-module

Often times a plugin will require one or more modules to support its functionality in the project, such as an administrative backend interface. In order for your module to be easily customizable for its housing project you will need to provide a "stub" actions class that can be replicated and customized in an application's modules directory.

Previously this would have involved either creating the module directory structure by hand, or running generate:module in your application and then copying, modifying and creating new files in your plugin. This process is now much more streamlined thanks to the generate:plugin-module task.

$ ./symfony generate:plugin-module myFirstPlugin myFirstModule

Executing this command will add the following to your plugin's directory structure:



As you develop this module, write all your action code in the /lib/BasemyFirstModuleActions.class.php file. Leaving the actions.class.php file empty makes it possible to replicate that file in the project and not lose or have to duplicate code from the plugin; this will be taken care of by the symfony autoloader and the magic of OOP inheritance.

This task also creates a functional test script for the new module and updates the embedded test project's config/settings.yml to enable the module.

New Task: plugin:package

Anyone who has released a symfony plugin in the past is familiar with the tedious task of filling out the necessary values in the requisite package.xml file. We have added the plugin:package task in order to speed up this process.

$ ./symfony plugin:package myFirstPlugin

This task will look for either a package.xml or package.xml.tmpl file in the plugin directory. If neither are found, the task will package the plugin using a default package.xml template. In any case, if any field values are not known the task will take advantage of one of the new symfony 1.2 task features and ask you for that information.

Interactive task

Once the task knows what it needs to package the plugin, a myFirstPlugin-0.0.1.tgz file will be created in the plugin directory. Once you upload this file to the symfony plugins application, your work will become immediately available to the entire symfony community.

What's Next?

The sfTaskExtraPlugin is young, but we have big plans for it. If you have any tasks you'd like to see incorporated, please let us know.

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.



Nice plugin to create my own plugin. Thanks

But i have a problem with test because the variable $_SERVER['SYMFONY'] don't exist on my computer. Do you have another solution to load the core ?


Wow!!...You guys do not give a chance to breathe...I am actually dreaming of symfony. Nice work!
Would be nice to have a task which creates the model class hierarchy (myModelClass -> PluginmyModelClass -> BaseMyModelClass)

Thanks for this plugin it's a great work and has encouraged me to create a new plugin.
@cinxgler Yes, that's on the roadmap. This plugin is very young right now, but I'm glad you're finding it useful!
Wonderful plugin. I'm already putting it to good use. I especially like the use of the test project in the fixtures.

I'm also getting errors with $_SERVER['SYMFONY']. What would normally be setting that?
@Piers Variables in the $_SERVER array can be set from your UNIX shell. In bash, I run "export SYMFONY=/path/to/symfony/lib". This technique doesn't support Windows, although I would like for it to in the future... any ideas?
If useful, I'm using this to avoid setting the _SERVER['SYMFONY'] variable.
Hello, it's must be helpfull.

BTW, I have two small tasks which might be contributed into this plugin.

One is simple wrapper for installWebContent/uninstallWebContent which simply add/remove(copy/remove for windows) symlinks for all plugins which have web folder. (handy with svn)

Second simply symlink webdir from symfony_data_dir to project webdir.


I am new to symfony, so, might lost something, let me know :)
Nice post !

Thanks for the hard work and the valuable information for sharing with us.

Comments are closed.

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