logo
Ask your Symfony questions! Pay money and get answers fast! (more info)

Warning: Please do not give out any FTP or ssh credentials to anyone, unless you trust them completely. Giving out login details is dangerous.

If the asker does not get an answer then they have 10 days to request a refund.

$30
Fatal error: Call to a member function setLabel() on a non-object

This is a sfDoctrineGuardPlugin problem.

I try to create a user:

guard/users/new

Oddly enough, I'm getting an error that has already been fixed. The error is:

Fatal error: Call to a member function setLabel() on a non-object in /home/lkrubner/dev/tastingnotes/plugins/sfDoctrineGuardPlugin/lib/form/doctrine/base/BasesfGuardUserAdminForm.class.php on line 28


This bug was reported over a year ago, and it was fixed 6 months ago.

Just to be safe, I just deleted sfDoctrineGuardPlugin from my project and re-installed the newest version.

I'm using Symfony 1.4, running in a sort of sandbox setup.

If I go here:

plugins/sfDoctrineGuardPlugin/lib/form/doctrine/base/BasesfGuardUserAdminForm.class.php

I see this code:

<?php

/**
* BasesfGuardUserAdminForm
*
* @package sfDoctrineGuardPlugin
* @subpackage form
* @author Fabien Potencier <fabien.potencier@symfony-project.com>
* @version SVN: $Id: BasesfGuardUserAdminForm.class.php 25546 2009-12-17 23:27:55Z Jonathan.Wage $
*/
class BasesfGuardUserAdminForm extends BasesfGuardUserForm
{
/**
* @see sfForm
*/
public function setup()
{
parent::setup();

unset(
$this['last_login'],
$this['created_at'],
$this['updated_at'],
$this['salt'],
$this['algorithm']
);

$this->widgetSchema['groups_list']->setLabel('Groups');
$this->widgetSchema['permissions_list']->setLabel('Permissions');

$this->widgetSchema['password'] = new sfWidgetFormInputPassword();
$this->validatorSchema['password']->setOption('required', false);
$this->widgetSchema['password_again'] = new sfWidgetFormInputPassword();
$this->validatorSchema['password_again'] = clone $this->validatorSchema['password'];

$this->widgetSchema->moveField('password_again', 'after', 'password');

$this->mergePostValidator(new sfValidatorSchemaCompare('password', sfValidatorSchemaCompare::EQUAL, 'password_again', array(), array('invalid' => 'The two passwords must be the same.')));
}
}


The line
parent::setup(); should fix everything, yes?

So why am I getting this bug?

[UPDATE]

I tried this solution

It did not work. I ran these commands:

svn delete lib/form/doctrine/sfDoctrineGuardPlugin/

svn delete lib/form/doctrine/base/*

./symfony doctrine:build --model --forms --filters

./symfony cc



The error remains:


Fatal error: Call to a member function setLabel() on a non-object in /home/lkrubner/dev/tastingnotes/plugins/sfDoctrineGuardPlugin/lib/form/doctrine/base/BasesfGuardUserAdminForm.class.php on line 28



Also, the file BaseSfGuardGroupForm.class.php is here:

lib/form/doctrine/base

Is that correct? I'm thinking that is the wrong path. I had a similar problem when I'd copied some schema info to the wrong schema file. Though I am not aware of any such mistake now.


I'm looking at this line in BaseSfGuardUserForm.class.php:

$this->widgetSchema->setNameFormat('sf_guard_user[%s]');

This does not throw an error. And yet this line:

$this->widgetSchema['groups_list']->setLabel('Groups');

in BasesfGuardUserAdminForm.class.php throws an error, and the class is defined as:

class BasesfGuardUserAdminForm extends BasesfGuardUserForm

[update]

I notice an UPPER/lower case conflict in the above file and class names. Sure enough, this folder:

lib/form/doctrine/base

has these files:

BaseSfGuardForgotPasswordForm.class.php
BaseSfGuardGroupForm.class.php
BaseSfGuardGroupPermissionForm.class.php
BaseSfGuardPermissionForm.class.php
BaseSfGuardRememberKeyForm.class.php
BaseSfGuardUserForm.class.php
BaseSfGuardUserGroupForm.class.php
BaseSfGuardUserPermissionForm.class.php

and yet, in this folder:

lib/form/doctrine/sfDoctrineGuardPlugin/base/

I have these files (where the "s" is correctly lower case):

BasesfGuardForgotPasswordForm.class.php
BasesfGuardGroupForm.class.php
BasesfGuardGroupPermissionForm.class.php
BasesfGuardPermissionForm.class.php
BasesfGuardRememberKeyForm.class.php
BasesfGuardUserForm.class.php
BasesfGuardUserGroupForm.class.php
BasesfGuardUserPermissionForm.class.php


So I delete them all incorrect files in lib/form/doctrine/base and do "symfony cc" and yet the problem is still there. Even worse, if I do this:

./symfony doctrine:build --model --forms --filters

./symfony cc


the incorrect files reappear in lib/form/doctrine/base

Does anyone know why this would happen?


[UPDATE]

Read the details in my comments below. I had stupidly copied the schema info for the sfDoctrineGuardUser plugin to my main schema.yml file. And yet, the problems persists. Yes at this point, the schema info seems to be only where it should be:


lkrubner@webdev:~/dev/tastingnotes$ grep -R "sfGuardPermission:" *
grep: apps/tastingnotes/modules/note/templates/.#_form.php: No such file or directory
data/fixtures/.svn/text-base/sfGuard.yml.svn-base:sfGuardPermission:
data/fixtures/sfGuard.yml:sfGuardPermission:
plugins/sfDoctrineGuardPlugin/data/fixtures/fixtures.yml.sample:sfGuardPermission:
plugins/sfDoctrineGuardPlugin/data/fixtures/.svn/text-base/fixtures.yml.sample.svn-base:sfGuardPermission:
plugins/sfDoctrineGuardPlugin/config/doctrine/schema.yml:sfGuardPermission:
plugins/sfDoctrineGuardPlugin/config/doctrine/.svn/text-base/schema.yml.svn-base:sfGuardPermission:





[UPDATE]

This is interesting. Now if I run this command:

./symfony doctrine:clean-model-files


See the screenshot. I am asked to delete all the files relating to the sfDoctrineGuardUser plugin. I delete them all, then I run the same command again. There are no files to delete.

So far, so good.

But now I run this command:

./symfony doctrine:build --model --forms --filters


and now I run this again:


./symfony doctrine:clean-model-files


And once again I am asked to delete the same files that I just deleted!

The doctrine:build command recreated the files that doctrine:clean-model-files think are not in use!!!!


How can this be possible?



[UPDATE]

I'm not sure why this did not jump out at me sooner:

lkrubner@webdev:~/dev/tastingnotes$ ./symfony doctrine:clean-model-files
>> file+ /tmp/doctrine_schema_29265.yml
>> doctrine No files found for the model named "sfGuardGroupPermission"
>> doctrine Deleted a total of 0 file(s)
>> doctrine No files found for the model named "sfGuardGroupPermission"
>> doctrine Deleted a total of 0 file(s)
>> doctrine No files found for the model named "sfGuardUserPermission"
>> doctrine Deleted a total of 0 file(s)
>> doctrine No files found for the model named "sfGuardUserPermission"
>> doctrine Deleted a total of 0 file(s)
>> doctrine No files found for the model named "sfGuardUserGroup"
>> doctrine Deleted a total of 0 file(s)
>> doctrine No files found for the model named "sfGuardUserGroup"
>> doctrine Deleted a total of 0 file(s)
>> doctrine No files found for the model named "sfGuardRememberKey"
>> doctrine Deleted a total of 0 file(s)
>> doctrine No files found for the model named "sfGuardRememberKey"
>> doctrine Deleted a total of 0 file(s)
>> doctrine No files found for the model named "sfGuardForgotPassword"
>> doctrine Deleted a total of 0 file(s)
>> doctrine No files found for the model named "sfGuardForgotPassword"
>> doctrine Deleted a total of 0 file(s)
>> autoload Resetting application autoloaders
>> autoload Resetting CLI autoloader



How can doctrine:clean-model-files both know that this models exist, and yet think they are not in use? What does "not in use" mean? If doctrine:clean-model-files sees a model defined in a schema, is that not enough to assume it is in use somewhere?


[UPDATE]

Deleted the plugin and reinstalled with a fresh copy.

I ran:

 ./symfony doctrine:build --model --forms --filters


I noticed that once again the model, form and filter classes for sfDoctrineGuard are being created in the wrong place, and with an uppercase "S". So I deleted all of these files:

rm lib/model/doctrine/SfGuard*

rm lib/form/doctrine/SfGuard*

rm lib/filter/doctrine/SfGuard*

./symfony cc


Still the error is there.

Why would these files appear in the wrong place, and with the wrong capitalization?



[UPDATE]


I tried this fix too:

http://oldforum.symfony-project.org/index.php/m/98239/

find . -name *SfGuard*.php | xargs rm

No luck.

This question has been answered.

attachment image asker uploaded image

Lawrence Krubner | 01/26/11 at 2:12pm Edit

Previous versions of this question: 01/27/11 at 5:23pm | 01/27/11 at 5:37pm | 01/27/11 at 5:41pm | 01/27/11 at 5:54pm | 01/28/11 at 12:37pm | 01/28/11 at 2:19pm | 01/28/11 at 2:28pm | 01/28/11 at 2:35pm | 01/28/11 at 2:38pm | 01/28/11 at 2:55pm | 01/28/11 at 4:17pm

(25) Responses

See a threaded view of answers?

Warning: Please do not give out any FTP or ssh credentials to anyone, unless you trust them completely. Giving out login details is dangerous.

  • avatar
    Last edited:
    01/31/11
    12:33pm
    mongabure ibes says:

    Hi,

    For me, it's either a cache problem (but i think you clear the cache before) or an error on BasesfGuardUserForm class(lib/form/doctrine/sfDoctrineGuardPlugin/base/BasesfGuardUserForm.class.php). So you must check that 'groups_list' & 'permissions_list' widgets exist in this file.

    attachment image expert uploaded image

    Previous versions of this answer: 01/27/11 at 3:10am

  • avatar
    Last edited:
    01/31/11
    12:33pm
    Jakub Zalas says:

    After installing plugin in a fresh project there is no such issue. Therefore I think there's something wrong with your environment.

    You have parent::setup() call in your BasesfGuardUserAdminForm class. That means that either there's something wrong with its parent class (BasesfGuardUserForm) or you're looking at the wrong file.

    First case is easy to verify. Just take a look on what's in the BasesfGuardUserForm. group_list widget should be created in setup() method. Regenerating form classes will fix the issue.

    Second case may sound funny but I faced such an issue when I started using APC. If apc.stat option is set to off APC doesn't check if file was modified and keeps an old version in the memory. You could have different file on the file system and in the memory (the later is used).

    BTW: apc.stat should be off on production but on on developemt.






    Previous versions of this answer: 01/27/11 at 3:04pm

  • avatar
    Last edited:
    01/31/11
    12:33pm
    Loban Rahman says:

    +1 to ./symfony doctrine:clean-model-files
    It has solved many an annoying problem for me. Pity symfony does not do this automatically.

  • avatar
    Last edited:
    01/31/11
    12:33pm
    José Nahuel Cuesta Luengo says:

    I agree with Jakub: it seems like you have either modified your project's schema.yml file or the plugin's schema.yml.

    Grep your schema files looking for any redefinition of sfGuardUser or any related table, and see if the relation between sfGuardUser and sfGuardGroup/sfGuardPermission has been modified -or even worse, removed-.

    Then clean your model files and rebuild everything.

  • avatar
    Last edited:
    01/27/11
    2:47pm
    Lawrence Krubner says:

    I've cleared the cache, so it is not the problem.

  • avatar
    Last edited:
    01/27/11
    2:48pm
    Lawrence Krubner says:

    Why would there be an error in BasesfGuardUserForm? I just installed the newest version of the plugin.

  • avatar
    Last edited:
    01/27/11
    4:01pm
    Lawrence Krubner says:

    Not using APC but I'll check memcache.

  • avatar
    Last edited:
    01/27/11
    4:07pm
    Lawrence Krubner says:

    Here is the entire class. What do you think could go wrong?




    /**
    * sfGuardUser form base class.
    *
    * @method sfGuardUser getObject() Returns the current form's model object
    *
    * @package sf_sandbox
    * @subpackage form
    * @author Your name here
    * @version SVN: $Id: sfDoctrineFormGeneratedTemplate.php 29553 2010-05-20 14:33:00Z Kris.Wallsmith $
    */
    abstract class BasesfGuardUserForm extends BaseFormDoctrine
    {
    public function setup()
    {
    $this->setWidgets(array(
    'id' => new sfWidgetFormInputHidden(),
    'first_name' => new sfWidgetFormInputText(),
    'last_name' => new sfWidgetFormInputText(),
    'email_address' => new sfWidgetFormInputText(),
    'username' => new sfWidgetFormInputText(),
    'algorithm' => new sfWidgetFormInputText(),
    'salt' => new sfWidgetFormInputText(),
    'password' => new sfWidgetFormInputText(),
    'is_active' => new sfWidgetFormInputCheckbox(),
    'is_super_admin' => new sfWidgetFormInputCheckbox(),
    'last_login' => new sfWidgetFormDateTime(),
    'created_at' => new sfWidgetFormDateTime(),
    'updated_at' => new sfWidgetFormDateTime(),
    ));

    $this->setValidators(array(
    'id' => new sfValidatorChoice(array('choices' => array($this->getObject()->get('id')), 'empty_value' => $this->getObject()->get('id'), 'required' => false)),
    'first_name' => new sfValidatorString(array('max_length' => 255)),
    'last_name' => new sfValidatorString(array('max_length' => 255)),
    'email_address' => new sfValidatorString(array('max_length' => 255)),
    'username' => new sfValidatorString(array('max_length' => 128)),
    'algorithm' => new sfValidatorString(array('max_length' => 128, 'required' => false)),
    'salt' => new sfValidatorString(array('max_length' => 128)),
    'password' => new sfValidatorString(array('max_length' => 128)),
    'is_active' => new sfValidatorBoolean(array('required' => false)),
    'is_super_admin' => new sfValidatorBoolean(array('required' => false)),
    'last_login' => new sfValidatorDateTime(),
    'created_at' => new sfValidatorDateTime(),
    'updated_at' => new sfValidatorDateTime(),
    ));

    $this->widgetSchema->setNameFormat('sf_guard_user[%s]');

    $this->errorSchema = new sfValidatorErrorSchema($this->validatorSchema);

    $this->setupInheritance();

    parent::setup();
    }

    public function getModelName()
    {
    return 'sfGuardUser';
    }

    }

  • avatar
    Last edited:
    01/27/11
    5:08pm
    Lawrence Krubner says:

    I do this:

    ./symfony doctrine:build --model --forms --filters


    then this:

    ./symfony cc


    But the problem remains. You can see the error in the screenshot.

    attachment image expert uploaded image

  • avatar
    Last edited:
    01/28/11
    2:35am
    Jakub Zalas says:

    lib/form/doctrine/base is not a right location. The correct one is lib/form/doctrine/sfDoctrineGuardPlugin/base of course.

    Maybe you have a modified version of guard's schema in your project?

    Or you have some guard forms still in lib/form/doctrine (from previous installation) and therefore doctrine puts base classes to lib/form/doctrine/base? If so try moving them to lib/form/doctrine/sfDoctrineGuardPlugin.

    I would also try following approach:
    1. Remove all base classes
    2. Remove data/sql/*.sql
    3. run ./symfony doctrine:clean-model-files
    4. run ./symfony doctrine:build --all-classes

  • avatar
    Last edited:
    01/28/11
    3:28am
    mongabure ibes says:

    So "group_list" & "permissions_list" are missing in your BasesfGuardUserForm form. In my file, i have this lines on widget declaration :


    'groups_list' => new sfWidgetFormDoctrineChoice(array('multiple' => true, 'model' => 'sfGuardGroup')),
    'permissions_list' => new sfWidgetFormDoctrineChoice(array('multiple' => true, 'model' => 'sfGuardPermission')),


    and validators


    'groups_list' => new sfValidatorDoctrineChoice(array('multiple' => true, 'model' => 'sfGuardGroup', 'required' => false)),
    'permissions_list' => new sfValidatorDoctrineChoice(array('multiple' => true, 'model' => 'sfGuardPermission', 'required' => false)),


    Try to add this lines on your file.
    I have installed the newest version too. When you run symfony doctrine:build --all-classes it seems that model does not care about the relation.
    So it's not a sfDoctrineGuard problem or the sfDoctrineGuard schema is wrong.
    Have you 'sf_guard_user_group' & 'sf_guard_user_permission' tables on your database?

  • avatar
    Last edited:
    01/28/11
    11:43am
    Lawrence Krubner says:

    I ran:

    ./symfony doctrine:clean-model-files

    ./symfony cc

    Check out the screenshot I'm uploading!

    I've still got the sfDoctrineGuardUser plugin installed, but now all the classes that start with a lower case "s" are considered to be "not in use" and are discarded!

    attachment image expert uploaded image

  • avatar
    Last edited:
    01/28/11
    11:44am
    Lawrence Krubner says:

    Check out the screen shot I just uploaded when I responded to Loban, below.

    I've still got the sfDoctrineGuardUser plugin installed, but now all the classes that start with a lower case "s" are considered to be "not in use" and are discarded!

    I end up with a lot of classes that start with an UPPER CASE "s". These are not usable.

  • avatar
    Last edited:
    01/28/11
    11:52am
    Lawrence Krubner says:

    Check out this screen shot. I run:

    find /home/lkrubner/dev/tastingnotes -name *schema.yml

    I only see the schema files that I expect to see.

    attachment image expert uploaded image

  • avatar
    Last edited:
    01/28/11
    11:53am
    Lawrence Krubner says:

    I just responded to José Nahuel Cuesta Luengo by posting a screenshot of what schemas I have. I see none that are misplaced, though the software acts as if some are misplaced.

  • avatar
    Last edited:
    01/28/11
    12:17pm
    Lawrence Krubner says:

    Sure enough, for some reason I copied the sfDoctrineGuard schema to the projects main schema.yml file. That should have been what caused the problem. However, I deleted it and the problem remains.

    After I deleted the sfGuardUser info from schema yml I ran these commands:

    ./symfony doctrine:build --model --forms --filters

    ./symfony cc


    Surprisingly, I still got the same error:

    Fatal error: Call to a member function setLabel() on a non-object in /home/lkrubner/dev/tastingnotes/plugins/sfDoctrineGuardPlugin/lib/form/doctrine/base/BasesfGuardUserAdminForm.class.php on line 28


    So I did:

    rm lib/form/doctrine/base/*

    rm -rf lib/form/doctrine/sfDoctrineGuardPlugin/*

    ./symfony doctrine:build --model --forms --filters

    ./symfony cc


    The problem remained. So I tried this:

    ./symfony doctrine:clean-model-files


    This gets weird. Look at the screen shot that I just uploaded. Symfony now felt that all of the sfGuardUser classes (with a small "s") were not in use. And yet it must have just generated them, because I'd just deleted all of their bases classes!

    attachment image expert uploaded image

  • avatar
    Last edited:
    01/28/11
    12:21pm
    Lawrence Krubner says:

    Interesting grep output too. This is after I ran "cc":



    lkrubner@webdev:~/dev/tastingnotes$ grep -R sfGuardUserPermission *
    grep: apps/tastingnotes/modules/note/templates/.#_form.php: No such file or directory
    cache/tastingnotes/dev/config/config_autoload.yml.php: 'pluginsfguarduserpermission' => '/home/lkrubner/dev/tastingnotes/plugins/sfDoctrineGuardPlugin/lib/model/doctrine/PluginsfGuardUserPermission.class.php',
    cache/tastingnotes/dev/config/config_autoload.yml.php: 'pluginsfguarduserpermissiontable' => '/home/lkrubner/dev/tastingnotes/plugins/sfDoctrineGuardPlugin/lib/model/doctrine/PluginsfGuardUserPermissionTable.class.php',

  • avatar
    Last edited:
    01/28/11
    1:37pm
    Lawrence Krubner says:

    About this:

    2. Remove data/sql/*.sql


    I'm not doing anything to load data.

  • avatar
    Last edited:
    01/28/11
    7:14pm
    José Nahuel Cuesta Luengo says:

    That's just fine, but I meant that you grep it through the files so that you are completely sure that no sfGuard* model schema info is misplaced or repeated. More so given the fact that you've got a lot of schema files.

  • avatar
    Last edited:
    01/28/11
    11:09pm
    Loban Rahman says:

    Man this is a huge mess. :-)

    Lets try this:

    Uninstall the sfDoctrineGuardPlugin. As in remove the plugin files.
    Run symfony clean-model-files.
    Run symfony cc.
    Check to see if there are any guard files left anywhere, there should be absolutely none.
    Hand remove if any left.
    Run symfony build models, forms, filters.
    Check to see if there are any guard files anywhere, there MUST be none.

    Now that we are sure that all remnants of guard is gone, reinstall the plugin, cc, build models forms, filters, and see if things are dandy.

  • avatar
    Last edited:
    01/29/11
    7:53am
    José Nahuel Cuesta Luengo says:

    Missed something: use grep -Ri so it's case-insensitive.. Remember you're having some odd behavior with lower and uppercase model files...

  • avatar
    Last edited:
    01/29/11
    4:37pm
    Jakub Zalas says:

    I once had issues with temporary schema generated by doctrine in /tmp (like /tmp/doctrine_schema_29265.yml). Doctrine couldn't overwrite existing file and used its previous version. Cleaning up solved the issue (rm /tmp/doctrine*.yml). I don't think it's exactly your problem but it's worth to mention.

    Your project behaves like you've changed guard's schema. Of course you didn't do it. You also didn't duplicate it. Might be environment problem. I'd try to build your model on different machine to make sure it's not a problem.

  • avatar
    Last edited:
    01/29/11
    4:41pm
    Jakub Zalas says:

    Another thing you could try is removing all your schema files but guard's and see if it builds correctly. If it builds than next thing is finding out which schema causes troubles.

  • avatar
    Last edited:
    01/31/11
    12:31pm
    Lawrence Krubner says:

    Thank you for that. Some odd combination of the last several commands seems to have allowed some progress. I ran all of these commands many, many times, in different orders:

    find . -name *SfGuard*.php | xargs rm

    ./symfony doctrine:clean-model-files
    ./symfony cc

    ./symfony doctrine:build—model—forms—filters

    ./symfony cc


    Suddenly my project started working, though I'm not sure why. I still face a problem though, as I've committed my changes to Subversion, yet my co-worker is unable to get his local version of the project working. After a few attempts, he decided to delete everything he had on his computer and then do a fresh checkout from Subversion, then rebuild the models and then clear cache - and he still gets the same error, even though it is gone from the local copy I have on my machine. When he runs "./symfony doctrine:build --model --forms --filters" Symfony generates SfGuard classes with an uppercase "S", and this wrecks the project. We can not figure out where the schema info might be that is allowing this "S" to persist, especially since it is gone from my machine and I've committed all changes and he did a clean checkout. I'm thinking there is some cache issue that is not being dealt with by "symfony cc". We do not keep the cache in Subversion, of course.

  • avatar
    Last edited:
    01/31/11
    12:32pm
    Lawrence Krubner says:

    That could be it. We will try that.

    Some odd combination of the last several commands seems to have allowed some progress. I ran all of these commands many, many times, in different orders:

    find . -name *SfGuard*.php | xargs rm

    ./symfony doctrine:clean-model-files
    ./symfony cc

    ./symfony doctrine:build—model—forms—filters

    ./symfony cc


    Suddenly my project started working, though I'm not sure why. I still face a problem though, as I've committed my changes to Subversion, yet my co-worker is unable to get his local version of the project working. After a few attempts, he decided to delete everything he had on his computer and then do a fresh checkout from Subversion, then rebuild the models and then clear cache - and he still gets the same error, even though it is gone from the local copy I have on my machine. When he runs "./symfony doctrine:build --model --forms --filters" Symfony generates SfGuard classes with an uppercase "S", and this wrecks the project. We can not figure out where the schema info might be that is allowing this "S" to persist, especially since it is gone from my machine and I've committed all changes and he did a clean checkout. I'm thinking there is some cache issue that is not being dealt with by "symfony cc". We do not keep the cache in Subversion, of course.

This question has expired.





Current status of this question: Completed



Warning: Please do not give out any FTP or ssh credentials to anyone, unless you trust them completely. Giving out login details is dangerous.

If the asker does not get an answer then they have 10 days to request a refund.