Kunena 6.3.2 released

The Kunena team has announce the arrival of Kunena 6.3.2 [K 6.3.2] in stable which is now available for download as a native Joomla extension for J! 4.4.x/5.0.x/5.1.x. This version addresses most of the issues that were discovered in K 6.2 / K 6.3 and issues discovered during the last development stages of K 6.3
Note: Please go to the Kunena Dashboard after an upgrade so that the Kunena database tables are also updated.

Topics that are moved into this category are generally considered to be closed. Users may want to add additional information but these topics should not be resurrected in order to discuss new problems or unrelated matters.

Question Migrating from Kunena 1.5.11 to 1.7.2 broke category manager "add categories" function.

More
12 years 4 months ago #1 by rasharon
Please advise,

I have a Joomla 1.5.25 site that had Kunena 1.5.11 stable running on it.

When installing Kunena 1.7.2 it identified the older version and gave me the option to migrate my database. I did migrate my database and no errors were reported - all steps were reported with a green ok. Outwardly everything looked good.

However now whenever I try to add a new category, Kunena assigns it Id 0 and that apparently violates database integrity.
  • It screws up the nesting / offset display for nested categories - creating additional incorrect indentation (confused over parentage?)
  • When I try to edit that category, it is missing information (e.g. title) but querying the categories table shows the data is there.
  • When I try to save any changes to that broken category I get a duplicate key SQL error on Id 0
  • When I try to add additional categories, I get a duplicate key SQL error on Id 0.

When I delete that new category (that broke the database) integrity appears to be restored, except that no new categories can be added without causing the above errors.

When I restore the database and downgrade back to version 1.5.11 all appears to be working normally again e.g. I can add categories without causing errors.

My configuration info:

This message contains confidential information

Database collation check: The collation of your table fields are correct

Legacy mode: Disabled | Joomla! SEF: Enabled | Joomla! SEF rewrite: Enabled | FTP layer: Disabled |

This message contains confidential information
htaccess: Exists | PHP environment: Max execution time: 30 seconds | Max execution memory: 96M | Max file upload: 10M

Kunena menu details:
Warning: Spoiler!

Joomla default template details : yoo_phoenix | author: YOOtheme | version: 5.5.19 | creationdate: January 2012

Kunena default template details : Blue Eagle (default) | author: Kunena Team | version: 1.7.2 | creationdate: 2012-01-31

Kunena version detailled: Installed version: 1.7.2 | Build: 5215 | Version name: Omega | Kunena detailled configuration:

Warning: Spoiler!

Third-party components: CommunityBuilder 1.7.1

Third-party SEF components: None

Plugins: System - Mootools Upgrade: Enabled | System - Mootools12: Disabled

Modules: None


Please advise of any workarounds or fixes for this problem.

Please Log in or Create an account to join the conversation.

More
12 years 4 months ago #2 by rasharon
I may have isolated fixed the problem.

1. Skimming a LOT of posts in this forum, I finally stumbled one that mentioned

(yoursebsite)/administrator/index.php?option=com_kunena&view=install&layout=schema

to report on schema differences - (expected vs found?)

2. Comparing the scheme differences report to the jos_kunena_... table structures, I found several tables with a primary key of "id" that should be autonum but was NOT. I used MySql administrator to correct all instances where I found that.

That seems to have corrected the categories problem I cited. Too early to tell if it broke (or failed to fix) anything else.

I did notice what may be errors in that schema diagnostic...

Several text fields are defined in the database as not null with default value of "" but the schema checker appears to be looking for not null with no default value.

I left those fields as not null with default "" even though scheme checker doesn't like that.

Some examles:

Schema diff report:

<table name="kunena_announcement" action="alter">
<field name="title" type="tinytext" null="0" action="alter" after="id"/>
<field name="sdescription" type="text" null="0" action="alter" after="title"/>
<field name="description" type="text" null="0" action="alter" after="sdescription"/>
</table>

vs Schema:

<table name="kunena_announcement">
<field primary_key="yes" name="id" type="int(3)" null="0" extra="auto_increment"/>
<field name="title" type="tinytext" null="0" default=""/>
<field name="sdescription" type="text" null="0" default=""/>
<field name="description" type="text" null="0" default=""/>
<field name="created" type="datetime" null="0" default="0000-00-00 00:00:00"/>
<field name="published" type="tinyint(1)" null="0" default="0"/>
<field name="ordering" type="tinyint(4)" null="0" default="0"/>
<field name="showdate" type="tinyint(1)" null="0" default="1"/>
<key name="PRIMARY" unique="1" columns="id"/>
</table>

Another example:

Diff report:

<table name="kunena_categories" action="alter">
<field primary_key="yes" name="id" type="int(11)" null="0" extra="auto_increment" action="alter"/>
<field name="description" type="text" null="0" action="alter" after="hits"/>
<field name="headerdesc" type="text" null="0" action="alter" after="description"/>
<field name="class_sfx" type="varchar(20)" null="0" action="alter" after="headerdesc"/>
</table>

vs Schema report:

<table name="kunena_categories">
<field primary_key="yes" name="id" type="int(11)" null="0" default=""/>
<field name="parent" type="int(11)" null="1" default="0"/>
<field name="name" type="tinytext" null="1"/>
<field name="cat_emoticon" type="tinyint(4)" null="0" default="0"/>
<field name="locked" type="tinyint(4)" null="0" default="0"/>
<field name="alert_admin" type="tinyint(4)" null="0" default="0"/>
<field name="moderated" type="tinyint(4)" null="0" default="1"/>
<field name="moderators" type="varchar(15)" null="1"/>
<field name="accesstype" type="varchar(20)" null="0" default="none"/>
<field name="access" type="int(11)" null="0" default="0"/>
<field name="pub_access" type="tinyint(4)" null="1" default="1"/>
<field name="pub_recurse" type="tinyint(4)" null="1" default="1"/>
<field name="admin_access" type="tinyint(4)" null="1" default="0"/>
<field name="admin_recurse" type="tinyint(4)" null="1" default="1"/>
<field name="ordering" type="smallint(6)" null="0" default="0"/>
<field name="future2" type="int(11)" null="1" default="0"/>
<field name="published" type="tinyint(4)" null="0" default="0"/>
<field name="checked_out" type="tinyint(4)" null="0" default="0"/>
<field name="checked_out_time" type="datetime" null="0" default="0000-00-00 00:00:00"/>
<field name="review" type="tinyint(4)" null="0" default="0"/>
<field name="allow_anonymous" type="tinyint(4)" null="0" default="0"/>
<field name="post_anonymous" type="tinyint(4)" null="0" default="0"/>
<field name="hits" type="int(11)" null="0" default="0"/>
<field name="description" type="text" null="0" default=""/>
<field name="headerdesc" type="text" null="0" default=""/>
<field name="class_sfx" type="varchar(20)" null="0" default=""/>
<field name="allow_polls" type="tinyint(4)" null="0" default="0"/>
<field name="id_last_msg" type="int(10)" null="0" default="0"/>
<field name="numTopics" type="mediumint(8)" null="0" default="0"/>
<field name="numPosts" type="mediumint(8)" null="0" default="0"/>
<field name="time_last_msg" type="int(11)" null="1"/>
<key name="PRIMARY" unique="1" columns="id"/>
<key name="parent" columns="parent"/>
<key name="published_pubaccess_id" columns="published,pub_access,id"/>
<key name="msg_id" columns="id_last_msg"/>
<key name="category_access" columns="accesstype,access"/>
</table>

Regardless, it seems that the migration from 1.5.11 to 1.7.2 is NOT properly setting all the necessary attributes on the new jos_kunena_... tables it creates.
The following user(s) said Thank You: sozzled

Please Log in or Create an account to join the conversation.

More
12 years 4 months ago #3 by sozzled
Thanks for that information, rasharon (although I'm not personally sure what I can do with it), and I'm trying to attract the attention of the Kunena development team to your issue. I can say, from my own experience, that I've successfully upgraded K 1.5.x to K 1.7.x quite easily and without the issues you've mentioned. I vaguely recall that, once upon a time, I struck a problem upgrading from K 1.5.9 to K 1.6.0-beta (I think) but we resolved that issue relating to a database schema inconsistency and that the installer procedure was modified because of the problem that I had encountered. But this was, like, about 18 months ago and we haven't had any issues reported since then.

From the overall sounds of things, you've fixed your problems. I'm sorry that, in your case, the upgrade was not a totally smooth operation. I hope that others will learn from your experience.

As far as I know, the upgrade to K 1.7.2 (from any of Fireboard, K 1.0.x, K 1.5.x, K 1.6.x) should be a two-mouseclick set-and-forget matter.. Sometimes it's not. Oh well, these things happen.

Please Log in or Create an account to join the conversation.

Time to create page: 0.489 seconds