Running a PC-hosted website and trying to diagnose problems that people might have with Kunena are always difficult. They’re difficult because no-one else can actually see the problems first-hand.

Running XAMPP on a Windows 7 64-bit system (for example) is particularly troublesome.  XAMPP or WAMP don’t like to work on 64-bit Windows systems.  This is the main reason that I abandoned my web development on Windows 7 (64-bit) but I occasionally do some experimentation in Windows 7 (32-bit). The bigger problem that I have—and still not fully resolved—concerns the Windows firewall which makes it virtually impossible—the response times are far too long—trying to access web pages across a Windows-based LAN.  Perhaps these issues don’t occur with UNIX-based servers but I really don’t have the time, energy or motivation to set up a webhosting environment on my LAN.

The problems don’t end there, either, and some problems may be unusual because different versions of this kind of software install unusual implementations of PHP—unusual in the sense that real web-hosted solutions don’t run into those issues.

As a general background to this subject, there are many topics on the Joomla and Kunena discussion forums that help people who want to know how to migrate from J! 1.5. Basically there are three things that need to be moved from your existing website:

1. Joomla users;
2. Kunena forum messages; and
3. Kunena forum attachments.

Migrating from J! 1.5 is not the easiest thing to do and requires good planning beforehand. J! 1.5 is completely different to J! 3.x—the user tables are different, the Joomla articles are different, and the source code used in templates, components, plugins, languages and modules is completely different. Add to this that J! 3.x uses a different security model to J! 1.5 and you can see that you could spend days or weeks trying to update your old website.

For those people who are prepared to spend as much time as it takes to migrate their old J! 1.5 website, this article may not be for you. This article describes the service I can provide if you decide that you do not have the time or skill to this job yourself.

When you install Kunena for the first time it usually works “out of the box” without making any changes to the configuration settings. There are, however, a few changes you might consider making to improve the way your forum works and to make it better for your members.

Based on my own experience using Kunena for several years, this article discusses some of those changes.

“I want to migrate my forum to Kunena because Kunena has a future and, for me, it's the way to go.” Whether we're discussing Kunena or any other web-based forum application, this is probably a question that every website owner has encountered and wants to know the answer to. It's not simply a case of how to convert from “brand-X” forum—and you can substitute product name instead of “brand-X”—to Kunena but it's also a matter of how do you preserve the cultural history of you web community, something that you and your users have invested their heart, their time (and possibly their money) into as well. How do you capture and preserve the essence of the community to keep it alive and to prosper and thrive with the reassurance that Kunena is a product with a future and that it will also support your community as it continues to grow?

Sometimes people don’t want specific details about how to resolve issues on their sites and they only want to ask quick “is it possible” questions. Generally speaking, the answer to these types of questions is yes but depends—

1. if it can be done easily because a built-in feature exists;
2. if something can be modified, changed or customised with CSS;
3. if something has to be changed in the HTML/PHP source code;
4. whether it has been done before or if the person you are asking knows the answer;
5. the complexity of the job;
6. how important it is to you to know the answer, whether you have the technical skill to do this yourself or pay someone to do the job for, and how much are you might have to pay for the solution;
7. your willingness to accept the burden of maintaining any custom changes when you upgrade software on your site; and
8. it may be possible but it may not be ethical or legal.