Forums / General / Help: new users are missing $current_user.contentobject

Help: new users are missing $current_user.contentobject

Next topic

Author	Message
Brendan Pike	Tuesday 22 November 2005 9:49:08 pm I've done a test upgrade from 3.6.1 to 3.6.4 and discovered that new users don't seem to get contentobject. When I compare the output of an old and new user with {$current_user\|attribute(show)} new users only have NULL next to the contentobject attribute but old users show 40 or so attribute types. Out as follows: Attribute Type Value contentobject_id string 1871 login string 'AABB' email string '[email protected]' password_hash string '94fdd5ea0478ce7d80b5ae3cbaf59d17' password_hash_type string 2 contentobject NULL groups array Array(0) has_stored_login boolean false original_password boolean false original_password_confirm boolean false roles array Array(0) role_id_list array Array(0) limited_assignment_value_list array Array(0) is_logged_in boolean true is_enabled boolean true last_visit integer 1132723161 What could be causing this, I did discover a newly added input in register.tpl <input class="button" type="hidden" name="UserID" value="{$content_attributes[0].contentobject_id}" /> Is there something similar I have missed in a template perhaps? bump www.dbinformatics.com.au We are always interested in hearing from experienced eZ PHP programmers and eZ template designers interested in contract work.
Brendan Pike	Wednesday 30 November 2005 6:09:30 pm Problem solved! I realise now why no one seemed able to offer any advice on this problem. To add a little more detail I was also experiencing odd behaviour like the user registration form would not enforce many required fields but only on the development site version which was identical in every way. It turned out that the mysql user class had somehow been corrupted, I still don't have a complete understanding, especially since I was using the same mysql user to access both the live database site and the development database copy, yet the live site worked fine and the development site did not. All permissions for each database was identical. So if you find similar strange behaviour I advise you to try a new database user, it could save you a lot of time and stress. www.dbinformatics.com.au We are always interested in hearing from experienced eZ PHP programmers and eZ template designers interested in contract work.

Author

Message

Tuesday 22 November 2005 9:49:08 pm

I've done a test upgrade from 3.6.1 to 3.6.4 and discovered that new users don't seem to get contentobject. When I compare the output of an old and new user with {$current_user|attribute(show)} new users only have NULL next to the contentobject attribute but old users show 40 or so attribute types.

Out as follows:

Attribute 	Type 	Value
contentobject_id 	string 	1871
login 	string 	'AABB'
email 	string 	'[email protected]'
password_hash 	string 	'94fdd5ea0478ce7d80b5ae3cbaf59d17'
password_hash_type 	string 	2
contentobject 	NULL 	
groups 	array 	Array(0)
has_stored_login 	boolean 	false
original_password 	boolean 	false
original_password_confirm 	boolean 	false
roles 	array 	Array(0)
role_id_list 	array 	Array(0)
limited_assignment_value_list 	array 	Array(0)
is_logged_in 	boolean 	true
is_enabled 	boolean 	true
last_visit 	integer 	1132723161

What could be causing this, I did discover a newly added input in register.tpl <input class="button" type="hidden" name="UserID" value="{$content_attributes[0].contentobject_id}" />

Is there something similar I have missed in a template perhaps?
*bump*

www.dbinformatics.com.au

We are always interested in hearing from experienced eZ PHP programmers and eZ template designers interested in contract work.

Brendan Pike

Wednesday 30 November 2005 6:09:30 pm

Problem solved! I realise now why no one seemed able to offer any advice on this problem.

To add a little more detail I was also experiencing odd behaviour like the user registration form would not enforce many required fields but only on the development site version which was identical in every way.

It turned out that the mysql user class had somehow been corrupted, I still don't have a complete understanding, especially since I was using the same mysql user to access both the live database site and the development database copy, yet the live site worked fine and the development site did not. All permissions for each database was identical.

So if you find similar strange behaviour I advise you to try a new database user, it could save you a lot of time and stress.

www.dbinformatics.com.au

We are always interested in hearing from experienced eZ PHP programmers and eZ template designers interested in contract work.