Advanced search  

News:

CPG Release 1.6.26
Correct PHP8.2 issues with user and language managers.
Additional fixes for PHP 8.2
Correct PHP8 error with SMF 2.0 bridge.
Correct IPTC supplimental category parsing.
Download and info HERE

Pages: [1]   Go Down

Author Topic: Creating separate "delete" and "remove" functionalities  (Read 3616 times)

0 Members and 1 Guest are viewing this topic.

cgc0202

  • Coppermine frequent poster
  • ***
  • Offline Offline
  • Posts: 199
Creating separate "delete" and "remove" functionalities
« on: September 02, 2006, 06:14:15 pm »

Hi,

I use a CPG format where the photos are  placed outside of the CPG, i.e., not in the "albums" directory within a CPG.  This works, so this is not the issue here. I opted for this strategy because I have multiple galleries.  Decoupling the photos from each CPG has many advantages.  Among them, I can use the same photos in multiple galleries,  much more easily. The aforementioned strategy is different from "presenting" the same photo in multiple albums within the same photogallery.  In that latter case, I use the unique "keyword" for each album to present the same photo in multiple albums within the same photogallery.

There is one big problem when a photo is used in multiple PhotoGalleries.  There are times (and reasons) when I want to "remove" a photo from a PhotoGallery completely  -- not just move it around to another "album" -- so that it will not show in the random photos.  To my knowledge, this can be done only through the "delete" function -- but this will delete the photo in the central "pic" directory. I am unsure of this but I think it also the deletes or at least orphan the photodetails (description, comments, etc.)

Paver, GauGau and others have suggested an existing "mod" that modifies the "delete" option, so that it will "delete" the "derivative" images associated with a photo, i.e., mini, thumb and normal, but not the original photo.  I found this remedy a significant modification.  Nonetheless, even in the aforementioned there is  still a need to restore the derivate images, if the original photo is used in multiple galleries.

A better solution would be to decouple a "remove" option from the existing "delete" option.  As the proposed "remove" option  suggests, it will remove an image (and prevent its presentation) in an album of a photogallery -- but not delete the original photo (and derivative images) as well as other related information (image description, comments, etc.).  This new feature will be critical for multiple PhotoGalleries, but I know some uses also even in just a single PhotoGallery settings.

CGC
« Last Edit: October 12, 2006, 02:44:28 pm by Paver »
Logged

Paver

  • Dev Team member
  • Coppermine addict
  • ****
  • Country: us
  • Offline Offline
  • Gender: Male
  • Posts: 1609
  • Paul V.
Re: Creating separate "delete" and "remove" functionalities
« Reply #1 on: September 02, 2006, 08:59:53 pm »

I think I understand what you are suggesting, but I think "remove" is the wrong word.  If you want to keep the title, description, etc. of the photo, then it's still in the gallery database and so hasn't been removed.  What you want to do is merely "hide" or make "inactive" the photo, effectively making it a photo without a home album (but it still exists in the gallery since it is present in the gallery's database).

I could also understand removing the photo from the gallery (and the gallery's database, including the title, description, etc), but keeping the original photo along with the thumb and the normal images.  In that case, the photo is being removed from the gallery since it no longer exists in the gallery's database.

I ask mainly to clarify your feature request.

FYI: If you merely want to hide certain albums from the random meta-album, you can use this plugin.
Logged

cgc0202

  • Coppermine frequent poster
  • ***
  • Offline Offline
  • Posts: 199
Re: Creating separate "delete" and "remove" functionalities
« Reply #2 on: September 02, 2006, 10:24:02 pm »

Thanks Paver for responding very fast,

I ask mainly to clarify your feature request.

Yes, you did get a sense of what I was trying to explain.  I am not sure if "remove" is indeed the correct term to use.  Also, there is some slight shift in perspective that is needed.  I am referring to the functionality of the "photo database" in a multiple PhotoGalleries setup, not the single PhotoGallery for which the CPG has been designed for mainly.  I will explain this more in your respective responses.

I think I understand what you are suggesting, but I think "remove" is the wrong word.  If you want to keep the title, description, etc. of the photo, then it's still in the gallery database and so hasn't been removed.  What you want to do is merely "hide" or make "inactive" the photo, effectively making it a photo without a home album (but it still exists in the gallery since it is present in the gallery's database).

Yes, I want to keep both the title, description, etc. as well as the original photo and the derivative images, with the photos being most critical.  I will read more about the plugin you stated below.  However, even before I knew about the plugin, here is what I do to hide the photos I did not want to appear -- I create  private album(s), and hide them there.  This is most practical for photos that I wish to show only at specific months or dates of the year. Not the most elegant solution perhaps as the plugin you mentioned below, but the strategy hides the images and original from presentation in a PhotoGallery, without deleting the original photo and derivative images in the common pics directory.

Here is the difference. Note that in a multi PhotoGallery, the photos (and the derivative images) placed in the common pics directory may be shared by the various photogalleries.  However, correct me if I am mistaken on this, the description and other text associated with each photo reside with each PhotoGallery and those are what are archived uniquely in each of the PhotoGallery databases, along with other things, uniquely associated with each PhotoGallery.

I could also understand removing the photo from the gallery (and the gallery's database, including the title, description, etc), but keeping the original photo along with the thumb and the normal images.  In that case, the photo is being removed from the gallery since it no longer exists in the gallery's database.

Yes, exactly.  However, I want to emphasize that while I want  each of the affected photos expunged from a PhotoGallery (both their presentation and relevant text included in the PhotoGallery database), the process of expunging these in a photogallery must not result in the deletion of the original photo and the derivative images found in the common pics directory.

 And, for a reason. I posted this because when I tried to upgrade from 1.4.8 -> .4.9, I saved the databases for each PhotoGallery, and I found out that a newly created PhotoGallery with about 800 photos had a database of almost 600KB -- since photos are allowed to have as much as 1500 for the description, and for each comment.   Think of 40,000 photos, or more and the size of the database of each ofthe PhotoGallery becomes very big.  There is no need to keep unwanted data in the database.

FYI: If you merely want to hide certain albums from the random meta-album, you can use this plugin.

Thanks for sharing this link.  I will read more on this.  If it has features there are improvements on the simpler (not so elegant) hiding process I summarized above, I will incorporate the plugin.  However, I try to avoid including plug-ins or mods, because sometimes they have ramifications that I did not anticipate.  I encountered some unexplained slowdown in the presentation of the photos before when I tried to include some features.  Now, I reverted back to the basic CPG-Stramm mod setup, and the slowdown disappeared.  Part of the slowdown might have beeen caused by the issue mentioned by GauGau and you, corrected by one of the "revisions", I believe 1.4.6 -> 1.4.7; around that time.

CGC
« Last Edit: September 02, 2006, 10:30:02 pm by cgc0202 »
Logged
Pages: [1]   Go Up
 

Page created in 0.022 seconds with 20 queries.