Print

[extrabigmehdi]

hi,
I've just recently adapted my bridge for Joomla 1.5 to work with cpg 1.5.

I've managed to make it work without any hacks on Coppermine core files
People can grab the bridge , and test it from here:

EDIT:
link to bridge has changed to
http://www.mehdiplugins.com/misc/index.htm

No attachments as I  prefer to keep stuff I  distribute on my website, sorry.

[François Keller]

I've managed to make it work without any hacks on Coppermine core files

it's a good new, thank's i'll test it

[Joachim Müller]

Excellent news.
The best thing is that no fiddling with core files is needed and that the visual integration is done using a plugin. Excellent. What license do the bridge and the plugin come with? I couldn't find reference to a particular license in the bundle. Are we allowed to bundle the plugin and the bridge file with the package, i.e. are those two components under GNU GPL or a compatible license? Of course your inline credits would remain and additionally you would be credited both in the readme as well as the coppermine site.
If those two components (bridge & plugin) would be shipped with coppermine, people would just have to copy the component into Joomla (step one of your instructions) - that would be very easy.
There's a lot of need in the community for an official Joomla-bridge in my opinion. Anything that makes integration easier is very welcome imo.
Thanks again, Mehdi. I'm looking forward to your reply. I really would love to see your compoments go into the core. Please answer as soon as you can.

Joachim

[extrabigmehdi]

hi,

The best thing is that no fiddling with core files is needed and that the visual integration is done using a plugin

I must admit that enabling / disabling visual integration through Coppermine admin panel  is quite convenient.
It's only recently that I've understood how Coppermine plugin work (partly because of lack of examples in package) , but I  don't have courage/time to re-apply this enhancement to previous bridge (and update all instructions etc..). Maybe later.

I couldn't find reference to a particular license in the bundle.

I'm not a specialist of all open source license available. But officially I announce all my stuff as GPL2 on Joomla extension website.

Are we allowed to bundle the plugin and the bridge file with the package

I'm sorry  , but I'm making few bucks with the ads on my website, and hence I do not wish.
Moreover, I  update from time to time  files on my website , if this can help to solve/bypass issues.
However I can change my mind if the average user perceive this too much  as an annoyance,
or if ever I'm not able one day to ensure proper distribution of these files.

I  would also add , that user might still want to edit the $joomQS setting in  joomla15.inc.php file of the bridge.
This is basically the query string passed to joomla before calling it. The reason is that the bridge cannot guess to which joomla's menu item, the user wish to associate coppermine,when enabling visual integration (by default, no menu item)  .If user could decide the  $joomQS  setting from the bridge manager this would be nice. Why the available settings in bridge manager are not just simply customizable ?

Concerning the code used in my bridge, I guess I'm not respecting the "spirit" of the  "Inspekt package" . I  got
to access directly to stored superglobals with "_source" property  (especially $COOKIE) before calling Joomla .

[Joachim Müller]

I'm sorry  , but I'm making few bucks with the ads on my website, and hence I do not wish.

That's why I suggested to bundle only the plugin and the bridge file with the release. Users would still have to visit your site to get the stuff that needs to go into the joomla folder. It would just mean that things are less confusing for newbies who have issues even copying files and folders into the correct location.
It's no taboo to discuss the final step of the bridge manager.
Another possible way would be to force end users to visit your site by giving out API keys (similar to what wordpress and akismet are doing) and performing a check against the API key in the bridge manager. This way, you could force the end user to visit your site as well. Imo your request is legitimate to force people to visit your site. My focus lies on two things: bundle the core bridge component with coppermine, so that the coppermine documentation could as well say that there is bridging support for Joomla. This way, much more users would learn about your bridge file imo.

Concerning the code used in my bridge, I guess I'm not respecting the "spirit" of the  "Inspekt package" . I  got
to access directly to stored superglobals with "_source" property  (especially $COOKIE) before calling Joomla .

Why do you do that? That's not a bright move imo - you're deliberately ruining the additional security that is created by using Inspekt. Why do you re-globalize all of them instead of just looking up the ones you actually need and populating your variable scope with just the needed stuff? The idea behind using Inspekt is that you deliberately need to "ask" for particular superglobals instead of allowing them blindly. This is suppossed to help prevent vulnerabilities that used to creep in previously because of sloppy coding.

[extrabigmehdi]

hi Joachim,

That's why I suggested to bundle only the plugin and the bridge file with the release. Users would still have to visit your site to get the stuff that needs to go into the joomla folder.

The joomla component is very basic. All it does is displaying the {COPPERMINE_TEMPLATE_HTML} tag inside Joomla.
This way the bridge can capture Joomla output and replace this tag, by the output of the gallery.
There's even a way to use no joomla component at all, it just might be more complicated to explain.

Another possible way would be to force end users to visit your site by giving out API keys (similar to what wordpress and akismet are doing) and performing a check against the API key in the bridge manager. This way, you could force the end user to visit your site as well. Imo your request is legitimate to force people to visit your site.

well that's a bit a weird solution.  At least when people visit website they take few minutes to read some instruction.
All of this looks like a dumb problem  ...  Probably I  should write true interesting articles, instead of giving away  stuff, and then expecting people to come back.

This way, much more users would learn about your bridge file imo.

Lot of people already know it I  think.
But I  guess people will adopt it more easily if it's officially supported by  Coppermine.

Why do you do that? That's not a bright move imo - you're deliberately ruining the additional security that is created by using Inspekt.

I'm not ruining the security introduced by Inspeckt at all.
But you have to be aware of the logic the bridge, that's why I bring this to your attention.
I  proceed this way:
1- restore some superglobals
2- call the full joomla install (yep, joomla included like a 'vulgar'  script).
3- destroy again superglobals.

Because I  cannot predict how Joomla will handle all superglobals (that's a big CMS), I'm just giving it  all the superglobals it can expect. In a similar way, Joomla destroy all globals at begin, and I have to bypass this otherwise all Coppermine globals  will be destroyed and it won't work.

I think I've done my best regarding security , just be aware that the bridge is  a different "beast". Joomla and Coppermine,
are both handling in different way security,  and I'm just ensuring that security solutions adopted by both script is not breaking logic adopted by my bridge.

"Final problem", I currently know: Coppermine & Joomla are using same class PHPMailer. Usually Joomla doesn't load by default the
class PHPMailer, and hence no conflict occurs. But I  got once a user complaining that a conflict occured .

I've told  more or less all the potential problems.
Once you understand that the full Joomla install is included inside Coppermine by the bridge, you should realize all that it implies.

[Joachim Müller]

Thanks for your patience to explain all those things to me. I must confess that I'm a complete novice when it comes to Joomla, so please bare with me.

"Final problem", I currently know: Coppermine & Joomla are using same class PHPMailer. Usually Joomla doesn't load by default the
class PHPMailer, and hence no conflict occurs. But I  got once a user complaining that a conflict occured .

This should be pretty easy to solve: we can savely rename "our" class or wrap it inside a if (!function_exists('function_name') {-construct.

I'll do that this weekend.

Joachim

[phill104]

extrabigmehdi

I'd like to thank you for excellent bridge. It is the only one that works well and as such I have been using it for a long time now. It is so good to see that you are continuing development to coppermine 1.5 as I would be lost without your efforts. This bridge  should enable a lot more users to integrate Coppermine and Joomla where before many struggled to apply the code changes. Keep up the good work.

As for people visiting your site, I'm sure people will still visit simply to get their themes sorted with your css integrator ( http://www.mehdiplugins.com/misc/cssintegrator.htm ), and get instructions on getting their themes to work properly. I'm sure if you included these links in the plugins details then you could increase traffic to your site.

[Nibbler]

This should be pretty easy to solve: we can savely rename "our" class or wrap it inside a if (!function_exists('function_name') {-construct.

Renaming is safer. We don't want to end up using Joomla's copy of the class instead of our own.

[Joachim Müller]

It should be safe to just rename the class, right?
Editing include/mailer.inc.php, finding

Code: [Select]

$mail = new PHPmailer();and replacing that string with

Code: [Select]

$mail = new cpg_PHPmailer();Then find

Code: [Select]

class PHPMailer {and replace with

Code: [Select]

class cpg_PHPMailer {Taking a closer look: we have another class named SMTP that might be there two times, so we'd have to rename that as well.

We don't want to end up using Joomla's copy of the class instead of our own.

Why not? They use PHPmailer as well. Couldn't we just wrap the two classes into corresponding if (!class_exists('class_name') {-code and get away with that? After all, the users of the joomla bridge warp "our" gallery into an entire CMS - the CMS should know what it is doing anyway.

[extrabigmehdi]

@Joachim Müller ,

I must confess that I'm a complete novice when it comes to Joomla, so please bare with me.

For your information, Joomla! has a small learning curve. It's currently the easiest CMS to use (with its "predecessor" Mambo).
And also it has quite enough flexibility for most people. I think even Microsoft is annoyed by Joomla, since recently I saw an article bashing Joomla! , but full of lies (and answer by "Joomla community"). So now you should  be curious, and try it   ... 

@Phill Luckhurst

It is so good to see that you are continuing development to coppermine 1.5 as I would be lost without your efforts.

Fortunately, it was easy enough  for me to port old bridge to new version of CPG 1.5 .  I've heard that the release of CPG 1.5  might be imminent, so I  tried to release bridge a  bit in advance. 

I'm sure if you included these links in the plugins details then you could increase traffic to your site.

For the moment I don't have the mind to think about this. Even if the bridge is included in Coppermine package, it might need to be updated.
Just recently I've added for instance a better support for community builder users (no more hacks for them).

About the PHPMailer issue:
I've noticed some difference between the class used by Joomla & Coppermine.
Joomla: version used is 1.73, and charset utf-8.
Coppermine: version used is 2.0.3 ,  and charset iso-8859-1

Anyway it's a relatively  minor issue, since lot of people used before  my bridge, and only one user reported by mail he got a problem.
I hope no other class/function conflict will be discovered.

[Nibbler]

It should be safe to just rename the class, right?
Editing include/mailer.inc.php, finding

Code: [Select]

$mail = new PHPmailer();and replacing that string with

Code: [Select]

$mail = new cpg_PHPmailer();Then find

Code: [Select]

class PHPMailer {and replace with

Code: [Select]

class cpg_PHPMailer {Taking a closer look: we have another class named SMTP that might be there two times, so we'd have to rename that as well.

Yes, both need renaming.

Why not? They use PHPmailer as well. Couldn't we just wrap the two classes into corresponding if (!class_exists('class_name') {-code and get away with that? After all, the users of the joomla bridge warp "our" gallery into an entire CMS - the CMS should know what it is doing anyway.

Our copy has changes for Inspekt plus an additional SMTP bugfix that's not in the official PHPMailer release. Theirs probably has changes too. Plus the fact that we may ship totally different versions of the class to each other. It's just asking for trouble to blindly use code we don't control.

[Joachim Müller]

OK, so it's the renaming-schedule. I'm not sure about the impact of renaming the smtp class though, and I currently can not test SMTP. Should we just blindly change without testing or do you have the opportunity to test a renamed SMTP class?

[extrabigmehdi]

@Joachim,
I think renaming will have zero impact on how Coppermine works.
I just made a search though all Coppermine files,  and the string "PHPmailer"
is only used on the file mailer.inc.php .

[Joachim Müller]

I just made a search though all Coppermine files,  and the string "PHPmailer"

I have done so before, I know that. That's why I said

Editing include/mailer.inc.php, finding

Code: [Select]

$mail = new PHPmailer();and replacing that string with

Code: [Select]

$mail = new cpg_PHPmailer();Then find

Code: [Select]

class PHPMailer {and replace with

Code: [Select]

class cpg_PHPMailer {

The word "SMTP" occurs much more often in the code - sometimes as class name, sometimes not. That's why I said

Taking a closer look: we have another class named SMTP that might be there two times, so we'd have to rename that as well.

SMTP is the trickier part.

[extrabigmehdi]

Yes a conflict might occurs with the SMTP class too, as Joomla also use it.
A bit annoying I guess.

[Nibbler]

Renamed both classes, tested SMTP and committed.

[extrabigmehdi]

hi,
could you rename function called deldir in file pluginmgr.php ?
Same function is used by Joomla 1.5 when enabling "legacy mode"
(in joomla, function is located at: plugins/system/legacy/functions.php).

Someone has reported me by mail problem with cpg 1.4x , but obviously there's same
problem with cpg 1.5x.

thanks in advance

[Joachim Müller]

Did as you suggested and replaced local function deldir with global function cpg_folder_file_delete. SVN revision 5998

[dougyang83]

joomla is dead end for me...