Is this possible?

[revjoe]

Apologize if this is the wrong forum, but couldn't find a misc forum.  I am considering using coppermine for displaying images I have on one of my servers.  The problem I have is that the directory structure and paths that I have in place are not changeable (would break existing applications).  I understand coppermine wants the images to reside in its directory structures, but is there a way to tell it that they exist somewhere in another path?  (all are web accessible, but they just to not have a common root  path).  Or alternatively can I create a symbolic link into coppermine's path that links to the real path?

Thanks for any pointers.

Joe

[Paver]

You might try the MassImport plugin.  Check the plugins contributions board.  It's designed to mirror a directory/file structure in your Coppermine categories & albums.

[lamama]

I understand coppermine wants the images to reside in its directory structures, but is there a way to tell it that they exist somewhere in another path? 

Well, cpg WANTS them there... it doesn't always get what it wants 

If I got your question right, you have the pics on your server and it's not possible to get them inside the cpg folder, right?
If all the pics have at least one common root folder, it might work. I had a cpg 1.3.x running with the albums folder outside the cpg folder and it worked fine, but maybe someone here knows about limitations that I haven't experienced with that configuration.

Let's say your paths are like ...

/coppermine/   - this is your cpg folder
/stuff/morestuff/pics/      - this is the path to your galleries.

Look at the coppermine CONFIG panel ->  Files and thumbnails advanced settings -> The album directory
Normally it's set to "albums/". Change the path (relative) from your cpg folder to whereever your pics are.
Like "../stuff/morestuff/pics/" (refering to the example above)

I guess coppermine needs 2 folders at this new location ("userpics" and "edit"), but maybe you can just copy them from the existing "albums" folder. IIRC you'll need to chmod them to 777.

[cgc0202]

Let's say your paths are like ...

/coppermine/   - this is your cpg folder
/stuff/morestuff/pics/      - this is the path to your galleries.

Look at the coppermine CONFIG panel ->  Files and thumbnails advanced settings -> The album directory
Normally it's set to "albums/". Change the path (relative) from your cpg folder to whereever your pics are.
Like "../stuff/morestuff/pics/" (refering to the example above)

I guess coppermine needs 2 folders at this new location ("userpics" and "edit"), but maybe you can just copy them from the existing "albums" folder. IIRC you'll need to chmod them to 777.

Did you say you tried it and it worked for you?  I wanted to do that myself, but not for the reason stated in the original post.  I did do a "777" on all the folders and used the alternative path in the CONFIG panel, but I got an error note that there is no folder in the Albums.

cgc0202

[lamama]

Did you say you tried it and it worked for you?

With 1.3.x no problem and AFAIK it hasn't changed since then.

Getting the right relative pathname can be a bit tricky 

(minutes later)

I just tested batch-add with an "old" 1.4.4. install and it worked. At least the folder that actually contains the pics needed  chmod 777.

Have you checked the other permissions? Owner? Group?

but I got an error note that there is no folder in the Albums

Can you post the complete error message?

[cgc0202]

Thanks lamama,

I am installing the new 1.4.5 as advised, then add the "squared" module, then try to retrace what I have done previously and will post here if it works.  It should.

cgc0202

[revjoe]

Actually, I had not tried it yet.  I am still at the point go trying to decide which software to use and was hoping to get some "pre-sales" help. 

Thanks guys.

Joe

[Paver]

revjoe: In that case, a few points. 

• The config setting for the albums directory is intended to allow you to do what you want.  The issue is that it is not quite robust enough to handle all permissions setups.  (Hence the discussion and testing here.)
• At the base level, the file paths are all kept in MySQL tables you can easily view for setting up a mod or plugin to modify your Coppermine setup to handle exactly what you want.  If you don't have the skills to do so, there are often people here who do and want to do something similar (as you can see from this thread).
• The new plugin system (as of 1.4) will allow easy add-ons to your Coppermine without hacking the core scripts.  But not all hacks (a.k.a. mods) have been converted to plugins, so there may be some work there as well.
• Here's one example that may be instructive.  I wanted to keep all the Coppermine-created thumbnails and "normal" images (intermediate-sized images) in a subfolder of each album folder so I don't have to browse through all those extra files when looking at the raw folders.  I was able to do what I wanted with a combination of configuration settings and a simple mod.  This mod is so simple that I can easily upgrade to newer versions of Coppermine, although I'd like to convert the mod to a plugin when I get around to it.
• Coppermine is open-source and you can easily view the code and the database tables for any customizations you want to make.

Happy hunting!

[cgc0202]

• Here's one example that may be instructive.  I wanted to keep all the Coppermine-created thumbnails and "normal" images (intermediate-sized images) in a subfolder of each album folder so I don't have to browse through all those extra files when looking at the raw folders.  I was able to do what I wanted with a combination of configuration settings and a simple mod.  This mod is so simple that I can easily upgrade to newer versions of Coppermine, although I'd like to convert the mod to a plugin when I get around to it.
• Coppermine is open-source and you can easily view the code and the database tables for any customizations you want to make.

Happy hunting!

Hi Paver,

That is even a greater idea, i.e., the simple mod you create that would separate the thumbnails and intermediate pics.  There are a number of "randomizing" scripts that would require a database of pics to randomize. It would be impractical to use the resulting database of pics resulting from Coppermine or other current photogalleries softwares I have tried -- because of the redundancy of the various sizes.

Actually, for some of the "randomizing" programs, the "intermediate" sizes might be more useful for easier uploads because of the lower byte size than the originals.  It looks like the flickr might have used the thumbnails, based from the links shown by Tarique in:

http://forum.coppermine-gallery.net/index.php?topic=7920.0

There are some interesting simple randomizers there plus some I found in the internet.

Is the mod you created discussed somewhere in the Forum?  Would it be possible to get a glimpse of it?

Thanks.

cgc0202

[cgc0202]

Hi lamama,

The installation of v1.4.5 went smoothly.  I made sure this time that I had folders in both the "albums" inside the CPG as well as a pics outside. 

I included below why things were not working before I figured out  what the mistake was -- did a lot of trial and error.  The key was quite simple -- two dots (..) before the forward slash (../) -- made the difference. 

../pics/

[Note the difference of this presentation in comparison with how the Admin  created folders are specified in the Config.]  For directories outside of the program itself, without the "../", in specifying the route path; for example if just like this:

pics/
/pics/

the program would think that it is inside the "album" directory.   So that it specifies the route of the outside folder "pics" as if it was inside the default "albums" directory.  So that the route path shown for the two specifications above would be like this:

...//cpg/albums/pics/inner folders/

...//cpg/albums//pics/inner folders/

respectively.  [Here, "...//cpg/"  refers to the route path before the default "albums" directory, and "cpg" refers to the name of the directory where the Coppermine program was placed.]   

In contrast to the above, with the two dots and the forward slash added, ie. ("/pics/"),  the Coppermine program would now interpret it this way:

...//cpg/albums/../pics/inner folders/

It still looks odd, but the second time I tried it, I happen to have uploaded photos in folders found in both the inner default "albums" and in my outer album, i.e., "pics".  In the second try, i.e.,  ("/pics/"),  the program pick up the folders with photos, outside of the program itself.

Also, there must be some prior "Albums" created already.  And, when I tried the "Batch add files", the program picked up the photos found in the  folder  outside of the program, created the thumbnails and intermediate -- and deposited them back to the original folder (outside of the program). 

It was working, because I could view them in the main page. I loaded my next set of pics and everything worked, but when I hit "Home" again, I got an error message -- something about not being to resolve the request (forgot now).  Devasting.  I thought, my procedure corrupted the system.   I checked an old photogallery in another website but using an older version of CPG, and it was working.  I checked another more recent one in a subdomain, it was also working.

Undaunted, I decided to reinstall  the program and started all over again -- install, upgrade, check version and configured.  Then I setup the directories, albums and changed their permissions. etc., etc.  Everything was working -- well until I FTP more pics (that worked), did the  "Batch add files" (that worked), then I hit "Home":

Same problem. .... same error message again.

I was about to write a ticket to my webhosting service.  But I found something odd, the general structure itself of the pic gallery was intact.  This means that the database itself was working.  The clue that there was nothing wrong with what I was doing was that when I tried the other photogallery in the same subdomain it was now not working also.  On the other hand, the one in a different domain was still working.

OK, long story short, it was a server issue, most likely but just guessing -- for some reason my system malfunctioned while I was doing the trial and error.  Maybe it got crazy with all the add and erase, as I was doing it by trial and error.

Thanks.

cgc0202


N.B.


All had the CHMOD changed to  "777"  I placed the route path of the outside  /pics/ folders  in the Config.  Somehow the program treated them as if the one I enter was inside the "albums: folder and I got this message:

"There are no folders inside the "albums" folder yet. Make sure to create at least one custom folder within "albums" folder and ftp-upload your files there. You mustn't upload to the "userpics" nor "edit" folders, they are reserved for http uploads and internal purposes."

This was the message I got the other day when I tried the previous approach -- using  (/pics/) without the two dots:

[I reverted to creating the folders inside the "albums: and of course that worked.]

I repeated the process today, and got the same error message.  I was not that surprised actually, after re-reading your post. The clue was the "two dots", I remembered instantly how in another application I use, without the two dots (maybe it works with three dots), the program interprets the link as if the folder in question was inside rather than outside.  I never encountered this before with a script using just basic html.

To test my hypothesis, I tried it with the "two dots", and what happened was as I explained above.  What is contained here would be boring to most.  However,  I related this because there might be people here like me with no scripting background and experience.

[lamama]

Uff! Quite a lot text. Let's see if I understood  it...

So you had 2 problems, right?

1) server malfunction, leading to strange results. :-)

2) you did not entered a "relative" path with leading '../'  like I wrote in my first reply. Might be an language issue on my side


BTW: I don't know what effect double ('//') or triple ('///') slashes actually have. Or triple dots ('...').
AFAIK the right syntax to go one step down the path is '../' while './' is refering to the actual path. To go two steps down the hierachy it would be '../../'

I'm not sure if /// or ... makes any sense at all, but maybe some wwwwizard round here knows better.

[cgc0202]

Hi lamama,

Sorry for not responding. I did not get the usual message that someone responded to this post. Better late than never.

Uff! Quite a lot text. Let's see if I understood  it...

So you had 2 problems, right?

1) server malfunction, leading to strange results. :-)

2) you did not entered a "relative" path with leading '../'  like I wrote in my first reply. Might be an language issue on my side

Yes to both counts. *grins* and *sighs*  I was having all sorts of internet connection that day.  It was not a language issue on my side.  Poor eyesight on my side or lack of attention to detail.

BTW: I don't know what effect double ('//') or triple ('///') slashes actually have. Or triple dots ('...').
AFAIK the right syntax to go one step down the path is '../' while './' is refering to the actual path. To go two steps down the hierachy it would be '../../'

I'm not sure if /// or ... makes any sense at all, but maybe some wwwwizard round here knows better.

It depends on how the codes were configured.  I am trying a links directory software right now, the presence of unresolved "//" may trigger some features  to malfunction. 

Thanks for the tip.  I am now migrating to having all photos outside.  This will help me a lot because I opted to have multiple photogalleries -- where many photos may be integrated in a number of the multiple independent galleries. 

If Paver will share how he separated the derivative photos (thumbs, minis and intermediates) from the original, then the option of having them outside would even be more useful.

Thanks again.

cgc0202