- Welcome to coppermine-gallery.com/forum.
Recent posts
#1
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.
#2
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.
#3
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
#4
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.
#5
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.
#6
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.
#7
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
#8
cpg1.6 upload / Re: Upload bug after moving fr...
Last post by ron4mac - April 10, 2026, 05:07:25 PMI did a fresh install of Ubuntu with Nginx as the web server and had no issues running CPG 1.6.28 on it. So there must be some anomaly with your setup that is causing the abnormal response from the server during upload. That said, it's a kind of trivial abnormality that shouldn't cause the upload progress to halt. I will make a modification to CPG so, in the future, it will handle this abnormal situation more gracefully.
#9
cpg1.6 upload / Re: Upload bug after moving fr...
Last post by screamqueen - April 10, 2026, 07:43:41 AMThank you so much, I'm really happy everything is working again and uploads are functioning properly. I really appreciate the fix you made, everything looks perfect now.
#10
cpg1.6 upload / Re: Upload bug after moving fr...
Last post by ron4mac - April 09, 2026, 01:51:02 PMYour Nginx server is behaving in a way that must not be totally normal. CPG upload has functioned without problem on many Nginx servers. I've made a modification to CPG upload on your galleries to get around the issue (clear your browser cache). When I have a bit more time, I'll setup a fresh ubuntu/nginx server to explore the possible root issues more deeply.