Symfony: Overloading and Overriding Plugins & Base classes

There’s a couple of places that tend to cause confusion when people try to override Symfony & plugin functionality and the autoloader doesn’t help when you’re trying to test things out.

You can generally create your own version of any class – if you put the new version in the right place and if the file and class are named properly.
The location you put the file depends on a number of factors (is it a core module or a plugin) and the scope you want to affect.

With plugins generally the best approach to start is to be as local to your Symfony app as possible.

1. Clear your cache – it doesn’t hurt to do this before and after you start making changes and it’s a good habit to do this often
2. Start by making a folder for the in apps\<applicationName>\modules\<pluginName> (often you just make the folder rather than using the generator)
   • Depending on what you’re overloading you create the sub folder here for it – so if you’re modifying a template then create a templates folder under the plugin folder you just created
3. Now copy the existing file from the plugin to the folder you just created- it’ll be a good starting place to making any changes.  When copying a file it’s the file that will be used initially by the autoloader  rather than a file named Base….
   • So if you’re looking to override the actions for sfGuard, it’s going to be under the sfGuard\modules\sfGuardUser\actions\actions.class.php
   • Well written plugins will use a base file – for sfGuard this is BasesfGuardUserActions.class.php – which allows easy overriding of your own functionality – you’ll see a reference to this in the top of the actions file
   • You’ll need to change the require/require_once statement in the top of the file you just copied – to point to the correct place as when you override the autoloader won’t be able to find the class you’re trying to include.
   • This file will generally just be a placeholder – with all the work being done in the parent class.  You’ll need to refer to the base class or have a decent IDE that gives you code assist or exploring of the methods in the parent to determine what method signatures are available for you
4. Now you can implement your own functionality in the file – for an action start with something simple like overriding a method and putting die(“hey – it worked! – Who’s da man?!?!”).  You can even put this just under the require statement to test – so you’ll know that it was your customised file that was included rather than the specific one within the plugin itself.
5. Clear your cache again and fire up your browser to load a page under the application you used above
6. Now you see your die statement is being hit – you can implement the actual code you want to happen

The locations available for you to put custom classes are:

• project\apps\thisApp\modules\moduleName\folderType\fileName
• project\apps\thisApp\lib\folderType\fileName
• project\apps\thisApp\lib\fileName
• project\lib\folderType\fileName
• project\lib\fileName

Where:

thisApp is your application name
moduleName is the name of your module or the plugin name
folderType is the type of folder – i.e. actions, templates, model, etc
fileName is the name of the file in the expected format (so actions.class.php for the actions class)

Posted via web from Dasher’s Dev Den