nuke_users

New Member Joined: Oct 08, 2007 Posts: 2

Hello, I'm new to PHP-Nuke but I must implement some modules.

The PHP-Nuke copy I'm extending uses CNB Your Account instead of the classic Your Account.

For some reason I need to add fields to the nuke_users table.

I've a custom table nuke_teams and I need to relate each user to his team, so I created in nuke_users a field nuke_team_id related to the team_id inside the nuke_teams table.

Someone has told me I should not add fields this way (even if there's a practical tutorial here: http://www.westernstudios.net/tut-create-new-field.ws: don't know if this applies to CNB Your Account too...)... but, instead, I should use CNB Your Account.

The fact is that I can't understand the inner workings of CNB: what does this do? If I add a field, is this field a sort of alias of a field inside the nuke_users table? Or what? How can I query it? Is there any reference guide?

Thanks!

Posted: Mon Oct 08, 2007 1:06 pm

Problem is that if you modify the nuke users table that way you are likely to cause existing programs to malfunction. A lot of programs update the table using a list of values where each value corresponds implicitly to one field in the table. So if you add fields those programs are not going to know about it and they will generate errors.

Better to create a new table (like team_id) as you did and then have userid and team_id related within it. You can then take the userid's and go against the users table and find out the rest of the information you need about each user without modifying the core table.

The alternative is to go thru all the code in Nuke and modify every update statement for your new table definition. And even then you are out of luck when the next set of updates comes thru.

I don't know about CNB, they may have some facility to add fields and keep the SQL statements up to date.

Posted: Tue Oct 09, 2007 1:03 am

fkelly wrote:

Better to create a new table (like team_id) as you did and then have userid and team_id related within it. You can then take the userid's and go against the users table and find out the rest of the information you need about each user without modifying the core table.

This is a good idea, thanks! Smile