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 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)
a. 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..
a. So if you're looking to override the actions then, for sfGuard, it's
going to be under the modules\sfGuardUser\actions\actions.class.php
b. Well written plugins will also have a base file - for sfGuard this
is BasesfGuardUserActions.class.php - which allows easy overriding of your
own functionality
c. You'll need to change the require/require_once statement in the top
of this copied file 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.
d. 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?!?!")
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)
Regarding your specific issue of capturing the source page where the use has
come from - you want to override the actions for the plugin and store the
referrer before sfGuard starts its own redirects - otherwise you'll lose the
information in the chain of redirects that happen. Most people append the
referrer to the URL as a parameter for this because unless you're careful
you'll lose the information if you try to store it in the session/cookie
(logging in will create a new session - so you'll need to transfer the
information from the existing session if you don't want to lose the data).
-----Original Message-----
From: symfony-users@googlegroups.com [mailto:symfony-us...@googlegroups.com]
On Behalf Of H. Tuttle
Sent: 15 May 2009 03:49
To: symfony users
Subject: [symfony-users] Re: do i directly edit sfGuardAuth signinSucess.php
if I want to customize the signing form, or do I override it elsewhere?
Yes, that's right. You can make your own sfGuardAuth module.
The other question almost as important is how do you overload the
sfGuardUser class? I have tried making my own sfGuardUser.php in the /
lib/model directory but with no success. I'd like to be able to stay
completely out of the plugin folders.
On May 14, 7:42 pm, Sid Bachtiar <sid.bacht...@gmail.com> wrote:
> That should be the default behaviour of sfGuardPlugin
>
> But if you want to customize the signinSuccess.php, don't do it on the
> plugin directory.
>
> Do it be creating
> "myproject/myapp/modules/sfGuardAuth/templates/signinSuccess.php" (do
> this manually, don't use symfony command line, e.g.: don't use symfony
> init-module).
>
> This should override the plugin's signinSuccess.php
>
> On Fri, May 15, 2009 at 12:23 PM, nick <lal...@teamlalala.com> wrote:
>
> > If someone tries to go to a secure page, and they are not logged in,
> > they get redirected to the login page, which has this template:
>
> > plugins/sfGuardPlugin/modules/sfGuardAuth/templates/signinSucess.php
>
> > I'd like to remember where the user was coming from, and then send
> > them there if they log in successfully. Do I directly edit
> > signinSuccess.php, or do I override it somewhere else?
>
> --
> Blue Horn Ltd - System Developmenthttp://bluehorn.co.nz
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"symfony users" group.
To post to this group, send email to symfony-users@googlegroups.com
To unsubscribe from this group, send email to
symfony-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-users?hl=en
-~----------~----~----~----~------~----~------~--~---
