This forum is in READ-ONLY mode.
You can look around, but if you want to ask a new question, please use the new forum.
Home » plugins » User management plugins » sfDoctrineApplyPlugin - Undocumented steps to make it work, and without Zend_Mail
sfDoctrineApplyPlugin - Undocumented steps to make it work, and without Zend_Mail [message #92774] Tue, 02 February 2010 20:41 Go to next message
stephenrs  is currently offline stephenrs
Messages: 22
Registered: January 2010
Junior Member
I had some problems getting sfDoctrineApplyPlugin to work - mostly because of some gaps in the documentation and weirdness in the code - so I decided to document what I did to make it work, in case anyone else is having trouble. Also, this solution uses Symfony's bundled mailer (SwiftMailer), so you don't have to install anything from Zend...which seems to make a little more sense to me...

This solution has been tested with Symfony1.4.1 and sfDoctrineApplyPlugin1.1.0. I'm sure it can be improved further but this has worked for me:

1. Installation

Since the plugin's readme says much about how to install Zend_Mailer, and nothing about how to install the plugin itself (and I couldn't find any combination of ./symfony plugin:install... that would fetch the plugin and install it) - and if you're not used to installing plugins manually, try this:

- Download the plugin from the plugins page ( http://www.symfony-project.org/plugins/sfDoctrineApplyPlugin)

- Unpack the archive, and copy the plugin directory to your project's /plugins directory (I called mine sfDoctrineApplyPlugin, removing the version "-1.1.0" from the directory name)

- Important: add this line to the setup() method of your /config/ProjectConfiguration.class.php:

    $this->enablePlugins('sfDoctrineApplyPlugin');


2. Configuration

The readme will tell you to put the following in your doctrine/schema.yml:

sfGuardUserProfile:
  tableName: sf_guard_user_profile
  columns:
    id:
      type: integer(4)
      primary: true
      autoincrement: true
    user_id:
      type: integer(4)
      notnull: true
    email:
      type: string(80)
    fullname:
      type: string(80)
    validate:
      type: string(17)

...etc...


If you're using the latest version of sfDoctrineGuard, then the above entries in your schema.yml will produce SQL errors when you run your next symfony doctrine:build..., and your foreign key won't work. To fix this, replace the above with the following:

sfGuardUserProfile:
  tableName: sf_guard_user_profile
  columns:
    id:
      type: integer(20)
      primary: true
      autoincrement: true
    user_id:
      type: integer(20)
      notnull: true
    email:
      type: string(80)
    fullname:
      type: string(80)
    validate:
      type: string(17)


Notice the type definitions for id and user_id in the lines above. The user_id type is the most important, because in a foreign key relationship, the columns involved in the relation must have types that match exactly. The user(id) column of sf_guard_user is a BIGINT (integer(20)), so the foreign key user_id must also be a BIGINT. I've also made sf_guard_user_profile(id) an integer(20) so that my system can have as many profiles as users.

3. Getting rid of Zend_Mailer

To do this, you need to override 2 of sfApply's methods. Create a module called sfApply in your application, and put this in the .../modules/sfApply/actions/actions.class.php:

require_once(sfConfig::get('sf_plugins_dir').'/sfDoctrineApplyPlugin/modules/sfApply/lib/BasesfApplyActions.class.php');

class sfApplyActions extends BasesfApplyActions
{
  public function executeApply(sfRequest $request)
  {
    $this->form = $this->newForm('sfApplyApplyForm');
    if ($request->isMethod('post'))
    {
      $this->form->bind($request->getParameter('sfApplyApply'));
      if ($this->form->isValid())
      {
        $guid = "n" . self::createGuid();
        $this->form->setValidate($guid);
        $this->form->save();
        try
        {
          $profile = $this->form->getObject();
          $this->mail(array('subject' => sfConfig::get('app_sfApplyPlugin_apply_subject',
              sfContext::getInstance()->getI18N()->__("Please verify your account on %1%", array('%1%' => $this->getRequest()->getHost()))),
            'fullname' => $profile->getFullname(),
            'email' => $profile->getEmail(),
            'parameters' => array('fullname' => $profile->getFullname(), 'validate' => $profile->getValidate()),
            'text' => 'sfApply/sendValidateNewText',
            'html' => 'sfApply/sendValidateNew'));
          return 'After';
        }
        catch (Exception $e)
        {
          //$mailer->disconnect();
          $profile = $this->form->getObject();
          $user = $profile->getUser();
          $user->delete();
            // You could re-throw $e here if you want to 
          // make it available for debugging purposes
          return 'MailerError';
        }
      }
    }
  }
  
  protected function mail($options) {
    $required = array('subject', 'parameters', 'email', 'fullname', 'html', 'text');
    foreach ($required as $option)
    {
      if (!isset($options[$option]))
      {
        throw new sfException("Required option $option not supplied to sfApply::mail");
      }
    }
    $message = $this->getMailer()->compose();
    $message->setSubject($options['subject']);
    
    // Render message parts
    $message->setBody($this->getPartial($options['html'], $options['parameters']), 'text/html');
    $message->addPart($this->getPartial($options['text'], $options['parameters']), 'text/plain');
    $address = $this->getFromAddress();
    $message->setFrom(array($address['email'] => $address['fullname']));
    $message->setTo(array($options['email'] => $options['fullname']));
    $this->getMailer()->send($message);
  }
}


This snippet overrides the mail() method to replace Zend_Mailer with the built-in SwifMailer.

It also overrides the executeApply method, simply commenting out the line that says:

$mailer->disconnect();


...because this line will always generate a PHP fatal error...$mailer is never defined...

You may also need to configure SwiftMailer to handle outbound mail, depending on your server environment. The JoeBeet tutorial (http://www.symfony-project.org/jobeet/1_4/Doctrine/en/16) is an excellent source of info on how to do this. For reference, I'm using a gmail account for sending mail, and the relevant section of my factories.yml file looks like this:

all:
  mailer:
    class: sfMailer
    param:
      logging:           %SF_LOGGING_ENABLED%
      charset:           %SF_CHARSET%
      delivery_strategy: realtime
      transport:
        class: Swift_SmtpTransport
        param:
          host:       smtp.gmail.com
          port:       465
          encryption: ssl
          username:   your.username@gmail.com
          password:   your.password


As I mentioned, this setup is working for me - so I hope this helps someone. Better yet, I hope the authors are inspired to update the docs, clean up the plugin, and remove the unnecessary dependency to Zend_Mailer.

Happy coding!
Re: sfDoctrineApplyPlugin - Undocumented steps to make it work, and without Zend_Mail [message #92777 is a reply to message #92774 ] Tue, 02 February 2010 22:05 Go to previous messageGo to next message
stephenrs  is currently offline stephenrs
Messages: 22
Registered: January 2010
Junior Member
UPDATE: Because executeApply() calls a static private method of BasesfApplyActions - "createGuid()", you'll need to workaround this in order to successfully override the executeApply() method. Obviously, there are a few ways to do this, but the quickest (I'm in a hurry) way, while avoiding changing the original plugin code, is to simply override createGuid() in your modules/sfApply/actions/actions.class.php, like so:

  static private function createGuid()
  {
    $guid = "";
    // This was 16 before, which produced a string twice as
    // long as desired. I could change the schema instead
    // to accommodate a validation code twice as big, but
    // that is completely unnecessary and would break 
    // the code of anyone upgrading from the 1.0 version.
    // Ridiculously unpasteable validation URLs are a 
    // pet peeve of mine anyway.
    for ($i = 0; ($i < 8); $i++) {
      $guid .= sprintf("%02x", mt_rand(0, 255));
    }
    return $guid;
  }


Of course, if you don't want to override executeApply(), and you don't mind changing the core plugin code, you can always just comment out the PHP fatal error line described in the original post...
Re: sfDoctrineApplyPlugin - Undocumented steps to make it work, and without Zend_Mail [message #93380 is a reply to message #92774 ] Fri, 12 February 2010 00:02 Go to previous messageGo to next message
alberthendriks  is currently offline alberthendriks
Messages: 25
Registered: March 2008
Junior Member
Thanks, that helped a lot. I agree that the documentation is crappy, it was still a pain to get it to work. Here are some extra notes that might help others.

Beware to put the "from" in app.yml. Mine now looks like this:
all:
  sfApplyPlugin:
    from:
      email: "info@email.com"
      fullname: "Company Name"

I did not need to install Zend nor Swiftmailer. The method mentioned above uses swiftmailer, which is included in symfony.

Be sure that in your database, sf_guard_user_profile has values for the columns email and fullname.

Your computer/server still needs a way to send mail. The closest I get on my laptop when requesting a new password is that in the /my_symfony_application/log 's, I find:
Sending email "Please verify your password reset request on localhost" to "info@email.com"

.. while the mail is still not sent. On the commandline I type mailq and see the messages. On my server on the other hand, The messages are sent. By gmail they are marked as spam, but that's hopefully because I did not make my own templates yet.

In factories.yml I have:
dev:
  mailer:
    param:
      delivery_strategy: realtime

so the emails are also sent when accessing through frontend_dev.php.

I use this plugin mainly for password recovery. I don't want new users to subscribe themselves so I turned that off (and didn't test that part).
Re: sfDoctrineApplyPlugin - Undocumented steps to make it work, and without Zend_Mail [message #93383 is a reply to message #93380 ] Fri, 12 February 2010 00:19 Go to previous messageGo to next message
stephenrs  is currently offline stephenrs
Messages: 22
Registered: January 2010
Junior Member
Good suggestions, and I'd further add that the plugin's bold dependence on the fullname field is pretty limiting for I'd think the vast majority of sites that collect firstName and lastName separately (I can't remember the last time I had to enter my full name in any web form single input field) - so I've changed that in the plugin as well.

The plugin also plainly breaks sfGuard's ability to allow login by username OR email_address (which is a requirement on my project), so I had to fix that too.

I'm a bit too pressed for time right now to writeup instructions for how I handled these last bits to bring the plugin up to snuff, but if anyone is really interested, let me know.
Re: sfDoctrineApplyPlugin - Undocumented steps to make it work, and without Zend_Mail [message #93418 is a reply to message #92774 ] Fri, 12 February 2010 13:25 Go to previous messageGo to next message
alberthendriks  is currently offline alberthendriks
Messages: 25
Registered: March 2008
Junior Member
I'd be interested. If you could indicate what to do I can write it out.
Re: sfDoctrineApplyPlugin - Undocumented steps to make it work, and without Zend_Mail [message #93465 is a reply to message #93418 ] Sat, 13 February 2010 09:47 Go to previous messageGo to next message
stephenrs  is currently offline stephenrs
Messages: 22
Registered: January 2010
Junior Member
I've attached a zip file containing the myApp/modules/sfApply/actions/actions.class.php, and lib/form/doctrine/sfApplyApplyForm.class.php overrides that I'm using in my project. actions.class.php overrides almost all the methods in the original plugin, and sfApplyApplyForm.class.php sets the form up the way I wanted it (including not requiring users to enter their email addresses twice) - but most importantly it overrides the doSave() method to properly update the sfGuardUser table with the email address field.

Overall though, if you diff the files with the originals, I think the changes are pretty minor.

Note: Among other custom changes for your particular situation, you'll probably need to remove references to sfValidatorNotDefault from sfApplyApplyForm.class.php - I've written a custom validator for my situation that I haven't included.

Here are the relevant entries from my schema.yml file:

sfGuardUserProfile:
  tableName: sf_guard_user_profile
  columns:
    id:
      type: integer(20)
      primary: true
      autoincrement: true
    user_id:
      type: integer(20)
      notnull: true
      unique: true
    email:
      type: string(255)
      notnull: true
      unique: true
    first_name:
      type: string(80)
    last_name:
      type: string(80)
    zipcode:
      type: string(10)
    validate:
      type: string(17)
  # Don't forget this!
  relations:
    User:
      class: sfGuardUser
      foreign: id
      local: user_id
      type: one  
      onDelete: cascade    
      foreignType: one
      foreignAlias: Profile


The main benefits of this solution are that users can login using username or email address (username is optional in my app), and that you can collect first name and last name as separate fields.

One drawback of this particular solution is that you'll end up duplicating the email address in the sf_guard_user and sf_guard_user_profile tables, so there's definitely room for some improvement - but it works.

Actually, I think the better solution for this plugin in general would be to use Doctrine Table Inheritance to extend the fields of sf_guard_user to avoid the field duplication, and make it integrate more cleanly with sfGuard...maybe I'll get around to that at some point...

Hope this works out for you, good luck!

Re: sfDoctrineApplyPlugin - Undocumented steps to make it work, and without Zend_Mail [message #93596 is a reply to message #93465 ] Mon, 15 February 2010 17:38 Go to previous messageGo to next message
alberthendriks  is currently offline alberthendriks
Messages: 25
Registered: March 2008
Junior Member
Thanks. You've almost created a fork of this plugin.
Re: sfDoctrineApplyPlugin - Undocumented steps to make it work, and without Zend_Mail [message #93621 is a reply to message #93596 ] Mon, 15 February 2010 20:21 Go to previous messageGo to next message
stephenrs  is currently offline stephenrs
Messages: 22
Registered: January 2010
Junior Member
Yes, I've had the same thought, but I'm a bit too busy at the moment to clean up and package it up nicely. Feel free to use the code to create a new and improved registration plugin for the community, or let me know if you'd like to work on it together.

...and I definitely think that in order for this to be worthwhile as a separate plugin, it should use one Doctrine's table inheritance strategies...
Re: sfDoctrineApplyPlugin - Undocumented steps to make it work, and without Zend_Mail [message #94173 is a reply to message #92774 ] Wed, 24 February 2010 14:25 Go to previous messageGo to next message
nwahs81  is currently offline nwahs81
Messages: 6
Registered: February 2010
Junior Member
Hi ya,

I have a problem with the fix. I have pasted your code segment in but however I keep getting this error:

An error took place during the email delivery process. Please try again later.

This happened when i click on submit
I think it has to do with the setting up of the smtp server connection. I am using gmail smtp

can you kindly guide me how do i actually set up the code for gmail smtp server(etc Where should I configure the smtp server setup.)

Thanks in Advance
Newbie..
Re: sfDoctrineApplyPlugin - Undocumented steps to make it work, and without Zend_Mail [message #94186 is a reply to message #92774 ] Wed, 24 February 2010 14:57 Go to previous messageGo to next message
nwahs81  is currently offline nwahs81
Messages: 6
Registered: February 2010
Junior Member
Hi there,

I have solved my problem. My problem is I did not enabled ssl in php.ini. silly me lol

extension=php_openssl.dll

Hope this will help someone.

Thanks
Newbie
Re: sfDoctrineApplyPlugin - Undocumented steps to make it work, and without Zend_Mail [message #94188 is a reply to message #92774 ] Wed, 24 February 2010 15:12 Go to previous messageGo to next message
alberthendriks  is currently offline alberthendriks
Messages: 25
Registered: March 2008
Junior Member
Good that you worked it out.

@stephen I'm afraid I don't have time for that..
Re: sfDoctrineApplyPlugin - Undocumented steps to make it work, and without Zend_Mail [message #94313 is a reply to message #92774 ] Thu, 25 February 2010 23:51 Go to previous messageGo to next message
fizyk  is currently offline fizyk
Messages: 64
Registered: December 2009
Location: Western Slavic Republic
Member
Nice work guys. I might be able to help with this plugin in a month, I just need to get to know symfony better than what I did so far.
And from what I've read about Doctrine's inheritence, sounds promising to include it in such fork.

just one note. There seems to be another omission in plugin's readme, there's no route for resetCancel, so don't be surprised when you'll try to reset your password Wink

add this to routing.yml
reset:
  url: /reset
  param: { module: sfApply, action: reset }
Re: sfDoctrineApplyPlugin - Undocumented steps to make it work, and without Zend_Mail [message #94332 is a reply to message #92774 ] Fri, 26 February 2010 11:01 Go to previous messageGo to next message
aki@beaglesoft.de  is currently offline aki@beaglesoft.de
Messages: 3
Registered: February 2010
Junior Member
Hi all,

how can i set some creditials/permissions on users apply? [SOLVED]

I need to AutoLogin user after Apply. How can i do that?

[Updated on: Fri, 26 February 2010 17:37]


make it possible!
Re: sfDoctrineApplyPlugin - Undocumented steps to make it work, and without Zend_Mail [message #94487 is a reply to message #93465 ] Mon, 01 March 2010 14:43 Go to previous messageGo to next message
fizyk  is currently offline fizyk
Messages: 64
Registered: December 2009
Location: Western Slavic Republic
Member
stephenrs wrote on Sat, 13 February 2010 09:47

but most importantly it overrides the doSave() method to properly update the sfGuardUser table with the email address field.

One drawback of this particular solution is that you'll end up duplicating the email address in the sf_guard_user and sf_guard_user_profile tables, so there's definitely room for some improvement - but it works.
[...]
Actually, I think the better solution for this plugin in general would be to use Doctrine Table Inheritance to extend the fields of sf_guard_user to avoid the field duplication, and make it integrate more cleanly with sfGuard...maybe I'll get around to that at some point...


I'm working currently into integrating all changes proposed here into one plugin-like package, and will post my efforts in a few days.
After that I'm going to look into Inheritance and work on that as well, however I'm thinking that this plugin should override few sfUserGuard settings or generators as well, or possibly recomend them.

Got one question however to you. You say that you duplicate emails, have you modified sfUserGuard schema as well? As I don't have emails in mine sfUserGuard.

EDIT: Oh, And I'll ignore in that package your custom sfApplyApplyForm, so trying those modification wouldn't require schema modifications.

[Updated on: Mon, 01 March 2010 14:46]

Re: sfDoctrineApplyPlugin - Undocumented steps to make it work, and without Zend_Mail [message #94493 is a reply to message #92774 ] Mon, 01 March 2010 16:52 Go to previous messageGo to next message
fizyk  is currently offline fizyk
Messages: 64
Registered: December 2009
Location: Western Slavic Republic
Member
Okay, here it is.
I suppose I should explain what I did:

  1. Moved all Baseaction, and Basecomponents to their corresponding actions, and components classes.
  2. Both static functions moved to separate library
  3. Removed all Zend references, since they are no longer used removed $mailer->close(); as there was no such object anyway.


Regarding first point, all non execute methods could be moved to separate library and place it in extend chain between our actions and sfActions? It could also contain all static functions, but protected, not private.

Regarding Inheritance, I'm wondering, what would be better, to extend sfGuardUser, or set default Profile schema and extend it? How will the link between User and Profile behave?

We could also add some task to remove not activated accounts.

Re: sfDoctrineApplyPlugin - Undocumented steps to make it work, and without Zend_Mail [message #94522 is a reply to message #92774 ] Mon, 01 March 2010 22:53 Go to previous messageGo to next message
fizyk  is currently offline fizyk
Messages: 64
Registered: December 2009
Location: Western Slavic Republic
Member
I've got few fixes, mostly cosmetic in code. Trying to figure out inheritance.
It would be very easy using simple or column_aggregation inheritance type, however if we'd like to set like email field as required (and as notnull in database), that would get quite problematic... since those inheritances won't allow that.
Because of that it would be preferred to use concrete inheritance type. I'm not sure however how would associations behave, especially from other sfGuard's supplied object as permission and group.
For sfGuard user class it'd be possible to override it's basic method so that it would retrieve itself from sfGuardUserProfile class. I don't have any idea right now how to change permission and group.

I do know however how will further profile extension will be solved, that is by using simple or column_aggregation inheritance type. That shouldn't create much problem later I hope.

if anyone have some experience in concrete inheritance and it's influence on associations, please share your experience.
Re: sfDoctrineApplyPlugin - Undocumented steps to make it work, and without Zend_Mail [message #94526 is a reply to message #92774 ] Tue, 02 March 2010 01:15 Go to previous messageGo to next message
stephenrs  is currently offline stephenrs
Messages: 22
Registered: January 2010
Junior Member
@fizyk - Just wanted to let you know that I've been following your posts to this thread, and I think it's great that you're advancing the plugin. Nice work. I'm in a sprint for a launch (tonight), so I don't have much time to reply - except to say that (1) I don't remember adding the email field to sfGuard (although I've been writing code fast and furious the last couple months, and might have forgotten), and since it already had the built-in feature login_with_username_or_email, or some such, I doubt it.

And (2) I think concrete inheritance is the way to go with this one, but maybe I'll reconsider and have something to add once I've had more time to think it through.

Good luck and happy coding!
Re: sfDoctrineApplyPlugin - Undocumented steps to make it work, and without Zend_Mail [message #94639 is a reply to message #92774 ] Wed, 03 March 2010 10:39 Go to previous messageGo to next message
mbernasocchi  is currently offline mbernasocchi
Messages: 31
Registered: June 2009
Member
stephenrs wrote on Tue, 02 February 2010 20:41


If you're using the latest version of sfDoctrineGuard, then the above entries in your schema.yml will produce SQL errors when you run your next symfony doctrine:build..., and your foreign key won't work. To fix this, replace the above with the following:



Hi, I was having a look at this post and i felt, wait a minute, I did follow the doc and it all worked properly, so I went out to see if I had an old version, but no.

it turns out the problem is actually in sfGuard, if you download the package, then the schema.yml looks like this:
sfGuardUser:
  actAs: [Timestampable]
  columns:
    id:
      type: integer(4)
      primary: true
      autoincrement: true
    username:
      type: string(128)
      notnull: true
      unique: true

on the other hand, if you install via svn trunk, then it looks like this:
sfGuardUser:
  actAs: [Timestampable]
  columns:
    first_name: string(255)
    last_name: string(255)
    email_address:
      type: string(255)
      notnull: true
      unique: true
    username:
      type: string(128)
      notnull: true
      unique: true

So, the basic problem is that sfGuard trunk schema.yml has evolved. I guess it's the disadvantage of using a trunk checkout. Using the 1.3 branch works (the file is the same as the one in the 4.01 package).

that is why you have already the email field in your sfGuardUser table.

So, if you stick to the package verson of sfGuard, then there is no need (actually it might even breack things the other way around) to do the schema.yml modifications.

thanks for the mailer thing! it's a pitty that they decided to go for zend mailer just before the swift mailer takeover was announced...

cheers Marco
Re: sfDoctrineApplyPlugin - Undocumented steps to make it work, and without Zend_Mail [message #94826 is a reply to message #94639 ] Thu, 04 March 2010 21:43 Go to previous messageGo to next message
fizyk  is currently offline fizyk
Messages: 64
Registered: December 2009
Location: Western Slavic Republic
Member
mbernasocchi wrote on Wed, 03 March 2010 10:39


So, the basic problem is that sfGuard trunk schema.yml has evolved. I guess it's the disadvantage of using a trunk checkout. Using the 1.3 branch works (the file is the same as the one in the 4.01 package).



I wonder when these changes will be incorporated into next table release.

Anyway, report:
I'm working on incorporating custom extension to profile first, and it looks promising, using simple inheritance here.
However I stumbled across one thing, and don't know which way to choose:
If we leave relations in sfGuardUserProfile which will be included into plugin, extending will just add methods and variables to sfGuardUserProfile class and fields to it's table.
If we instead add that to extension, we'll have that extension under sfUserGuard::getProfile(), and it seems to be the main difference. It's important if we'd like to tell which model/filter/form plugin's user should customize.

Oh, and I'm starting to think, that it's actually good that login credentials are separate from profile data. One more information bad guys would have to look for, if changed from generated/default.
Re: sfDoctrineApplyPlugin - Undocumented steps to make it work, and without Zend_Mail [message #95228 is a reply to message #92774 ] Wed, 10 March 2010 23:15 Go to previous messageGo to next message
fizyk  is currently offline fizyk
Messages: 64
Registered: December 2009
Location: Western Slavic Republic
Member
Here's another version of our fork.
I mostly focused on inheritance, and introduced plugins own schema.yml.

It includes sfGuardUserProfileBasis which you've got to inherite in your sfGuardUserProfile.
You ought to have at least minimal version:
sfGuardUserProfile:
  inheritance:
    type: simple
    extends: sfGuardUserProfileBasis
  # Don't forget this!
  relations:
    User:
      class: sfGuardUser
      foreign: id
      local: user_id
      type: one
      onDelete: cascade
      foreignType: one
      foreignAlias: Profile


And like the above example, it should include relation to sfGuardUser.

I've fixed a little bit that basis schema compared to what was proposed in original, and moved some validators to separate classes.

Future plans are mostly covered by todo entries (like plan to create task to clean old validate fields.
I'm also considering reactivate validate field generation as 16 chars, not just 8.

Re: sfDoctrineApplyPlugin - Undocumented steps to make it work, and without Zend_Mail [message #95313 is a reply to message #92774 ] Thu, 11 March 2010 22:26 Go to previous messageGo to next message
fizyk  is currently offline fizyk
Messages: 64
Registered: December 2009
Location: Western Slavic Republic
Member
After the last functional change:
logged in user will no longer receive emails demanding confirmation to reset passwords. instead will be redirected to reset password form.

So, I've got question, has anyone used app_sfDoctrineApplyPlugin_afterLogin and app_sfDoctrineApplyPlugin_after settings? I seem can't find these nowhere in source.
Re: sfDoctrineApplyPlugin - Undocumented steps to make it work, and without Zend_Mail [message #95318 is a reply to message #92774 ] Thu, 11 March 2010 23:17 Go to previous messageGo to next message
mbernasocchi  is currently offline mbernasocchi
Messages: 31
Registered: June 2009
Member
hey, any Idea how could executeResetRequest
if ($this->form->isValid())
        {
          $user = sfGuardUserTable::retrieveByUsername(
            $this->form->getValue('username'));
          return $this->resetRequestBody($user);
        }

be changed so that it does not throw
Strict standards: Non-static method PluginsfGuardUserTable::retrieveByUsername() should not be called statically, assuming $this from incompatible context in ..../plugins/sfDoctrineApplyPlugin/modules/sfApply/lib/BasesfApplyActions.class.php on line 91


Thanks a lot
Marco
Re: sfDoctrineApplyPlugin - Undocumented steps to make it work, and without Zend_Mail [message #95385 is a reply to message #95318 ] Fri, 12 March 2010 19:54 Go to previous messageGo to next message
fizyk  is currently offline fizyk
Messages: 64
Registered: December 2009
Location: Western Slavic Republic
Member
Try this:

if ($this->form->isValid())
        {
          $user = Doctrine::getTable('sfGuardUser')->retrieveByUsername(
            $this->form->getValue('username'));
          return $this->resetRequestBody($user);
        }


I know it's against the best practicies, but the other way is to declare static method in you sfGuardUserTable class.

[Updated on: Fri, 12 March 2010 19:55]

Re: sfDoctrineApplyPlugin - Undocumented steps to make it work, and without Zend_Mail [message #95516 is a reply to message #95385 ] Mon, 15 March 2010 22:51 Go to previous messageGo to next message
fizyk  is currently offline fizyk
Messages: 64
Registered: December 2009
Location: Western Slavic Republic
Member
Okay here's the latest version.
I moved the action library to action/ folder, added polish translation, prepared readme and license files.

here's the general list of changes since the beginning of the thread:


* Introduced simple inheritance for profile class.
* Logged user won't get confirmation email when accidentaly requesting password change.
* Visitor can't get access to reset password page if not logged in, or haven't ame through confirmation page.
* Doubled the original confirmation string.
* Moved action library class into apropriate folder
* Added polish translation


I'm almost ready to deploy this plugin to symfony site. All I need is more information about stephen (to credit you in proper way) and update few glitches in polish translation.

Re: sfDoctrineApplyPlugin - Undocumented steps to make it work, and without Zend_Mail [message #95527 is a reply to message #92774 ] Tue, 16 March 2010 04:18 Go to previous messageGo to next message
BillyParadise  is currently offline BillyParadise
Messages: 5
Registered: March 2010
Location: Canada
Junior Member
Hi, I've been attempting to follow along with you with this reincarnation of sfDoctrineApplyPlugin, and would like to thank you for taking your time to make this happen.

(in my mind, user authentication should be a part of the core of symfony and I shouldn't have to fight the system for hours just for a basic feature like user management - but I'm just some dumb Canadian and I guess I've become accustomed to pretty user interfaces like Wordpress.)

I'm working on a brand new deployment of symfony, and have been trying to install your latest version of the Forked plugin. Unfortunately it's a no-go.

Steps taken:

1. <install symfony to lib/vendor>
2. ./symfony generate:project <myapp>
3. ./symfony generate:app frontend
4. ./symfony plugin:install ./sfDoctrineGuardPlugin-4.0.1.tgz
5. <edit databases.yml and create the database>
6. ./symfony doc:build --all --and-load
7. ./symfony cc

and then I should be installing your plugin, right?
Quote:


./symfony plugin:install ./sfForkedDoctrineApplyPlugin.tgz
>> plugin installing plugin "./sfForkedDoctrineApplyPlugin.tgz"
>> sfPearFrontendPlugin Attempting to discover channel "."...
>> sfPearFrontendPlugin Attempting fallback to https instead of http on channel "."...
>> sfPearFrontendPlugin unknown channel "." in "./sfForkedDoctrineApplyPlugin.tgz"
>> sfPearFrontendPlugin could not extract the package.xml file from
>> sfPearFrontendPlugin "./sfForkedDoctrineApplyPlugin.tgz"

Plugin "./sfForkedDoctrineApplyPlugin.tgz" installation failed:



Please assist Smile

Thanks
BP
Re: sfDoctrineApplyPlugin - Undocumented steps to make it work, and without Zend_Mail [message #95528 is a reply to message #92774 ] Tue, 16 March 2010 04:26 Go to previous messageGo to next message
BillyParadise  is currently offline BillyParadise
Messages: 5
Registered: March 2010
Location: Canada
Junior Member
Just found the README file Wink Moron is going back to work - but the auto install is not working for me fyi Sad
Re: sfDoctrineApplyPlugin - Undocumented steps to make it work, and without Zend_Mail [message #95530 is a reply to message #92774 ] Tue, 16 March 2010 04:50 Go to previous messageGo to next message
BillyParadise  is currently offline BillyParadise
Messages: 5
Registered: March 2010
Location: Canada
Junior Member
Continuing.. sorry to make the thread longer... I unpacked and copied the directory to plugins, added routes, cleared cache... and now I am at:

Quote:

Fatal error: Class 'sfGuardUserProfileForm' not found in /usr/local/www/symfony/plugins/sfForkedDoctrineApplyPlugin/l ib/form/sfApplyApplyForm.class.php on line 4


Re: sfDoctrineApplyPlugin - Undocumented steps to make it work, and without Zend_Mail [message #95531 is a reply to message #92774 ] Tue, 16 March 2010 05:07 Go to previous messageGo to next message
BillyParadise  is currently offline BillyParadise
Messages: 5
Registered: March 2010
Location: Canada
Junior Member
I will have you all convinced by the end of the night that i'm a complete moron. That's what I get for trying to build an app while I'm doing a night shift Smile I"m going to shut up now, stop racing a mile a minute when i can barely crawl... and maybe get some sleep.

Re: sfDoctrineApplyPlugin - Undocumented steps to make it work, and without Zend_Mail [message #95540 is a reply to message #92774 ] Tue, 16 March 2010 08:18 Go to previous messageGo to next message
fizyk  is currently offline fizyk
Messages: 64
Registered: December 2009
Location: Western Slavic Republic
Member
Hello Billy,
I have the readme prepared with all the install statements but it's not yet installable, that's why I'm posting it here. Haven't built it yet as a PEAR package.

Going back to your further attempt, have you added to you'r schema.yml the sfGuardUserProfile table that inherits from the sfGuardUserProfileBasis from the plugin?
After that you should build your model, forms, sql and database again.
Re: sfDoctrineApplyPlugin - Undocumented steps to make it work, and without Zend_Mail [message #95674 is a reply to message #95540 ] Thu, 18 March 2010 10:07 Go to previous messageGo to next message
tnaseem  is currently offline tnaseem
Messages: 11
Registered: April 2008
Junior Member
fizyk,

Firstly, I'd just like to say many thanks to you and stephen for your work on this. It's saved me a hell of a headache!

I have a bit of an issue though. I've installed and got the Forked plugin working fine, up to a point.

I'm having problems with the password reset. Once I enter my new password and confirmation, I get a 404:

404 | Not Found | sfError404Exception
This request has been forwarded to a 404 error page by the action "sfApply/reset".


It's failing in executeReset() on the following lines:

    $this->id = $this->getUser()->getAttribute('sfApplyReset', false);
    $this->forward404Unless($this->id);


Not given much to go on, but was wondering if anything sprung to mind!

Many thanks.

Tarique.
Re: sfDoctrineApplyPlugin - Undocumented steps to make it work, and without Zend_Mail [message #95675 is a reply to message #95674 ] Thu, 18 March 2010 10:13 Go to previous messageGo to next message
tnaseem  is currently offline tnaseem
Messages: 11
Registered: April 2008
Junior Member
While I'm at it, stupid question 2:

What do I need to do to allow the user to register without the need to verify their email address?

Cheers,
Tarique.
Re: sfDoctrineApplyPlugin - Undocumented steps to make it work, and without Zend_Mail [message #95688 is a reply to message #95675 ] Thu, 18 March 2010 12:16 Go to previous messageGo to next message
fizyk  is currently offline fizyk
Messages: 64
Registered: December 2009
Location: Western Slavic Republic
Member
hey Tarique, I'll look for that 404 issue in the evening. But to be sure. you've got all routes correct and this happens after you try to change new password? I might have an idea about the problem...

As for the mail function. You have to set your user as is_active after registering him, and strip it of the possibility to generate confirmation code and add it to email.
it might be a good idea for a plugin setting like: confirm_new_account and choose if the new account should be confirmed through email or not.
Re: sfDoctrineApplyPlugin - Undocumented steps to make it work, and without Zend_Mail [message #95689 is a reply to message #95688 ] Thu, 18 March 2010 12:28 Go to previous messageGo to next message
tnaseem  is currently offline tnaseem
Messages: 11
Registered: April 2008
Junior Member
Thanks for getting back to me so quickly!

Yes, it happens when I try to change the new password (ie. When I click 'Reset My Password' on the /user/reset-password screen).

The excerpt from my routing.yml looks like this:

# sfForkedDoctrineApplyPlugin
apply:
  url:  /user/register
  param: { module: sfApply, action: apply }

reset:
  url: /user/password-reset
  param: { module: sfApply, action: reset }

resetRequest:
  url: /user/reset-request
  param: { module: sfApply, action: resetRequest }

resetCancel:
  url: /user/reset-cancel
  param: { module: sfApply, action: resetCancel }

validate:
  url: /user/confirm/:validate
  param: { module: sfApply, action: confirm }

settings:
  url: /user/settings
  param: { module: sfApply, action: settings }
Re: sfDoctrineApplyPlugin - Undocumented steps to make it work, and without Zend_Mail [message #95730 is a reply to message #95689 ] Thu, 18 March 2010 22:33 Go to previous messageGo to next message
fizyk  is currently offline fizyk
Messages: 64
Registered: December 2009
Location: Western Slavic Republic
Member
Okay, I've pinned down the reason for this behaviour.
In the original, where you were mailed no matter if you were logged, or not, while you were confirming your email, your id got stored in session.

Now if you were changing password as logged in user, id hasn't been stored in session. Now it's fixed, as it get's the logged user id.

Additionally, we've got fixed i18n strings and complete polish translation Wink Package should be also installable with plugin:install filename.tgz (not through normal channel yet!) and I'll upload it on the weekend to the plugin section on symfony main website if no further bugs would get discovered.

Re: sfDoctrineApplyPlugin - Undocumented steps to make it work, and without Zend_Mail [message #95734 is a reply to message #95730 ] Thu, 18 March 2010 23:39 Go to previous messageGo to next message
tnaseem  is currently offline tnaseem
Messages: 11
Registered: April 2008
Junior Member
That's great! Thanks. Will try out the new version now. [EDIT: Just tried it and the password change work fine! Many thanks!]

I've been playing around with the user settings too. At the moment, the default only allows the user to change the first and last names.

I updated sfApplySettingsForm to allow the user to also change the email address. However, if you leave that field alone and only update the name, the validation fails with

An object with the same "email" already exist.

The configure function in sfApplySettingsForm is as follows:

    public function configure()
    {
        parent::configure();
        $this->removeFields();

        // We're editing the user who is logged in. It is not appropriate
        // for the user to get to pick somebody else's userid, or change
        // the validate field which is part of how their account is
        // verified by email. Also, users cannot change their email
        // addresses as they are our only verified connection to the user.

        $this->widgetSchema->setLabels(
                array(
                    'firstname' => 'First Name',
                    'lastname' => 'Last Name',
		    'email' => 'Email') );        // Added this

        $this->widgetSchema->moveField('email', sfWidgetFormSchema::LAST);        // Added this

        $this->widgetSchema->setNameFormat('sfApplySettings[%s]');
        $this->widgetSchema->setFormFormatterName('table');

        $this->setValidator('firstname' , new sfValidatorApplyFirstname() );
        $this->setValidator('lastname', new sfValidatorApplyLastname() );
        $this->setValidator('email', new sfValidatorEmail(array('required' => true, 'trim' => true)));        // Added this.
    }

    private function removeFields()
    {
        unset(
                $this['user_id'],
                $this['validate'],
//              $this['email'],
                $this['validate_at'], 
                $this['id'],
                $this['created_at'],
                $this['updated_at']
                );
    }


Not quite sure how to get around the email validator checking against itself, and coming back as already in use.

I'm pretty new to Symfony 1.4, so all this form validation stuff is new territory for me, so any help would be appreciated!

Of course, I shouldn't really be editing directly in the plugin, but I was just doing that as a quick test to see parts working.

Any clues?

Cheers,
Tarique.

[Updated on: Thu, 18 March 2010 23:55]

Re: sfDoctrineApplyPlugin - Undocumented steps to make it work, and without Zend_Mail [message #95824 is a reply to message #92774 ] Fri, 19 March 2010 19:54 Go to previous messageGo to next message
fizyk  is currently offline fizyk
Messages: 64
Registered: December 2009
Location: Western Slavic Republic
Member
That's because validator check the email in database, without excluding current user from the check query.
The Validator would have to be slightly adjusted to allow email editing. This however would require another confirmation email for security reasons. You wouldn't want someone to change your email while you're gone for a coffee, and accidentally stay logged in, and after that change your password.
That's another todo to the list Wink
Re: sfDoctrineApplyPlugin - Undocumented steps to make it work, and without Zend_Mail [message #96113 is a reply to message #95824 ] Wed, 24 March 2010 13:44 Go to previous messageGo to next message
sela  is currently offline sela
Messages: 24
Registered: November 2009
Location: London
Junior Member
installed the new plugin and get this error message
Fatal error: Class 'sfGuardUserProfileForm' not found in /Code/sfprojects/myproj/plugins/sfForkedDoctrineApplyPlugin/ lib/form/sfApplyApplyForm.class.php on line 4
for creating new user /frontend_dev.php/user/new

I didn't configure yet the mail settings according to day 16?
Re: sfDoctrineApplyPlugin - Undocumented steps to make it work, and without Zend_Mail [message #96137 is a reply to message #96113 ] Wed, 24 March 2010 17:44 Go to previous messageGo to next message
fizyk  is currently offline fizyk
Messages: 64
Registered: December 2009
Location: Western Slavic Republic
Member
Hey sela. That's not becouse you haven't cofigured mail settings. It's becouse sfApplyApplyForm extends sfGuardUserProfile form, which gets created at first in your project's lib/form/doctrine folder after you build: models, forms and filters.
have you run any doctrine:build tasks after installing sfForked?

Check if the Form file and class appears in the folder I mentioned above.
Re: sfDoctrineApplyPlugin - Undocumented steps to make it work, and without Zend_Mail [message #96138 is a reply to message #96137 ] Wed, 24 March 2010 17:50 Go to previous messageGo to next message
sela  is currently offline sela
Messages: 24
Registered: November 2009
Location: London
Junior Member
i read again the text and indeed i couldn't find it and ran again the doctrine build for forms models and sql and couldn't find it in the lib/doctrine, so not sure why it's not created?
Re: sfDoctrineApplyPlugin - Undocumented steps to make it work, and without Zend_Mail [message #96139 is a reply to message #96138 ] Wed, 24 March 2010 18:32 Go to previous messageGo to previous message
fizyk  is currently offline fizyk
Messages: 64
Registered: December 2009
Location: Western Slavic Republic
Member
Have you added this in your schema.yml?

sfGuardUserProfile:
  inheritance:
    type: simple
    extends: sfGuardUserProfileBasis
  # Don't forget this!
  relations:
    User:
      class: sfGuardUser
      foreign: id
      local: user_id
      type: one
      onDelete: cascade
      foreignType: one
      foreignAlias: Profile


If so, after you run doctrine:build task, you should have that form in lib/form/doctrine
Previous Topic:sfForkedDotrctineApplyPlugin is broken (latest version)
Next Topic:Customize sfGuard or use sfApply
Goto Forum:
  

powered by FUDforum - copyright ©2001-2004 FUD Forum Bulletin Board Software