Important K 1.5 latest posts module - no longer supported or maintained. Do NOT use this with K 1.6!

I have the same problem now, I did what the Mosets Devloper said on his site and I go the Moset tree to work but now my latest forum mod is gone. He said in t the post

In that case, do the same changes above to this file in MT:

/components/com_mtree/mtree.tools.php


I did not set that same code in mtree.tools.php file.

what does he mean.

thanks Jimmy

no one?

Not in my module:
helper.php line 17 So there must be another module which causes this. But which one?[/quote]
Or component/module/plugin/template where is defined other class smile. Not the class from Kunena. Better would be to rename class smile to Ksmile to get rid off these issues.

Blue85 wrote:

Fatal error: Call to undefined function ctype_digit() in /srv/www/htdocs/j/modules/mod_kunena_latest/mod_kunena_latest.php on line 224

It's not my mod_kunenalatest as my name is mod_kunenalatest version 1.0.45 is the latest. If you have mod_kunena_latest it's some different project/different developer -> different support.
You can grab my module and take support from here

I believe line 17 in helper.php should be:
By forcing the default template in the above require_once statement:
...it pretty much ensures class collisions because kunena itself is reading the smile class from the admin-designated template.

The only time it's an issue is when the module is included on kunena pages AND when the admin has selected a template other than 'default'. I have a custom template so it's issue.

Fortunately, I bumped into this on my development machine and avoided this on production because I don't include mod_kunenalatest on the actual kunena pages. I use it as a teaser on other pages.

While developing locally I happened to set the module to 'All' pages and the board wouldn't render because mod_kunenalatest is trying to load the smile class from the 'default' template, then kunena tries to load smile.class.php from another template. The require_once fails to filter out the 2 class definitions because the 2 paths to smile.class.php are different (1 per template).

Hope this helps,
K

kunena.php lines 179-186
You can see, as it's not found in templates default_ex, default_(red|green|gray), it's called from default template. And therefore it is working with kunena distributed templates.
It's tested and it's working on Kunena pages with all kunena distributed templates.

HaND, Jerry

P.S. If somebody has problems with this, please give me account or list of all installed components/modules/plugins/templates. I am almost sure, that other package using own smile class / other kunena package using require/include - that's the reason.

I'll see if I can track it down in my case. I can definitely replicate the issue.

I am running Jomsocial 1.5.248 with the Hello Me Module and I still cannot correct the jquery error when using Kunena Latest. I followed the thread on Jomsocial mentioned some pages back and changed the code but still the same result. I have since reverted the code back to original. If you look at the last page in the post over at Jomsocial there is another code solution that did work however after creating a post in Kunena it trashed the template (default_ex). Obviously, I changed that back to it's original form as well.

Any and all help is appreciated. Site is www.paanglers.com if you need to look at it.

Thanks,

troutspinner

Hi, I went through line by line debugging and in my case,
it hits this line in kunena.php, which is listed above:
require_once (KUNENA_ABSTMPLTPATH .DS. 'smile.class.php');

...it loads the custom smile.class.php from my custom template.

Then it gets to the explicitly declared hard-coded reference to the default template's smile.class.php and blows up with:
Fatal error: Cannot redeclare class smile in /Applications/MAMP/svn/www/components/com_kunena/template/default/smile.class.php on line 31

I get the fact that the distributed templates don't blow up - but none of them have a custom smile.class.php. There's quite a bit of display layer code in smile.class.php so I'm guessing it's possible I'm not the only one with a custom file in my template.

I also did a sitewide 'find | xargs grep' to look for all references to smile.class.php and it appears that the only references I have are
1. some config references in /administrator
2. the conditional you mention in ./components/com_kunena/kunena.php
3. ./modules/mod_kunenalatest/helper.php
4. commented header code in ./components/com_kunena/template/default/smile.class.php
and my custom smile.class.php

If there is a smile.class.php in a custom or modified template, line 17 in helper.php is going to have an issue.

Are you saying that the module is only supposed to work with distributed templates? I would think you could add your own conditional and basically make sure you're doing a require_once on the same smile.class.php file that kunena.php loads.

kirblam wrote:

...it loads the custom smile.class.php from my custom template.

Never tried custom templates. Don't know that there are peoples which modifies smile.class.php.
OK, I will sync loading smile.class.php with Kunena. Will be resolved in next version.