The best way to troubleshoot what caused it is to enable the error log and try to reproduce the issue.

Sometimes though the log wouldn't help. It may happen if the error happened in your browser, rather than on the server, or the error was so unexpected that PHP was not able even to write it down.

This article contains solutions to all errors that do not produce any records in the log.

If You're Using PHP v5.3.9+

PHP v5.3.9 introduced a new setting max_input_vars, which is set to 1000 by default. This is less than required by KMP, so you may see the "Connection Lost" message occasionally.

To check if is it issue you're having, go to the Articles > Articles & Categories page in the KMP admin area and press F5 on your keyboard. If you get "Connection Lost", you can be pretty sure that you need to fix this setting.

If you're using PHP v5.3.9 or higher (and under certain circumstances it may occur on PHP v5.3.6+ as well), you can be 100% sure that you need to do this:

1. Open the php.ini file (PHP configuration file)

2. Find the "max_input_vars" setting and set it to 2000:

If you do not see this setting, feel free to add it and the end of the file.

3. Save php.ini.

4.  Restart the web server (just restart IIS or Apache; there is no need to restart the operation system).

There was an issue introduced in Firefox v10. When you're using Firefox v10 or higher in the admin area of KMP, it crashes on Articles & Categories page (and sometimes on some other pages).

There is a simple workaround that helps you to keep using Firefox v10 or v11 with KMP. You just need to adjust one of the Firefox options (in fact, disable one of the things that improves performance a bit, which is not working properly at the moment):

The Workaround

1. Type "about:config" in Firefox address bar and press Enter.

2. It will show a confirmation. Don't worry, click "I'll be careful...". We know what we're doing.

3. You'll see a large list of under-the-hood options. Copy this to the filter field and wait a second: javascript.options.typeinference

It will show you exactly one option:

4. Double-click on it to switch it to "false":

5. Now close all Firefox windows and start Firefox again. It should not crash when you work with KMP now.

Later, when the fix will be included to a Firefox release, you should switch this option back to "true". You will gain about 5-10% performance improvement.

Some Other Workarounds

There are other workarounds that are not so good. You can try them if for some reason the workaround mentioned above doesn't work for you.

• Use a different browser, for example Google Chrome or Internet Explorer
• Roll-back to an older stable version of Firefox. Firefox 9.0.1 works like a charm. Download Firefox 9.0.1 US for Windows. Other languages and platforms. 
• Install and enable Firebug addon for KMP site (see the details below)

If you're not plnning to update the mail program, there is a workaround that you can use. Simply open this file under the KMP folder:

\admin\application\config\config.php

and search for this setting:

By default it is set to \r\n.

And you need to change it to \n:

If you're not sure if the cron job is running on your server, use this guide to troubleshoot this issue.

First of all, check if that is really the case - use this guide to check if cron job is set up and running. Once you are sure that cron doesn't work, proceed with the troubleshooting steps below to find out what caused that and how to fix it.

• If the knowledge base opens via https only
• Check if the cron job is setup to run each 1 minute
• Windows XP/2003
• Windows 7/2008
• Try to run cron from the command line
• Ensure that cron.vbs and php.exe are not blocked
• Check if the URL to KMP has a trailing slash
• If paths contain spaces
• Enable the error log

If the knowledge base opens via https only

If you're using an SSL certificate for secure connection (https), you need to add two lines to the cron.php file.

It is easy to check if you're using SSL. Simply take a look at the browser address bar when a knowledge base page is opened. If it starts with "https://", then you're using SSL. If you've got "http://" there, then you're not.

Check if the cron job is setup to run each 1 minute

Remember that if cron job runs less frequently than once per minute, KMP will still display that "You have to setup cron script..." message. So cron might actually be running correctly, just not as often as expected. Use the instructions below that match your Windows version to check how often cron is set to run on your system.

Windows XP/2003

Go to Start > Control Panel > Scheduled Tasks.

Right-click on the KMP cron task and click Properties.

Then click the Schedule tab on the window with cron task properties. You'll see the schedule.

Click the "Advanced" button.

Check that the Start Date is in the past and that all other settings are the same as on the screenshot above. Pay attention to the part marked on the screenshot. It is recommended to repeat the task every 1 minute.

Save the new settings and hold on a minute. Then check if cron job is now working. If it still doesn't work, proceed to the next step.

Windows 7/2008

Open Control Panel and type "Schedule Tasks" into the search field.

You will see the "Schedule Tasks" link. Click on it.

Find the KMP cron task, right click on it and select Properties.

Click on the Triggers tab.

Select the trigger and click Edit.

Check that the Start date is in the past and that all other settings are the same as on the screenshot above. Pay attention to the part marked on the screenshot. It is recommended to repeat the task every 1 minute. Since there is no option "1 minute" in the selection list, it is a common issue when users select "5 minutes" instead.

You can simply type "1 minute" to the field and it will be accepted as a valid repetition period.

Save the new settings and hold on a minute. Then check if cron job is now working. If it still doesn't work, proceed to the next step.

Try to run cron from the command line

Now let's check if the cron.vbs file is valid.

Go to Start > All Programs > Accessories > Command Prompt.

Copy-paste the full path to php.exe with the two parameters from the cron.vbs (that is what you've got between quotation marks on the second line after WinScriptHost.Run).

Valid command usually doesn't generate any input like shown on the screenshot. So if you do not see any errors, it should be OK and you can proceed to the next step.

If an error has been displayed and you understand what the error means (for instance it may tell you that the path to php.exe is incorrect - so you need to adjust it), try to fix it. Then try to launch the updated command once again. If the error message is unclear, make a shot of your screen (you might need to send it to us for a research) and proceed to the next step. We've got some common errors explained below along with appropriate solutions.

Ensure that cron.vbs and php.exe are not blocked

Open properties of the php.exe file and cron.vbs and make sure that these files are not blocked.

If one of these files is blocked, click the "Unblock" button to unlock it.

Check if the URL to KMP has a trailing slash

Open the cron.vbs and check if the last parameter on the second line - the URL to KMP has a trailing slash.

This is correct:

This is incorrect:

 If the trailing slash is missing, add it, save the cron.vbs file and check if cron is working normally now.

If paths contain spaces

If the path to php.exe or to cron.php contains spaces, it is necessary to take that path into double quotes:

The matching pairs of quotes are shown in the same color in the example above for your convenience.

Enable the error log

Enable the error log, then try to run cron job once again. Check if anything has been added to the log file, which is located in the /admin/tmp/ directory.

If this guide haven't helped or you have any questions feel free to contact our Support Team. Please attach the error log file and the screenshot of the output produced by the cron.vbs file to your email. This will help us to resolve the issue faster. Thank you.

• Black rectangles instead of text
• Chinese characters are not displayed properly (Linux)
• Japanese characters are not displayed properly (Linux)
• It says that PDF library is installed, but it doesn't work at all (Linux)
• Lost images in exported PDF on https:// sites (Linux)
• Lost images in exported PDF and slow performance (Windows)
• whkhtmltopdf library installed with following errors: null

Black rectangles instead of text (Linux/UNIX)

You may get black lines instead of text in generated PDFs.

This means that you do not have proper fonts installed on the server.

Extract the ttf-dejavu folder from the attached ttf-dejavu.zip archive and put it to:

so that you would have the following files (full paths):

Chinese characters are not displayed properly (Linux)

This means that you do not have proper fonts installed on the server.

Extract the two font files from the attached ipa.zip archive and put it to:

so that you would have the following files (full paths):

Japanese characters are not displayed properly (Linux)

This means that you do not have proper fonts installed on the server.

Extract the arphic folder from the attached arphic.zip archive and put it to:

so that you would have the following files (full paths):

It says that PDF library is installed, but it doesn't work at all (Linux/UNIX)

Check if you have uploaded the right version x86 or x64 of the library. You can download each version here.

Try to run wkhtmltopdf from the command line (e.g. SSH). Check if it returns any errors.

If you get the error shown above, it means that you need to install X11 (the xorg package). For Ubuntu it can be done by running the following command:

If you're using some other distribution, check its documentation.

Please note that it doesn't require X11 to run. It is enough to have it installed because wkhtmltopdf library relies on some packages (e.g. libfontconfig) included to X11.

Lost images in exported PDF on https:// sites (Linux)

Exported PDF file may have broken images if you're using Knowledgebase Manager Pro via https://

It happens because the wkhtmltopdf library that generates PDF files may not be able to access images via https links.

To resolve this please install "openssl-devel" package on the server (Linux). There are no reported issues of this kind on Windows systems.

Lost images in exported PDF and slow performance (Windows)

If there are additional restrictions to access the front-end page of the knowledge base (for example Basic access authentication), it is possible that wkhtmltopdf tool will not be able to access images. In this case it will work slowly in futile attempts to load images. The solution to this is to remove the restrictions to the knowledge base pages.

Please note that access restrictions that you set in KMP user interface don't cause this issue. This can be caused only by web site configuration, firewall settings, etc.

whkhtmltopdf library installed with following errors: null

When you go to Administration > General Settings > PDF Export, you get this error:

Please check your phpinfo page. Probably "passtru" function which allows PHP to run shell commands is disabled in PHP settings.

Please enable this function by removing it from the list of disable_functions in php.ini to resolve the issue.

It is most probable that you have Suhosin pack installed over your PHP. It applies certain limits on server requests. Please adjust the following parameters in PHP settings to resolve the problem:

There are two solutions to this problem. Right solution for you depend from what emails have incorrect links:

• Emails sent manually (e.g. "Email to a Friend" email)
• Emails sent automatically (e.g. "Article Subscription" email)

Emails sent manually

When you send an email from a KMP page manually (e.g.: via "Email to a Friend" form),  it inserts the same hostname to the URL as one in the address bar of your browser. For example if you're sending an email from a page on web-site-scripts.com, it will have the article URL with "web-site-scripts.com" domain.

However, if you opened KMP from a local server ("localhost"), the email will have URL with "localhost" for domain, e.g.:

Email sent automatically

The domain part of the URL is taken from the second parameter of the cron job command.

e.g. for Linux/Unix:

e.g. for Windows (cron.vbs):

Solution is the same for all systems - replace "localhost" with correct domain name:

e.g. for Linux/Unix:

e.g. for Windows (cron.vbs):

Correct solution to this issue is:

1. Enable the ExtendedStatus option in the httpd.conf file (Apache configuration file):
   
   ExtendedStatus On
2. And set cgi.fix_pathinfo to 1 in the php.ini (PHP configuration file):
   
   cgi.fix_pathinfo=1

You can ask GoDaddy to enable these options, and if they will refuse to do so, you can use a workaround:

Simply alter the \admin\application\config\config.php file again and change uri_protocol to QUERY_STRING:

In this case you would need to check this setting each time you update KMP, because this file can be overwritten and uri_protocol would be set back to AUTO.

• mapping of KMP and LDAP groups
• LDAP users are unable to login to KMP
• you cannot import LDAP users to KMP
• other issues

Group Mapping Issues

If you do not see any groups under the LDAP Group entry in Group Mappings section, this probably means that you have specified incorrect LDAP connection details.

Check the following settings first:

• Allow Follow Referrals
• LDAP Version 3
• Negotiate TLS
• Base DN
• Connect Username
• Connect Password

LDAP Users Import or Login Issues

If you specify OU (Organizational Unit) in Base DN, make sure that LDAP users that you want to import belong to this OU as well as their parent groups. Otherwise, they won't be imported. Try to remove OU to check if that's the cause of the problem.

Remember that LDAP users that you want to import must have all these required attributes: account name, first name, last name, email. Otherwise they won't be imported. Make sure that attributes here in KMP preferences (LDAP Synchronization Preferences) match user attributes on the LDAP server.

Other issues

KMP has built-in log for all LDAP operations, which helps to troubleshoot any issue with connection to your LDAP server.

To enable the log, edit the /admin/config.inc.php file and change LOG_LDAP_OPERATIONS flag from "FALSE" to "TRUE":

Then try to reproduce the issue (try connecting to the LDAP server if you have an issue with connection, or try to import LDAP users if you have an issue with users import).

Log file will be generated and saved to the /admin/tmp/ folder in this format: ldap_log-YYYY-MM-DD.txt

You can now open this file and check for errors or send it to us for investigation.

1. Enable errors logs as described in this article.
2. Reproduce the error.
3. Submit a ticket to support with the problem description and attach the error log (it is saved in /admin/tmp folder).

Starting from v5.4.0, you can enable all error logging and reporting from the single configuration file. If you're using v5.3.1 or earlier, check another guide.

First of all you need to open this file: /admin/config.inc.php

You will find a lot of different options at the beginning of this file:

The option that you would usually need is LOG_ERRORS, it is highlighted.

To enable logs, set it to "1":

Try to reproduce the error. After that a log file will be generated in the admin/tmp directory. Its name will include current date and ".log" extension.