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