Fix 2 problems with profile page - missing user_profile data and a php notice

[flar]

The profile page was not showing the user_profile data for users.  There was also a php notice with that page.

The php notice can be fixed by putting user_name in quotes on one line:

Find this line in profile.php (near 379):

Code Select Expand


        $result = cpg_db_query("SELECT pid FROM {$CONFIG['TABLE_PICTURES']} WHERE owner_name = '".addslashes($user_data[user_name])."'");

and add the quotes around 'user_name':

Code Select Expand


        $result = cpg_db_query("SELECT pid FROM {$CONFIG['TABLE_PICTURES']} WHERE owner_name = '".addslashes($user_data['user_name'])."'");


[Edit - NOTE: the following modification is overkill and obsoleted by a fix to udb_base.inc.php somewhere between 1.4.2 and 1.4.5 to add a "*" to the SQL query in the default implementation of get_user_infos (read later posts for more info)]

The problem with user_profile data not being added to the web page is due to the fact that the user data query is done via the bridging code and the coppermine default bridge relies on the generic code in the base class that only fetches some of the fields.  I copied the get_user_infos function from the udb_base code to the coppermine file and enhanced its sql query to match the query in the old pre-bridge code in profile.php as follows:

Add the following function to bridge/coppermine.inc.php (I chose to add it just after the edit_profile function - circa line 360 or so):

Code Select Expand


        // Get user information
        function get_user_infos($uid)
        {
            global $lang_register_php, $CONFIG;

            $sql = "SELECT user_name, user_email, user_group, UNIX_TIMESTAMP(user_regdate) as user_regdate, group_name, "
                 . "user_profile1, user_profile2, user_profile3, user_profile4, user_profile5, user_profile6 "
                 . "FROM {$CONFIG['TABLE_USERS']} AS u "
                 . "INNER JOIN {$CONFIG['TABLE_USERGROUPS']} AS g ON user_group = group_id "
                 . "WHERE user_id ='$uid'";

            $result = cpg_db_query($sql, $this->link_id);

            if (!mysql_num_rows($result)) cpg_die(ERROR, $lang_register_php['err_unk_user'], __FILE__, __LINE__);

            $user_data = mysql_fetch_array($result);
            mysql_free_result($result);

            return $user_data;
        }



[Stramm]

no need to add that function cause it already exists in the class core_udb. The class coppermine_udb just extends core_udb
You'd add redundant code making it harder to maintain the project

If your gallery doesn't show the profile fields there's prolly something else fishy
Just to be sure I'd tried with 1.4.3, 1.4.5 and my modded 1.4.5... all smooth


the notice, yes, thanks for that

[Nibbler]

The generic code in udb_base selects * from the user table, that should get the user_profile fields already.

[flar]

Sorry about that, I was working from 1.4.2 which did not have the *, but I see it is there in 1.4.5.  I had looked at the 1.4.5 source base before I posted this, but the '*' was so small that I missed the change by visual inspection.

I've been avoiding upgrading to 1.4.5 so far because there is no easy "one click upgrade" from my provider and I don't have shell access to the account to do the upgrade manually, but maybe it's time I figure out how to do the upgrade via ftp...   :-\

[Stramm]

you don't need shell access for the upgrade

[flar]

you don't need shell access for the upgrade

Thanks, I realize that.  It's just a lot less, um, "fun" via ftp than it would be with a shell account, but that's my problem for going with a bargain basement provider... 

But all of that is neither here nor there.  Upgrading or not, I'll try to be more careful about making sure my future contributions aren't obsoleted by an upgrade.

At this point I'd like to point out a difference between the pre-bridge code that is commented out in profile.php (upon which I based my coppermine implementation of get_user_infos) and the code that you reference in udb_base.inc.php as I'm not sure if this is a "bug" or a "feature":

The old code (profile.php, line 349) used an SQL query that explicitly included 'group_name' as one of the query fields.  The code in core_udb->get_user_infos has a line (udb_base.inc.php, line 401) that sets the value of this array entry to an empty string after the query returns.  Is this an intentional decision to exclude the group name from the query results (and therefore also from the profile information displayed), or is this an artifact of core_udb->get_user_infos stomping on the value in an attempt to make sure that the array entry has a value?

Fixing it would be simple - simply put an if (!isset($user_data['group_name'])) {...} around the line...

[Nibbler]

Issues fixed in svn.