Solved. The problem is that there is a bug in the way that Community Builder detects the version of Kunena (detection is based on the presence of a file, which is now also included in the latest builds of Kunena 1.5.xx as well as 1.6)


Two solutions:
1. Delete the administrator/components/com_kunena/api.php file (not recommended, who knows what else will depend on that file later)

or

2. Edit components/com_profiler/plugin/user/plug_cbsimpleboardtab/cb.simpleboardtab.model.php and change the below lines (just search for "Kunena 1.6", it's line 775 in my version):


Before
[code:1]
// Kunena 1.6:
$forumParams->prefix = 'kunena';
[/code:1]


After
[code:1]
// Kunena 1.6:
$forumParams->prefix = 'fb';
[/code:1]

krileon wrote:

You need to edit the Forum integration plugin and ensure Kunena is selected.

Yep as stated in my original reply:
CB's default forum fields are enabled and the forum tab is manually set to Kunena.

It's possible you're missing the following file which is what determines if CB should use the new forum structure or not.

administrator/components/com_kunena/api.php

I will assume you know this entire thread is about Kunena 1.5 and not 1.6. According to the current code, if that file is present it thinks that it's 1.6. That file is present in 1.5 too, so the routine to detect the version is bugged. I've never loaded 1.6 (php version is too low on this server).

Looking for a specific file is a poor method of version detection -- would be better to look for a db value or text within a known file to determine version info.


Existing detection routine
[code:1]
if ( file_exists( $path . '/administrator/components/com_kunena/api.php' ) ) {
// Kunena 1.6:
$forumParams->prefix = 'kunena';
} else {
// Kunena 1.0-1.5:
$forumParams->prefix = 'fb';
}
[/code:1]

Post edited by: robknc, at: 2010/11/24 19:31

One of my techs stated that they tried to load 1.6 on this originally but it failed, so I opened up the api.php file and it does in fact have a date/version from a 1.6 build of Kunena.

This means that Kunena 1.6's installer is bugged or at the very least does a poor job at cleaning up a failed installation. The 1.6 installer dumps the api.php file and creates folders even if the PHP version is too low to install (and the install is aborted).

#1 on my fix list below is the better option it looks like (delete administrator/components/com_kunena/api.php). Would still suggest a different method of detecting Kunena version though



Thanks for the assistance.
Rob

Post edited by: robknc, at: 2010/11/24 19:31

krileon wrote:

Wrong, this is not a bug of the plugin; it is simply behaving as intended.

Then the intended behavior poorly implemented and it could use some work or revisions to make the version detection more accurate. I understand that frequently people come here and blame CB code for everything under the sun, but I feel that this is a valid issue that could be addressed easily by CB, regardless of who's at fault for the issue (user/cb/kunena). Finger pointing is useless, it would be better not to even reply. On a side note, this is the only reason I haven't subscribed to docs here, every post I read has the same finger pointing bs.

This is not Kunenas fault; your PHP failed, not the installation. When PHP has a fatal error then any subsequent PHP fails; so no clean up code could possibly fire. Agreed, there should be a check to test PHP versin, but they likely have what version is required stated on their site and in the install package.

In a perfect world users read the docs and match up versions prior to installing this stuff, in real life I bet the percentage is significantly less than half. The above is a perfect example of finger pointing -- it's not our fault, it's not Kunena's, it must be PHP's! Give me a break.

This issue simply wouldn't exist with a little forward thinking on Kunena's part regarding the cleanup of failed installs, or if CB used a less SLACK way of version detection...


Rob