Coppermine devs: what is best way to give you clean e107 integration?

[MrPete]

Hi,
I'm a dev for e107, and am this close to having a clean integration of cpg 1.3.2 with no further hacks required (i.e. it could slide into e107 without anything but bridge/theme code, plus the few core cpg code changes i've made, which use standard UDB... defines.)

I've also found and fixed some bugs, and done a bit of other cleanup work.

Before I do final cleanup and prepare to submit all this to you, I'd like to ask:
  - what's the best way to hand serious updates to you?
  - do you want changes submitted for any/all of stable/devel/(cpgNG) branches?
  - what else should I know before I go into the final stretch on this?

Thanks much for ALL you do! cpg is truly awesome.

[Joachim Müller]

I'd like to suggest that if you are planning to release an e107 port (anything that contains modified coppermine core files), please add another footer line to the bottom of your port that says where support for the port can be gotten from - we have been troubled in the past with users seeking help for coppermine ports we simply don't know - at least in the admin section of each theme there should be a big fat disclaimer that the port is not supported on this page (unless you volunteer to actually start moderating a sub-board that deals with support for an e107 coppermine port).

The stable (cpg1.3.x) branch will be discontinued once the devel branch gets released, so we're of course interessted in actual bug fixes for cpg1.3.x (stable), but we're aware that there are cosmetical issues within cpg1.3.x code that doesn't need fixing.
We're keen on fixes for all versions of coppermine, but both the devel branch and especially the cpgNG branch are currently under heavy contruction and are being changed all the time, so it would make it much easier if any code submissions or bug reports are based on very recent cvs checkouts. Of course it would be the easiest method if you could actually address each bug you discovered individually in new posts (don't worry, although you can't post on the bugs board we're ready to receive any bug reports posted on another sub-board of the forum - we'll move them accoringly; please make sure that the subject lines say e.g. [cpg1.4 bug report] or similar, plus an actual subject.
In the past, the author of another coppermine port (Andi, who ported coppermine for vkpMx Pragma) has been of very great help by posting many bugs that existed both in the stable and devel branches. His reports where oustanding, if you could post the iussues you discovered in a similar manner we'd be very gratefull.

Having another port for coppermine around is one thing (and we understand and are happy that it will increase the coppermine user community), but very high on my "wishlist" would be "non-ported" support for CMS like e107: an actual bridge file that just gave users the opportunity to use e107 user management without close visual integration (although an e107 theme would of course be great) without the need to modify any coppermine core files would make it much easier for us to react and plan ahead; and supporters would be happy as well as some users. Don't get me wrong: do you port, as the e107 project will of course benefit if there is a powerfull photo gallery module around for it; but I would like to ask you to provide "just" a bridge file as well that leaves the core files as they are.

I'm looking forward to your thoughts and submissions.

Joachim

[MrPete]

Thanks for the helpful hints, Joachim!

re support -- that's a good idea. You're right, we don't want to cause confusion. Once I better understand whether what I'm doing is a port or not ... then I'll know what kind of footer to write!

I'll be glad to submit fixes etc in postings. That's what I did with e107 until they decided to twist my arm to become a dev . (Easier to checkin directly, harder to feel like I have no responsibility for it...)

AFAIK, in your terminology this is intended to be a "non-ported" version... yet perhaps it's a ported non-port or something. e107's DB very much prefers to be frobbed by the e107 core classes... which means the bridge file depends on being somewhat integrated into e107. My goal this time around was minimal changes to coppermine core.

There are really only two key core changes dependent on UDB_INTEGRATION==e107

1) e107 manages ob_*; having coppermine start up its own sub-level causes some pain (I hesitate to call it a bug in coppermine since I'm actually a coppermine noob... you may find our new debug tools helpful however ). It's quite possible this could go away with appropriate effort applied to the coppermine codebase... maybe 1.4.0 is all that's needed! I'll check asap.

2) there's a fundamental filename conflict. e107 plugins all have a "config.php" file. I can put a tiny bit of conditional code in the coppermine file of that name... or require users to rename it when installing with e107. I'd rather just insert the necessary conditional code into coppermine, so the problem is permanently resolved.

The rest is all bug fixes and new/improved features... which really have nothing to do with e107 at all.

As for the level of integration with/in e107... this "non-ported port" works rather smoothly:
* It implements all the coppermine bridge functions as specified
* It makes use of all coppermine database definitions to install, upgrade and uninstall within the e107 environment
* It uses a single generic "e107" coppermine theme to render coppermine in the currently selected e107 theme -- ANY e107 theme.

[Nibbler]

The bridging system is different in 1.4 (and is still not final in cvs), so you may encounter some issues there.

[Joachim Müller]

2) there's a fundamental filename conflict. e107 plugins all have a "config.php" file. I can put a tiny bit of conditional code in the coppermine file of that name... or require users to rename it when installing with e107. I'd rather just insert the necessary conditional code into coppermine, so the problem is permanently resolved.

There's no file named "config.php" in cpg1.4.x any more, it has been renamed to admin.php to avoid issues on some webhosts who won't allow a file named "config.php" on their server; yeah, I agree - this is a stupid policy, but a workaround that works for us and is something you should be able to "benefit" from.

If you plan to base your port on cpg1.4.x code, please be adviced that there might still vast changes in the devel code - basing your code on anything that exists within the current devel branch of the cvs might turn out later not to be included in the release.
If there are only minor modifications within coppermine's core code that make the e107 version "tick", we should discuss them - maybe we could iron them out. As I said before: another port (seen from the coppermine standalone dev team's point of view) is just another port (that will cause support related questions we can not answer), but an e107 bridge that will seamlessly integrate both apps, while the core code of both apps stays untouched and only some files are added would be great (well, in an ideal world ).

Joachim

[MrPete]

2) there's a fundamental filename conflict. e107 plugins all have a "config.php" file. I can put a tiny bit of conditional code in the coppermine file of that name... or require users to rename it when installing with e107. I'd rather just insert the necessary conditional code into coppermine, so the problem is permanently resolved.

There's no file named "config.php" in cpg1.4.x any more, it has been renamed to admin.php to avoid issues on some webhosts who won't allow a file named "config.php" on their server; yeah, I agree - this is a stupid policy, but a workaround that works for us and is something you should be able to "benefit" from.

OK, sounds like the cpg1.4.x version will be all the more directly-compatible

If you plan to base your port on cpg1.4.x code, please be adviced that there might still vast changes in the devel code - basing your code on anything that exists within the current devel branch of the cvs might turn out later not to be included in the release.

Since I'm basically done with the 'stable' work, and a lot of e107 sites would appreciate having access... my inclination is to get a 1.3.2 version working ASAP... and track with the coppermine dev's to ensure a 1.4.0 version will be ready out of the box.

If there are only minor modifications within coppermine's core code that make the e107 version "tick", we should discuss them - maybe we could iron them out....an e107 bridge that will seamlessly integrate both apps, while the core code of both apps stays untouched and only some files are added would be great (well, in an ideal world ).

I agree completely .. and I think it's not too hard to get there. Perhaps it might even be of value to make the ob_* change an option for other bridged situations.

The only two changes necessary to seamlessly integrate coppermine with e107 are:
1) No ob_* - in init.inc, if UDB_INTEGRATION=='e107', do *not* do the ob_start(); same in cpg_die (functions.inc). Everywhere else, no change is needed because the page_footer() intercepts and completes coppermine's rendering.
2) In config.php, a few lines of logic added if UDB_INTEGRATION=='e107' to redirect the flow to the e107 config file. Again, this can disappear in 1.4.0

We also made some gratuitous 'improvements' such as
3) No wasted time with 'ok' message when switching between user/admin modes (admin.php)
4) Revamped EXIF display
etc...

...but those have nothing whatsoever to do with e107

Thanks again for your helpful feedback and encouragement!
Pete

PS -- I can pm you a link to a functioning integrated site if you like. It's a private site for a public service group, which is why I don't want it to show up here 

[Joachim Müller]

I can pm you a link to a functioning integrated site if you like. It's a private site for a public service group, which is why I don't want it to show up here 

Yes, please go ahead and PM me this link.

Joachim

[MrPete]

One more question re preferences of coppermine developers:

Integration with e107 requires a few added files beyond the basic bridge/XYZ.inc.php

What's your preference?

* Keep them entirely out of the coppermine code base, provide separate download and instructions for integration from the e107 plugin repository site.
   Place cross-referenced instructions in the bridge module header.

* Create a bridge-specific subfolder (bridge/e107 ?) with the necessary files and integration instructions (e.g. a couple of files must be placed in the coppermine root).

* Some other idea 

Thanks

[Joachim Müller]

I'm not sure about this, as bridging is currently under construction in the devel branch of the cvs, so I'd like to give a recommendation that will work in the future as well. From the bottom of my heart, I'd say "create a sub-folder within the bridge folder and put your additional files there", but I'm not sure. As far as I can see there will be no workaround to make this a clean integration, it will be a port anyway you put it, so I suggest you just make this in a way that is easiest for you to maintain and reflect changes in the coppermine core code.

Joachim