On May 15, 5:23 am, "David Ashwood" <da...@inspiredthinking.co.uk>
wrote:
> 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
That's interesting that you test the code by putting in a die()
statement. I do the same thing. But that has not been a problem in
this case. I was able to override the plugin classes without any
trouble. I saw my die() statement fire as soon as I had overridden
sfGuardAuth. My problems started after that.
> 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
Yes, of course, but that isn't working for us. As I explained in an
earlier post:
When I look in BasesfGuardAuthActions.class.php, I see this code:
$this->form->bind($request->getParameter('signin'));
if ($this->form->isValid())
{
$values = $this->form->getValues();
$this->getUser()->signin($values['user'], array_key_exists
('remember', $values) ? $values['remember'] : false);
// always redirect to a URL set in app.yml
// or to the referer
// or to the homepage
$signinUrl = sfConfig::get
('app_sf_guard_plugin_success_signin_url', $user->getReferer
('@homepage'));
return $this->redirect($signinUrl);
}
We want the page that the user was trying to get to, which isn't
treated as the referer on my machine. For instance, if I am at the
home page, and then I try go here:
index.php/wiki/show/id/54
The home page is treated as the referer. But after the user signs in,
I want them to end up here:
index.php/wiki/show/id/54
The address I want is in getUri() instead of getReferer(). However, if
I change this:
return $this->redirect($signinUrl);
to this:
return $this->redirect($request->getUri());
then I end up with an infinite loop of redirection.
If I embed getUri() in the login form, and then submit it, and capture
it as a parameter, and then use it in the line above, I still get an
infinite loop of redirection.
Ideally I could use $this->forward(), but this forward usually takes a
module and action like this:
$this->forward('question', 'index');
I think it would be a lot of work for me to fetch the id and squeeze
it in there.
I could also drop out of Symfony and do this:
header('Location: ' . $request->getUri());
I tried this but it simply doesn't work. Nothing happens. Symfony
somehow smothers this.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
