CpmFetch 2.0 Request For Comments

[vuud]

This is a thread soley for discussion about the upcoming cpmfetch 2.0.

DO NOT POST SUPPORT QUESTIONS IN HERE... they will be deleted and ignored.  Sorry, but I don't know how to move threads.

I am interested to hear thoughts on new things I plan on doing, especially if they will be a bad thing for everyone. 

Vuud

[vuud]

One of the biggest headaches is for novices and getting the path to the CPG directory correct.  So with the next release I am planning on asking for it to be installed inside the cpg directory.

Mind you I will still have a work around, but the easy way will ask for it to be there.

Does anyone see any problems with this?  The whole cpmfetch folder will be inside the CPG directory.

Vuud

[Joachim Müller]

I'd love to see cpmFetch shipping with coppermine in the future, or as additional plugin/add-on. This would make it mandatory to have cpmFetch installed within a defined folder within the coppermine folder.
In return, you could draw much of the settings from coppermine's config instead of the cpmFetch configuration. This way, newbie users would be able to get cpmFetch started much faster, as most of the data they are not aware of (db settings, path names, URLs) would automatically be populated. Subsequently, the users would only have to worry about the actual syntax of the code on the pages they would like to see their cpmFetch content turn up.
If we decided to bundle coppermine with cpmFetch, there could be a single toggle within coppermine's config (labelled something like "enable cpmFetch" or similar). The only drawback of bundling cpmFetch with coppermine out-of-the-box would be that the coppermine package got a bit larger. Taking into account that cpmFetch currently consists of "only" around 320 kB, this would hardly matter.
When I first decided to use cpmFetch I thought about integrating it more closely into the core (in fact doing as I suggested above), but I dropped work on this in favor of working on other sub-projects.
Thoughts?

Joachim

[vuud]

I'd love to see cpmFetch shipping with coppermine in the future, or as additional plugin/add-on. This would make it mandatory to have cpmFetch installed within a defined folder within the coppermine folder.
In return, you could draw much of the settings from coppermine's config instead of the cpmFetch configuration. This way, newbie users would be able to get cpmFetch started much faster, as most of the data they are not aware of (db settings, path names, URLs) would automatically be populated. Subsequently, the users would only have to worry about the actual syntax of the code on the pages they would like to see their cpmFetch content turn up.
If we decided to bundle coppermine with cpmFetch, there could be a single toggle within coppermine's config (labelled something like "enable cpmFetch" or similar). The only drawback of bundling cpmFetch with coppermine out-of-the-box would be that the coppermine package got a bit larger. Taking into account that cpmFetch currently consists of "only" around 320 kB, this would hardly matter.
When I first decided to use cpmFetch I thought about integrating it more closely into the core (in fact doing as I suggested above), but I dropped work on this in favor of working on other sub-projects.
Thoughts?

Joachim

For the record (and giving credit where due), GauGau made this suggestion like a year ago, and it took me this long (and many support posts) to see the wisdom in his suggestion

This version, strongly suggests installing into the coppermine folder, which will in turn basically automate the installation.  It also connects and retrieves all sorts of goodies by connecting to cpg and saving the config table to a code based php file for fast includes.  Call it a compromise   Basically addressing everything mentioned above... no more setting the path.

In addition to integrating better to CPG, the individual tools are integrated together better.  All settings, activations and more are contained in the centralized cpmfetch config file now... no more $ENABLED=true in each file.

This rewrite addresses many, if not all, of the support posts over the past year.  Some come up way to often to be ignored.

I would say that including it in CPG is always a possibility. 

The installer as of today is working very well - a few more goodies to integrate and it will be posted as development version 1.9.0 with the next stable release to be 2.0.  The dev release is in a few days at the most.

[cgc0202]

I agree with the ideas you presented.  People, like me, with minimal scripting experience would benefit greatly from the integration of CPMFetch into the CPG.

I have only begun to exploit the potentials of CPMFetch, in relation to presenting photos randomly in pages outside of CPG.  However, there might be features already working in CPMFetch that could be adopted in the presentation of random photos in CPG.  I realized for example that the number of photos in the categories and albums are not always equal.  As a result, the random presentation of photos in albums and categories would be dependent on their statistical weightings of their photo content.

This is circumvented partly by the directed album, category, etc,  but random presentation of photos from these chosen groupings.  In some applications, this provides a more balanced presentation of the contents of a photogallery -- and should be considered for application of CPMFetch itself, within the CPG.

The above feature is workable only for a photogallery with few categories and albums.  In "larger" photogalleries,  more complex advance would be a random (or rotated) presentation of all the albums and categories themselves while in turn, the contents within each album or category are randomly presented, irrespective of the global weightings in the CPG database.

These features are advantageous for CPMFetch, as it is integrated in pages outside of CPG. However, I must reiterate that they should be useful also for CPG, by integrating  CPMFetch as a functional feature of CPG or adapting such features within CPG, independent of CPMFetch.


CGC

[vuud]

I agree with the ideas you presented.  People, like me, with minimal scripting experience would benefit greatly from the integration of CPMFetch into the CPG.

Once the dev release is stable, try that one.  I do not think integration would get much simplier, even if cpmFetch was integrated further.  The one extra step would be the install.php that gets run the first time.  A full integration would not eliminate the complexity of including calls in the non-CPG pages.

I have only begun to exploit the potentials of CPMFetch, in relation to presenting photos randomly in pages outside of CPG.  However, there might be features already working in CPMFetch that could be adopted in the presentation of random photos in CPG.  I realized for example that the number of photos in the categories and albums are not always equal.  As a result, the random presentation of photos in albums and categories would be dependent on their statistical weightings of their photo content.

This is circumvented partly by the directed album, category, etc,  but random presentation of photos from these chosen groupings.  In some applications, this provides a more balanced presentation of the contents of a photogallery -- and should be considered for application of CPMFetch itself, within the CPG.

Hmmm, interesting point.  I had not really considered that.  Perhaps a randombalanced call is in cpmfetch's future.  I would pursue this with the CPG folks for an option inside the CPG gallery if you want that there.

The above feature is workable only for a photogallery with few categories and albums.  In "larger" photogalleries,  more complex advance would be a random (or rotated) presentation of all the albums and categories themselves while in turn, the contents within each album or category are randomly presented, irrespective of the global weightings in the CPG database.

As I understand what you are saying, this is possible with cpmfetch as it is - with a bit of code overlayed on top to iterate through each section.  Not really easy, but should really cool things be easy?  

These features are advantageous for CPMFetch, as it is integrated in pages outside of CPG. However, I must reiterate that they should be useful also for CPG, by integrating  CPMFetch as a functional feature of CPG or adapting such features within CPG, independent of CPMFetch.
CGC

You've got some good points.  And I don't deny that eventually CpmFetch could be integrated into CPG, but CpmFetch would at that point be driven more by CPG's internals and its (if any) limitations.

I've been meaning to take a look at the database abstractions inside CPG but have not had time.  CpmFetch was designed to be light and fast - both for database calls and for development also.  For example, I can easily release new features on a rapid basis, where-as CPG has a more structured release and testing cycle.  Of course, mine pales in comparision to the complexity of CPG so I am not saying they are not performing or anything like that.

As the feature set for CpmFetch is refined and many many lessons learned, fundamentally a nice roadmap for a CPG integrated functionality is being defined.  Perhaps that is the best way to look at it for now.

I would like to someday have both cpmFetch integrated into CPG, but also maintained as a seperate more nimble faster releasing "add-on" or replacement in parrallel.  New functions could be integrated and tested as CpmFetch, then integrated into the main CPG distrobution on their release schedule.

Cool points thoughts

Vuud

[n3n]

I think it would be nice to have cpmfetch spit out an unordered list of things like albums/categories/users/uploads by date.
This way this info could easily be transformed into a select box, or a "suckerfish" css menu.
Think this would be a nice addon for the navigation of coppermine.
Also it could be used outside of CPG, like the frontpage..

Just an idea

[vuud]

I think it would be nice to have cpmfetch spit out an unordered list of things like albums/categories/users/uploads by date.
This way this info could easily be transformed into a select box, or a "suckerfish" css menu.
Think this would be a nice addon for the navigation of coppermine.
Also it could be used outside of CPG, like the frontpage..

Just an idea

when you say "unordered" by "date" I get lost... do you mean <UL> tags for the unordered part?

[n3n]

Yea sorry was a bit unspecific. Yes I meant UL tags, or any other way that it could be combined with
menu systems and css.

[Slideshow Bob]

Specifying the URL in the install is a great idea.  I can't see a downside - especially if you run the testscript right afterwards...

[vuud]

Specifying the URL in the install is a great idea.  I can't see a downside - especially if you run the testscript right afterwards...

I think I nixed that part... In the end the whole thing made more sense as a relative url.  You can override it after.  Trust me, the way it is now is like 100x better than it used to be.

[cgc0202]

Hi Vuud,

I like the current CPMFetch right now, even as it is.  There are times where I can only show one large "single photo box" on a page. I can do that too, with CPMFecth.  An ideal feature of this large photo box would be akin to the "automated slide show" of CPG or perhaps a random slide show, presented in a single photo box, to add some more dynamism to the photo presentation on such pages. Of course, if such feature is available, there is no reason why both the existing features of CPMFetch could not be availed together with a new feature, where applicable.

The CPG already includes an automated slide show, albeit much simpler  (same sequential order each time) than that of the more sophisticated flickr "single photo box" presentation:

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

The threads that I have read so far only considered framing the CPG slideshow; that approach does not have the portability and flexibility of what can be done now with CPMFetch.

Not sure how much work that would entail or how much it would add to the file size of the  CPMFetch program. 

CGC