- Welcome to coppermine-gallery.com/forum.
Recent posts
#51
cpg1.6 miscellaneous / Re: Unable to access the ADMIN...
Last post by Legacies - June 04, 2026, 01:06:45 PMHi Ron4Mac,
We appreciate your answer.
We do not run any plugins and have checked AI for solutions,
We have been running this installation of Coppermine for many-many years without any problems, so we are not sure why this is happening now.
We even tried to run a backup, but it would not load properly, so it seems like something got corrupted.
It seems like our only choice now is to either compare every file in the corrupted site to the files in a brand new working installation----or----- make a backup of our database through our cPanel and use that backup to populate a new installation.
Both of these operations will be time consuming, so we were hoping someone here had other suggestions
Thanks
We appreciate your answer.
We do not run any plugins and have checked AI for solutions,
We have been running this installation of Coppermine for many-many years without any problems, so we are not sure why this is happening now.
We even tried to run a backup, but it would not load properly, so it seems like something got corrupted.
It seems like our only choice now is to either compare every file in the corrupted site to the files in a brand new working installation----or----- make a backup of our database through our cPanel and use that backup to populate a new installation.
Both of these operations will be time consuming, so we were hoping someone here had other suggestions
Thanks
#52
cpg1.6 miscellaneous / Re: Unable to access the ADMIN...
Last post by ron4mac - June 04, 2026, 03:35:20 AMThe problem that you are having would seem to be stemming from some system configuration issue. If you search various AI platforms (Gemini, ChatGpt, Claude) for your failure message, you will likely find methods to try for resolution. Are you running a bunch of plugins on the problem instance? I suppose some plugin could be causing the problem. Disable all your plugins to see if there is any change.
#53
cpg1.6 miscellaneous / Unable to access the ADMIN TOO...
Last post by Legacies - June 03, 2026, 08:16:16 PM We are dealing with an issue on Coppermine 1.6.29.
We recently moved our entire cPanel to a new server and updated Coppermine after the move.
Now, we are unable to access the "Admin Tools" area.
Multiple admins are able to upload images and perform other duties, but no one can access the Admin Tools.
We are getting the following error, "PHP Request Shutdown: Use of mbstring.http_input is deprecated File: Unknown - Line: 0"
We looked through the htaccess and php.ini and could not find any references to the mbstring. We also ran a version check and found no errors.
We are using php 8.5 and tried moving it back to 8.0 to no avial.
We also installed a new program from scratch, on another cPanel that is using the same server and php. The new install worked fine.
So, we are perplexed as to what additional steps we can take to find the problem. Any suggestions would be greatly appreciate, however we would need step by step directions as we are a non-profit entity and none of our volunteers are trained in programming.
Thank you very much for any assistance.
We recently moved our entire cPanel to a new server and updated Coppermine after the move.
Now, we are unable to access the "Admin Tools" area.
Multiple admins are able to upload images and perform other duties, but no one can access the Admin Tools.
We are getting the following error, "PHP Request Shutdown: Use of mbstring.http_input is deprecated File: Unknown - Line: 0"
We looked through the htaccess and php.ini and could not find any references to the mbstring. We also ran a version check and found no errors.
We are using php 8.5 and tried moving it back to 8.0 to no avial.
We also installed a new program from scratch, on another cPanel that is using the same server and php. The new install worked fine.
So, we are perplexed as to what additional steps we can take to find the problem. Any suggestions would be greatly appreciate, however we would need step by step directions as we are a non-profit entity and none of our volunteers are trained in programming.
Thank you very much for any assistance.
#54
cpg1.6 permissions / Re: Visibility in albums: sugg...
Last post by andresf - May 07, 2026, 09:57:24 PMThank you, I'll do it that way.
#55
cpg1.6 permissions / Re: Visibility in albums: sugg...
Last post by ron4mac - May 07, 2026, 04:41:46 PMYou can make code contributions (and submit issues) at Github. Fork the repository, make your changes and submit a pull request.
#56
cpg1.6 permissions / Visibility in albums: suggesti...
Last post by andresf - May 06, 2026, 11:44:05 PMHello:
This post should better go at the "Modifications/Add-Ons/Hacks" subforum but I'm not allowed to post there.
As you know, CPG albums have a property (the "visibility" field, type INT) that allows you to limit who can see each one. If this field is less than 10,000 (this number is a constant assigned to FIRST_USER_CAT), it indicates the ID of the group that has permission to view it. If it's greater than 10,000, it indicates the ID of the user with permission (uid = Visibility - 10,000). And if it's 0, the album is public to everyone. All of this is explained in the documentation.
The way CPG implements this property when displaying album thumbnails is filtering at the "picture" level. I mean that CPG creates a WHERE clause that applies a filter to the pictures (the thumbnails you see), discarding those that belong to an album with permissions that the current user doesn't have access to. The code of the WHERE sentence is implemented in the get_private_album_set function (functions.inc.php), and then this sentence is used by all the SQL querys that select the thumbnails (get_pic_data function in functions.inc.php).
But this filter doesn't apply to "linked pictures" (linked via the "keywords" field), so these pictures will still appear for everybody although the album has a visibility restriction. Obviously, if an album contains only owned images (uploaded directly to it) and we apply visibility permissions to the album, no pictures will appear for unauthorized users. In my opinion, albums with "visibility restriction" should never show any picture (owned nor linked).
Certain that CPG does, when displaying album lists, is to "hide the link" to albums with no permissions for the current user, but there's still the possibility to watch them, by example writting the link in the address bar of the navigator, what I consider a "back door" to access to these restricted albums.
To prevent this, my suggestion is to implement an "album level" restriction. I implemented the following code, that directly denies permissions to a single album that the current user should not see. Notice that it only applies when watching an specific album, it has no sense when watching category thumbnails. This code is inserted at the beginning of the `get_pic_data` function (functions.inc.php):
Hoping this may be useful for somebody ...
Regards
This post should better go at the "Modifications/Add-Ons/Hacks" subforum but I'm not allowed to post there.
As you know, CPG albums have a property (the "visibility" field, type INT) that allows you to limit who can see each one. If this field is less than 10,000 (this number is a constant assigned to FIRST_USER_CAT), it indicates the ID of the group that has permission to view it. If it's greater than 10,000, it indicates the ID of the user with permission (uid = Visibility - 10,000). And if it's 0, the album is public to everyone. All of this is explained in the documentation.
The way CPG implements this property when displaying album thumbnails is filtering at the "picture" level. I mean that CPG creates a WHERE clause that applies a filter to the pictures (the thumbnails you see), discarding those that belong to an album with permissions that the current user doesn't have access to. The code of the WHERE sentence is implemented in the get_private_album_set function (functions.inc.php), and then this sentence is used by all the SQL querys that select the thumbnails (get_pic_data function in functions.inc.php).
But this filter doesn't apply to "linked pictures" (linked via the "keywords" field), so these pictures will still appear for everybody although the album has a visibility restriction. Obviously, if an album contains only owned images (uploaded directly to it) and we apply visibility permissions to the album, no pictures will appear for unauthorized users. In my opinion, albums with "visibility restriction" should never show any picture (owned nor linked).
Certain that CPG does, when displaying album lists, is to "hide the link" to albums with no permissions for the current user, but there's still the possibility to watch them, by example writting the link in the address bar of the navigator, what I consider a "back door" to access to these restricted albums.
To prevent this, my suggestion is to implement an "album level" restriction. I implemented the following code, that directly denies permissions to a single album that the current user should not see. Notice that it only applies when watching an specific album, it has no sense when watching category thumbnails. This code is inserted at the beginning of the `get_pic_data` function (functions.inc.php):
Code Select
// if we're viewing an specific album, the variable "$alb_id" will contain its Identificator; otherwise it will contain -1 and we do not apply any restriction
$alb_id = is_numeric($album) ? $album : ($cat < 0 ? -$cat : -1);
if ($alb_id > 0 && !GALLERY_ADMIN_MODE) {
$result = cpg_db_query("SELECT visibility FROM {$CONFIG['TABLE_ALBUMS']} WHERE aid = {$alb_id}");
list($visibility) = $result->fetchRow(true);
if ($visibility != 0) {
if ((($visibility > FIRST_USER_CAT) && ($visibility - FIRST_USER_CAT != USER_ID)) OR
(($visibility < FIRST_USER_CAT) && !in_array($visibility, $USER_DATA['groups']))) {
cpg_die(ERROR, $lang_errors['perm_denied'], __FILE__, __LINE__);
}
}
}
Hoping this may be useful for somebody ...
Regards
#57
cpg1.6 install / Re: Possible bug creating hit_...
Last post by andresf - April 30, 2026, 02:50:57 PMWell, it doesn't really take up much more space; the VARCHAR type adjusts the space to the entered data.
#58
cpg1.6 install / Re: Possible bug creating hit_...
Last post by andresf - April 30, 2026, 02:33:15 PMThanks, ron4mac, for your reply. Indeed, it's not really a "bug" that affects the gallery's functionality.
I realized this when I saw that the "hit_stats" table is possibly the one that grows the most and takes up the most space in the database, and that field ('pid') declared as VARCHAR(100) contributes to it taking up even more space.
I realized this when I saw that the "hit_stats" table is possibly the one that grows the most and takes up the most space in the database, and that field ('pid') declared as VARCHAR(100) contributes to it taking up even more space.
#59
cpg1.6 install / Re: Possible bug creating hit_...
Last post by ron4mac - April 30, 2026, 02:35:12 AMThank you for posting your discovery. Technically, you are correct. But it has been mis-declared like that for over 18 years without issue.
#60
cpg1.6 install / Possible bug creating hit_stat...
Last post by andresf - April 29, 2026, 09:44:51 PMHello:
My name is Andres and this is my first message in this forum. I want to thank André for his help with some problems I had registering.
I discovered the Coppermine Gallery a while ago and have some experience programming it. I hope I can contribute something to improve this tool.
In this post, I wanted to warn about a possible bug in the sql\schema.sql file. When the "hit_stats" table is created, the `pid` field should be of type INT, according to the documentation, not VARCHAR(100). This can be found on line 196.
Regards
My name is Andres and this is my first message in this forum. I want to thank André for his help with some problems I had registering.
I discovered the Coppermine Gallery a while ago and have some experience programming it. I hope I can contribute something to improve this tool.
In this post, I wanted to warn about a possible bug in the sql\schema.sql file. When the "hit_stats" table is created, the `pid` field should be of type INT, according to the documentation, not VARCHAR(100). This can be found on line 196.
Regards