Would like to select physical repository (directory/destination) on upload

[HenrikBechmann]

I would like my users (custodians) to place uploaded files in specific target directories (repositories) when uploading files. I understand that the default behaviour is to upload them to a userpics subdirectory based on an internal user id, but that makes the pictures essentially inaccessible to the wiki that I am using for content management (pmwiki). I also understand that ftp is the alternative, followed by a re-scan of the directory from within coppermine, but it would be SO much easier if my custodians could select a target for the upload. Has someone done a hack for this perhaps? How hard would it be to do one, ie have a repositories table and surface it to the admin interface, the permissions, and the upload interface?

In general, is there any way to allow the user to select a picture repository when using the upload feature?

Thanks,

- Henrik

[Paver]

There are hacks that give moderator functions and album edit permissions to non-admin users.  Please see the Mod/Hacks board (under Admin Functions sub-board) for these.

But are you instead suggesting a non-Coppermine directory destination?  Please describe the directory structure in more detail, with write permissions for which directories.  I don't know if this has been done in the past (have you searched the forum yet?).  One problem is that Coppermine expects all pictures along with thumbnails & intermediate pictures to be in the albums/ directory.

[Joachim Müller]

to avoid creation of sub-directories within coppermine's userpics folder, enable silly_safe_mode in include/config.inc.php (not recommended though on servers that don't run on safe mode). Putting all pics into the same folder may cause issues later if your gallery grows. You can change the location of coppermine's albums folder in coppermine's config - use relative paths there if you need the albums folder to reside somewhere else than within the coppermine folder (not recommended though).

[HenrikBechmann]

But are you instead suggesting a non-Coppermine directory destination?  Please describe the directory structure in more detail, with write permissions for which directories.  I don't know if this has been done in the past (have you searched the forum yet?).  One problem is that Coppermine expects all pictures along with thumbnails & intermediate pictures to be in the albums/ directory.

I am suggesting that there are two logical levels to this (and any) object management scheme: The repository (single site/physical location) and various collections (such as albums) which are arbitrary combinations of the objects stored in repositories.

At the moment the repository scheme of coppermine is implicit: the objects reside in an "owner" repository. This has been extended to allow arbitrary repositories per the "Batch Add Files" function.

I am suggesting that the implicit scheme be made explicit: Allow declaration of named repositories (essentially an ID/ name/path combination); then allow matching of picture locations to repositories. It involves one more level of abstraction in your database - specifically (logically) changing the filepath field to "repositoryID" in the pictures table. The repositoryID field would point to a record in the "repositories" table which would have a "filepath" field there.

The named repositories could then be offered (optionally) during upload, as destinations, governed by the usual permissions. I imagine the system could be made to operate as it does now by defining certain default configurations.

So to answer your first question, no the idea is not to reach outside of coppermine, but rather to render explicit a concept (repositories) that is now implicit. This would continue the practice of holding the "thumb_" and "normal_" files in the same repository.

Your second question: my directory structure: I have about 20 departments (arts, food, sports, campfires, picnics, etc) for a community website (www.dufferinpark.ca). Each department has its own master directory from the root, and each department directory has (among other things) a photos subdirectory. These would be the logical repositories for the scheme that I am talking about. But as with anything, there is a lot of cross-over (the "newlsetter" department refers to pictures in a bunch of other departments for example), roughly analagous to the "album" vs. "repostory" distinction. I don't have a problem making repositories read/write. Organizationally I have 1 or more custodian for each department, and rights can be thus limited.

On a practical level, pmwiki (I am using wiki software as simple content management software) has a "map" concept, which is a way (just a 2 column text file) of matching a path (url or local path) to a name, so that you can do Picnics-Photos:somepicture.jpg, in the wikimarkup, and have the system substitute the path (/picnics/photos/) for the name. So if I can match coppermine repositories to pmwiki repositories, I'm home free with a very loosely coupled link between the two. The alternative (I suppose) is to invent a syntax in pmwiki that means "Coppermine album", and then write some pmwiki code that draws on the coppermine database. But that's a much more tightly coupled, product-specific (and from my point of view less desirable) solution. Not to mention involving more technical work and code maintenance.

Coppermine, from what I can see, having enabled the "Batch Add Files" approach and the supporting admin tools, is very close to supporting such a general, comprehensive, symmetrical, and flexible scheme. All it needs is a repository table, and integration of the requisite support.

Is this clearer? Does it make sense?

- Henrik

[HenrikBechmann]

to avoid creation of sub-directories within coppermine's userpics folder, enable silly_safe_mode in include/config.inc.php (not recommended though on servers that don't run on safe mode). Putting all pics into the same folder may cause issues later if your gallery grows. You can change the location of coppermine's albums folder in coppermine's config - use relative paths there if you need the albums folder to reside somewhere else than within the coppermine folder (not recommended though).

GauGau,

In order to allow my photo repositories to be seen as album subdirectories, I have set the album path as "../" ie the root of the website (coppermine is located in /gallery/). This allows /arts/photos/, /food/photos/ etc. to be seen as picture repostories by the system. In the short run I may use your "silly safe mode" (LOVE the name!!! ) to make one repository for newly uploaded images, though this as you say is not at all desirable in the long run, and it sort of interferes with my scheme in the short run. (Thanks for the hint though).

You say it is not recommended to make folders outside coppermine folders, and I appreciate your cautiousness, but I submit that with good design, it makes a lot of sense to have repositories (read folders) -- if they are clearly defined and carefully controlled -- shared by more than one application, as it allows for loose coupling between applications that are integrated into a website.

As another example, I use phpicalendar for presenting calendar information. By design this application does not create icalendar files, it just renders them. In this case, the repository (ie folder where the .ics files are stored) is shared by phpicalendar for presentation, and (in my case) the mozilla calendar (implemented as an extension of Firefox 1.5) as the icalendar file creation application.

See my response to Paver for more details.

I appreciate your input.

All the best,

- Henrik

[HenrikBechmann]

to avoid creation of sub-directories within coppermine's userpics folder, enable silly_safe_mode in include/config.inc.php

Hi GauGau,

I don't see "silly_safe_mode" in include/config.inc.php.

would it be

$CONFIG['silly_safe_mode']=true;

or

$CONFIG['silly_safe_mode']='true';

??

Thanks,

- Henrik

[HenrikBechmann]

to avoid creation of sub-directories within coppermine's userpics folder, enable silly_safe_mode in include/config.inc.php

Hi GauGau,

Ignore my last request for clarification. I poked around in the source code, and now have

define('SILLY_SAFE_MODE', true);

in config.inc.php.

I have renamed the userpics/ directory to commonphotos/

where all uploaded images now end up.

I have created an Album called CommonPhotos, and will create a map entry in pmwiki like this:

CommonPhotos   /commonphotos/

I will instruct custodians to upload only the occasional picture using CopperMine, and assign all such uploaded pictures to the CommonPhotos album.

I will instruct custodians to bulk-upload photos with ftp (using FileZilla) to departmental photo repositoroes,  and to ask me to rescan those repositories as needed.

This gives us a workaround in the short run, and will give me time to sort out what to do for a permanent protocol.

Thanks for the tip.

Best,

- Henrik