Fatal Error after upgrade from 1.4.19 to 1.5.28

[robin.hair]

When I try to run update.php it successfully loads the initial page (which tells me 'Gallery is currently offline - check back soon'), but when I try to click login I get a white screen with 'Fatal Error'.  Is the 'offline' status somehow preventing update.php running?

My 1.4.19 install was successfully running for some years, and as far as I remember it wasn't fiddled about with, just a virgin install with no plugins.  Having read the upgrade instructions I look these steps:

Backed everything up
Set the gallery to offline
Downloaded and expanded cpg1.5.28.zip
Copied the files over the top of 1.4.19 (except the Albums directory, and anycontent.php)
Ran http://hrca.net/photogallery/update.php

I assume the following error is systematic of the fact update.php hasn't actually been run?
From ../logs/database.log.php

2014-05-02 09:08:18 - While executing query '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 cpg_usergroups WHERE group_id in (3)' in bridge/udb_base.inc.php on line 323 the following error was encountered:
Unknown column 'access_level' in 'field list'

Assistance in running update.php would be much appreciated.
Thanks
Robin

[phill104]

Did you have bridging enabled previously? Did you have any plugins installed previously? If so please disable the bridge and all plugins. This can be done in phpmyadmin if you know what you are doing (there are plenty of threads detailing how).

[Αndré]

Check if your MySQL user has permission to ALTER tables. If you don't know how, please read this post and that corresponding post.

[robin.hair]

My cpg_usergroups table doesn't have an 'access_level' row, should I add one (is it normal to have to dive into SQL during a routine upgrade?).

My cpg_plugin table is empty and cpg_bridge has these 27 rows:

-- Dumping data for table `cpg_bridge`
--

INSERT INTO `cpg_bridge` (`name`, `value`) VALUES
('short_name', ''),
('license_number', ''),
('db_database_name', ''),
('db_hostname', ''),
('db_username', ''),
('db_password', ''),
('full_forum_url', ''),
('relative_path_of_forum_from_webroot', ''),
('relative_path_to_config_file', ''),
('logout_flag', ''),
('use_post_based_groups', ''),
('cookie_prefix', ''),
('table_prefix', ''),
('user_table', ''),
('session_table', ''),
('group_table', ''),
('group_relation_table', ''),
('group_mapping_table', ''),
('use_standard_groups', '1'),
('validating_group', ''),
('guest_group', ''),
('member_group', ''),
('admin_group', ''),
('banned_group', ''),
('global_moderators_group', ''),
('recovery_logon_failures', '0'),
('recovery_logon_timestamp', '');

[robin.hair]

.... further to my last post, just looked at cpg_config and it doesn't have a 'bridge_enable' row.

[gmc]

My cpg_usergroups table doesn't have an 'access_level' row, should I add one (is it normal to have to dive into SQL during a routine upgrade?).

No - it's not normal...
Missing fields are signs that update.php did not run properly.

As Andre indicated below:

Check if your MySQL user has permission to ALTER tables. If you don't know how, please read this post and that corresponding post.

(links to posts are active in his entry below)
ALTER authority is only needed at upgrade time to make any table changes introduced since your last upgrade.
It is very comprehensive - as we never know what version you are coming from - as a result many statements reply 'already done'.

The script cannot currently tell the difference between truly already done - and an authorization failure...

[robin.hair]

I've now manually added this row:
ALTER TABLE cpg_usergroups ADD access_level tinyint(4) NOT NULL default '3';
but I still get the 'Fatal error' when I try to login.

I also tried running sql/update.sql as per another forum thread, but hit errors.  Was that the correct thing to have done?

[Αndré]

Please follow the links in my first reply to understand/find out what goes wrong and how it can be fixed. I haven't checked the database changes, but there are probably more than one table alteration. So I recommend to fix the MySQL permissions and then run the upgrade script again.

[robin.hair]

I'm logged into phpmyadmin with the same database user as defined in coppermine, and I was able to alter the sql table with the command:
ALTER TABLE cpg_usergroups ADD access_level tinyint(4) NOT NULL default '3';
I assume this means the Update.php script would also have the 'alter' permissions?

I'm unsure what other MySQL permissions I need to fix.  Could you kindly detail exactly what I need to check or fix next, as it wasn't clear from reading the referenced other posts.

Thanks
Robin

[Αndré]

From the first link:

Please run update.php with the parameter debug:

update.php?debug

This will show you additional information below each command. What exactly is printed below

ALTER TABLE CPG_usergroups ADD access_level tinyint(4) NOT NULL default '3';

?

As you already executed that query via phpMyAdmin successfully, either undo that change (i.e. delete the access_level column) or search for the next ALTER query.

[robin.hair]

I've dropped the access_level row, and run with ?debug and I see this in the logs/basebase.log.php

2014-05-02 16:00:07 - While executing query 'SELECT MAX(group_quota) AS disk_max, MIN(group_quota).....
in bridge/udb_base.inc.php on line 323 the following error was encountered:
Unknown column 'access_level' in 'field list'

Should I be looking elsewhere for other more detailed 'debug' output?

Thanks for helping me here, as you can imagine I have little experience with Coppermine and other such software!
Robin

[robin.hair]

...I should have added, I still got the fatal error message, but nothing after it:
Fatal error :

If you try running my update.php then hopefully you'll see nothing much happens, it loads the initial screen (doesn't appear to have done any updates), then when I click any of the menu items (e.g. Login) I get the fatal error:

http://hrca.net/photogallery/update.php?debug

[gmc]

For a Fatal Error, the debug for Coppermine is set in the config (or database) - not in the URL...
http://documentation.coppermine-gallery.net/en/errors.htm#errors_fatal

Debug in the url gives more info during update.PHP for specific commands.... But not for a Fatal Error.

Since you are upgrading across several years of releases - I'm sure there are multiple missing fields that have been added...
All will be handled by update.php if it is run with the proper permissions.

Have you validated the permissions as André requested??
He provided links with info related to that...

(edited to clarify the different 'debug's)

[gmc]

OK... there is a disconnect here... and I think I found it.

From original post:

When I try to run update.php it successfully loads the initial page (which tells me 'Gallery is currently offline - check back soon'), but when I try to click login I get a white screen with 'Fatal Error'.  Is the 'offline' status somehow preventing update.php running?

Yes... the gallery being offline is preventing update.php from running (oops!).... and the missing field is preventing you from logging in... SO you have never gotten to the point of actually having update/php execute the required SQL to update your tables...

Since update.php is clearly maintenance - it should be allowed when the gallery is offline.

A few options:
Update includes/init.inc.php. 
Find: (at the bottom)

Code Select Expand


if (!USER_IS_ADMIN && $CONFIG['offline'] && !strstr($CPG_PHP_SELF, 'login')) {

and replace with:

Code Select Expand


if (!USER_IS_ADMIN && $CONFIG['offline'] && !strstr($CPG_PHP_SELF, 'login') && !defined('UPDATE_PHP')) {

This will allow execution of update.php (it defines constant 'UPDATE_PHP') even if the gallery is offline.
(This should be included as a 'bug fix' in my opinion...)

Other workarounds:
Set gallery online - will need to be done with a tool like phpMyAdmin as you can't current;y login...
The record to update is in cpg_config with a name of 'offline' - set value to '0'.

Code Select Expand


UPDATE `cpg_config` SET `value` = '0' WHERE `name` = 'offline';


Use the SKIP_AUTHENTICATION flag in update.php...
Uncomment the first of two lines below: (near the top)

Code Select Expand


// define('SKIP_AUTHENTICATION', true);
// If you don't remember the admin account data you're prompted for when running this file in your browser, umcomment the line above by removing the two slashes in front of it, upload that file to your webserver, run it in your browser. After successfully having run it, remember to restore the two slashes you removed and replace the "unsecure" version on your webserver with the "secure" version (the one that contains the double slashes).

which will bypass checks for authentication (and offline status).  Be sure to undo this once complete.

[robin.hair]

Many thanks Greg for rereading my earlier posts.  I used your third option of bypassing the authentication and offline status checks and the installation is now updated successfully .  It seemed like a natural thing to set the Gallery Off-line, so as users wouldn't receive errors, but that was clearly my downfall!

Thanks
again
Robin

[Αndré]

Fixed in SVN revision 8692.