Issues after upgrading my SMF bridged install from 1.4.19 to 1.5.20

[CRCs Reality]

I have the following issue when trying to bridge coppermine and SMF forum (smf version 1.1.16)
No admin tools when bridged, multiple permission errors ('you do not have permission to access this page' errors for 'groups' , config , or most other admin functions)
Coppermine install: http://www.lionsbrooke.com/gallery/index.php
Bridging app install: http://www.lionsbrooke.com/
Coppermine version: cpg1.5.20
Bridging app version: SMF forum, version 1.1.16
Test user account: CR_test / password123
BridgeManager settings:
Bridge app URL:  http://www.lionsbrooke.com
Relative path to your bridge app's config file:  ../
Cookie name or prefix:  coppermine
Use bridge app custom groups?:  1

OK, this is a blog I manage for my mother to keep in touch with her friends..  Low traffic, low membership, but VERY important to her..
It's been up and running for years, but this week I upgraded coppermine from 1.4.19 to 1.5.20 (yeah, yeah, I know..  should have kept up-to-date)..  Now users cannot upload pictures at all..  I still can as an admin, but all admin controlls are gone, and if I try and go directly to a page (for example, http://www.lionsbrooke.com/gallery/versioncheck.php) I get an error stating that I do not have permission to access the page.

I have gone into bridge manager and broken / re-created the bridge..  When the bridge is broken my local coppermine admin account has full access, but once I bridge it the issues re-appear..

Any ideas? 

[Jeff Bailey]

Try some of the things failing at:
http://www.lionsbrooke.com/gallery/index.php?theme=curve
to return to your default theme:
http://www.lionsbrooke.com/gallery/index.php?theme=xxx

You are using an outdated theme. There is a classic theme available for 1.5.x if you want it.

Did you unbridge before upgrading?

[Jeff Bailey]

Forgot to mention you didn't provide any upload capabilities so there's no way for us to test that.
http://documentation.coppermine-gallery.net/en/upload_troubleshooting.htm?expand_all=1#upload_support_step-by-step

[CRCs Reality]

Should have mentioned (I've been working on this for hours)..  I tried other themes, even the 'classic' to see if it was theme related..  No change.

Also, prior to the upgrade, all posters had upload capabilities..  Shouldn't that capability have transferred to the upgraded version?

I did not un-bridge prior to the upgrade, didn't know I should have (should I have?!?!?)

The input is appreciated...

[Jeff Bailey]

I did not un-bridge prior to the upgrade, didn't know I should have (should I have?!?!?)

I don't believe it is in the documentation but it helps to avoid issues like this.

Have you run update.php?
Synced your groups?

Take a look at this:
http://forum.coppermine-gallery.net/index.php/topic,74048.msg356653.html#msg356653
and try some of the steps Joe outlines.

[CRCs Reality]

Yes, update.php completed without error..

When I try and sync the groups, I get the 'you do not have permission toaccess this page' error...

I DO have a full backup (pre upgrade) and can revert to the prior version if needed...  But I'm trying to understand what went wrong before I waste time (and a couple days of forum posts) before I revert to backup....

[Jeff Bailey]

Could you manually enable debug mode.
http://documentation.coppermine-gallery.net/en/errors.htm#errors_debug_mode_manual

[Jeff Bailey]

Is your forum actually at http://www.lionsbrooke.com/smf ?
and your gallery at http://www.lionsbrooke.com/smf/gallery ?

[CRCs Reality]

Is your forum actually at http://www.lionsbrooke.com/smf ?
and your gallery at http://www.lionsbrooke.com/smf/gallery ?

Yes, and Yes...

[CRCs Reality]

Could you manually enable debug mode.
http://documentation.coppermine-gallery.net/en/errors.htm#errors_debug_mode_manual

Done...
What should I look for?

[Jeff Bailey]

Check
[has_admin_access]

and it looks like your SMF cooke name is SMFCookie980 not coppermine

[CRCs Reality]

OK, with debug enabled when I go to a page that gives me the error, here's the debug output:
So, the big question is 'why' don't I have admin  .  .  .

Code Select Expand



USER:
------------------
Array
(
    [ID] => c7e81bfecdbf9695609a8533269aaa12
    [am] => 1
    [lang] => english
    [theme] => water_drop
)

==========================
USER DATA:
------------------
Array
(
    [user_id] => 0
    [user_name] => Guest
    [groups] => Array
        (
            [0] => 103
        )

    [group_quota] => 0
    [can_rate_pictures] => 0
    [can_send_ecards] => 0
    [can_post_comments] => 0
    [can_upload_pictures] => 0
    [can_create_albums] => 0
    [pub_upl_need_approval] => 1
    [priv_upl_need_approval] => 1
    [access_level] => 3
    [disk_max] => 0
    [disk_min] => 0
    [has_admin_access] => 0
    [group_name] => Moderator
    [can_create_public_albums] => 0
    [can_see_all_albums] => 0
    [group_id] => 103
    [allowed_albums] => Array
        (
        )

)

==========================
Queries:
------------------
Array
(
    [0] => SELECT name, value FROM cpg14x_config [include/init.inc.php:179] (0 ms)
    [1] => SELECT * FROM cpg14x_plugins ORDER BY priority [include/plugin_api.inc.php:52] (0 ms)
    [2] => SELECT name, value FROM cpg14x_bridge [include/functions.inc.php:4442] (0 ms)
    [3] => SELECT MAX(group_quota) AS disk_max, MIN(group_quota) AS disk_min, MAX(can_rate_pictures) AS can_rate_pictures, MAX(can_send_ecards) AS can_send_ecards, MAX(can_post_comments) AS can_post_comments, MAX(can_upload_pictures) AS can_upload_pictures, MAX(can_create_albums) AS can_create_albums, MAX(has_admin_access) AS has_admin_access, MAX(access_level) AS access_level, MIN(pub_upl_need_approval) AS pub_upl_need_approval, MIN( priv_upl_need_approval) AS  priv_upl_need_approval FROM cpg14x_usergroups WHERE group_id in (103) [bridge/udb_base.inc.php:323] (0 ms)
    [4] => SELECT group_name FROM cpg14x_usergroups WHERE group_id= 103 [bridge/udb_base.inc.php:327] (0 ms)
    [5] => SELECT COUNT(*) FROM cpg14x_categorymap WHERE group_id in (103) [bridge/udb_base.inc.php:340] (0 ms)
    [6] => SELECT aid FROM cpg14x_albums WHERE moderator_group IN (103) [include/init.inc.php:269] (0 ms)
    [7] => SELECT lang_id FROM cpg14x_languages WHERE enabled='YES' [include/init.inc.php:327] (0 ms)
    [8] => DELETE FROM cpg14x_banned WHERE expiry < '2012-08-21 03:11:14' [include/init.inc.php:441] (0 ms)
    [9] => SELECT null FROM cpg14x_banned WHERE ('71.206.202.207' LIKE ip_addr ) AND brute_force=0 LIMIT 1 [include/init.inc.php:457] (0 ms)
    [10] => SELECT aid FROM cpg14x_albums WHERE (1  AND visibility != 0 AND visibility != 10000 AND visibility NOT IN (103)) [include/functions.inc.php:976] (0 ms)
)

==========================
GET :
------------------
Array
(
)

==========================
POST :
------------------
Array
(
)

==========================
COOKIE :
------------------
Array
(
    [coppermine_data] => YTo0OntzOjI6IklEIjtzOjMyOiJjN2U4MWJmZWNkYmY5Njk1NjA5YTg1MzMyNjlhYWExMiI7czoyOiJhbSI7aToxO3M6NDoibGFuZyI7czo3OiJlbmdsaXNoIjtzOjU6InRoZW1lIjtzOjEwOiJ3YXRlcl9kcm9wIjt9
    [fb09a6802bcf17290eb6b7ce4236fc1b] => cfa7b8537287676ae25343a995dbfb35
)

==========================
               


[Jeff Bailey]

The problem ended up being the way SMF keeps track of user groups.
If the user is not created as the admin it gets a group id of 0 which doesn't exist, it has another column for additional groups that keeps track of the actual groups the user belongs to. CRCs Reality was in the admin group but Coppermine used group 0 as the primary and didn't recognize the additional groups.

I changed CRCs Reality's id_group to 1 and was granted admin access and was able to sync groups and reestablish upload privileges to the users.

Anyone that is more familiar with bridging know why this happened?

[CRCs Reality]

Solution tested and working!
Jeff, thanks so much, I was pulling my hair out on this one..  I appreciate the assistance.

[Jeff Bailey]

No problem and thank you for resolving your thread.