Hi there,

I am signed in under "". Why does var_dump(Yii::app()->user) keeps dumping this?:


  public 'allowAutoLogin' => boolean true

  public 'guestName' => string 'Guest' (length=5)

  public 'loginUrl' => 


      0 => string '/site/login' (length=11)

  public 'identityCookie' => null

  public 'authTimeout' => null

  public 'autoRenewCookie' => boolean false

  public 'autoUpdateFlash' => boolean true

  private '_keyPrefix' => string 'f8fc6cfefb53e67820930c48a32dffc6' (length=32)

  private '_access' => 



  public 'behaviors' => 



  private '_initialized' (CApplicationComponent) => boolean true

  private '_e' (CComponent) => null

  private '_m' (CComponent) => null

while var_dump(Yii::app()->user->name), as it is supposed to, displays

string '' (length=17)


that’s not what I asked about. And you shoulnd’t’ve moved it to the general php forums.

The question is why dumping Yii::app()->user always shows that I am signed in as a guest (and therefore it doesn’t display states, id and any other info whatsoever), that’s while I am authenticated as a registered user. On the other hand when I dump info about a specific property of Yii::app()->user it displays just what it is supposed to

Hi Dan,

When you are doing var_dump is actually displaying the structure of the object , in this case is CWebUser and when you access one property is displaying the default value of the property. If you look at the code of CWebUser, you will see that the object is initialized as ‘Guest’ and this is why var_dump displays it.

On the other hand, when you var_dump variables or arrays, they are displayed recursively and this is why you see its actual values. That is what actually Samdark was trying to say.



I am not sure how to do the +1 thing here

The following is for +1:

there is no such button for me

@Dan S.K.

You did not have that button as you where just registered and had less than 3 posts… so now that you have 4 posts… you will have even that + button ;)

I am a newbie to YII, so I’m probably showing some naivete here, but, what we expect var_dump to do is to show to current values of the USER instance variable. If I run the following:

user=new myUser();



I would expect the output to display the current state of the “user” variable. But, apparently, if the name property isn’t declared as a public variable, var_dump won’t show it (and the assignment above wouldn’t work either). I suppose if a property isn’t explicitly declared, then the var_dump() function will not show it as part of its output. If this is true, this raises some questions?

  1. what would you call this type of property (to distinguish it from the public properties that are declared)?

  2. how or where is this value being set?

  3. how would we dump the entire contents of this variable to the screen for inspection?

  4. why would you want to use a variable like this, rather than explicitly declaring it as part of the public interface so that the users of the class can easily find it and locate it without referring to some external documentation.

Thanks in advance for your help with this.

Check CWebUser::__set() and CWebUser::__get() and this

Thanks for pointing me in the right direction. This really was helpful. Below, I’ll try to clarify what I discovered following those links (especially the link on PHP: Overloading from the PHP manual).

This is probably very fundamental stuff in PHP, but I’ll attempt to list the reasons why one (the Yii Framework specifically) would use “dynamically created properties” vs. explicitly defined properties with getters and setters. If we can understand why, it helps in learning and using the language and framework more effectively.

I am brand new to PHP on YII, so I’m hoping someone will fill in the gaps and correct the mistakes here.

Reasons to use Dynamically Created Properties and Methods (what PHP calls “Overloading” but from a traditional sense it’s actually overriding (or interpreter hooks)):

You can make the property READ ONLY and still allow access to the property with ->, rather than with a Getter.

You can pass properties via an array, rather than having to use individual arguments for each setting.  PHP doesn't support named parameters, so the only way to pass the initial values to an object's constructor would be to specify values for all items (the ordering is important).

This might be why they call this Overloading.  It is a technique that allows for an overloading(in the traditional sense) workaround, in addition to named parameters.

Reasons not to do this: (This is directly copied from a post by theaceofthespade at gmail dot com in PHP: Overloading from the PHP manual, but he articulates my sentiments as well or better than I could have.)

A word of warning!  It may seem obvious, but remember, when deciding whether to use __get, __set, and __call as a way to access the data in your class (as opposed to hard-coding getters and setters), keep in mind that this will prevent any sort of autocomplete, highlighting, or documentation that your ide mite do.

Furthermore, it beyond personal preference when working with other people. Even without an ide, it can be much easier to go through and look at hard coded member and method definitions in code, than having to sift through code and piece together the method/member names that are assembled in __get and __set.

If you still decide to use __get and __set for everything in your class, be sure to include detailed comments and documenting, so that the people you are working with (or the people who inherit the code from you at a later date) don’t have to waste time interpreting your code just to be able to use it.

I’m still curious how dynamically created properties can be preferable to the alternative. But, maybe this is just something I need to accept and that I’ll get used to. Or, maybe it’s just a style or preference thing.

I got to thinking about this more and analyzed the __get and __set functions in YII’s CWebUser class. One big reason that Yii is using “dynamically created” properties (rather than explicitly declaring the property in the class definition), is because the actual values of the settings are being saved in the _SESSION Super Global variable. But, this could also have been done with explicitly defined setters for each property.

Does anyone else have any further insight on this?