Posts tagged ‘dev tips’
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.
- 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
- 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
- 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
- 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.
- Clear your cache again and fire up your browser to load a page under the application you used above
- 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:
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)