Prestashop 1.2.x not showing Categories box

Problem: In the front system (FS) Prestashop is not showing the Categories box. In the back system (BS), clicking on the Catalog tab shows just a blank page, or an error message saying the page is unavailible. The probable reason is that your Home category is missing or messed up. The problem is that you can’t get into the Catalog tab in the backend system to fix it. I ended up in this situation by trying to import categories as a CSV (comma/semi colon separated file) and I had a category in that file with ID = 1. Category ID number 1 is reserved for the Home category. Prestashop did not filter this or issue a warning during the import. So take it from me – do not try to import a category with ID = 1. Prestashop table ps_category in phpmyadminSolution: I opened my database with phpmyadmin and went to the ps_category table. The row for id_category 1 was messed up and by comparing it to a backup I set it to: id_category = 1, id_parent = 0, level_depth = 0, active = 1. The dates I left as they were. Then I went into the table ps_category_lang and made sure that there were entries for id_category 1 for all languages that I had installed (I had two in my system). Voila, back and front system now works. By adjusting the ID:s in my category import file (making sure no ID was 1) it worked like a charm to import it.

PHP htmlspecialchars_decode doesn’t handle nordic/german characters like å, ä and ö

The PHP functions htmlspecialchars and it’s reverse htmlspecialchars_decode only handles the following characters:

  • ‘&’ (ampersand) becomes ‘&’
  • ‘”‘ (double quote) becomes ‘"’ when ENT_NOQUOTES is not set.
  • ”’ (single quote) becomes ‘'’ only when ENT_QUOTES is set.
  • ‘<‘ (less than) becomes ‘&lt;’
  • ‘>’ (greater than) becomes ‘&gt;’

If you want to output html text containing nordic/german characters like Å, Ä, Ö and Ü in dialog boxes (popups) these characters also needs to be converted. The following PHP function does this for you:

function unhtml( $string ) {
$string = str_replace ( '&amp;', '&', $string );
$string = str_replace ( '&#039;', '\'', $string );
$string = str_replace ( '&quot;', '"', $string );
$string = str_replace ( '&lt;', '<', $string );
$string = str_replace ( '&gt;', '>', $string );
$string = str_replace ( '&uuml;', 'ü', $string );
$string = str_replace ( '&Uuml;', 'Ü', $string );
$string = str_replace ( '&auml;', 'ä', $string );
$string = str_replace ( '&Auml;', 'Ä', $string );
$string = str_replace ( '&ouml;', 'ö', $string );
$string = str_replace ( '&Ouml;', 'Ö', $string );
$string = str_replace ( '&aring;', 'å', $string );
$string = str_replace ( '&Aring;', 'Å', $string );
return $string;
}

It is important that the code is saved in UTF-8 encoding (or the format your web page is using). Edit the code in for example Windows notedpad and use Save as. Now you can select UTF-8 encoding when saving the file.

Or if you are using UNIX / Linux you can use iconv to convert the file if it is not already in the correct format. First, to find out the current encoding for your file, use the file command:

$ file --mime-encoding unhtml.php
unhtml.php: iso-8859-1

Now, to convert it to UTF-8 using the iconv command:

iconv -f iso-8859-1 -t utf-8 unhtml.php > unhtml-utf-8.php

The reverse of unhtml is of course the html function:

/* Encodes specific characters for display as html */
function html($string) {
  $string = str_replace ( '&', '&amp;', $string );
  $string = str_replace ( '\'', '&#039;', $string );
  $string = str_replace ( '"', '&quot;', $string );
  $string = str_replace ( '<', '&lt;', $string );
  $string = str_replace ( '>', '&gt;', $string );
  $string = str_replace ( 'ü', '&uuml;', $string );
  $string = str_replace ( 'Ü', '&Uuml;', $string );
  $string = str_replace ( 'ä', '&auml;', $string );
  $string = str_replace ( 'Ä', '&Auml;', $string );
  $string = str_replace ( 'ö', '&ouml;', $string );
  $string = str_replace ( 'Ö', '&Ouml;', $string );
  $string = str_replace ( 'å', '&aring;', $string );
  $string = str_replace ( 'Å', '&Aring;', $string );
  return $string;
}
?>

TYPO3 cms installation fails in step 2

If you are installing the TYPO3 content management system (CMS), after uploading the files to your web server and setting some directory permissions, you are supposed to point your browser to your web server’s root where you just have installed TYPO3 in order to continue the installation. A screen similar to this is displayed:

TYPO3 installation step 1

Click to enlarge

Enter database username, password and server (normally “localhost”) and click continue. If the following screen (as step 2) is displayed, you are in trouble:

TYPO3 installation step 2

Click to enlarge

This screen is supposed to show you the availible databases for selection. But as you can see it ends just below the word “Database”. No error message is displayed.

The reason for this is that PHP is running in Safe mode. By configuring your webserver/PHP to run with Safe mode off the installation will work.

This situation is actually described in the TYPO3 Wiki under troubleshooting saying “This could cause the Install Tool to display an error message”. In my case it didn’t and it took some time of head scratching to figure it out.

How to find out what Ubuntu version a system is running

There are two ways:

# cat /etc/issue
Ubuntu 9.10 \n \l

or

# lsb_release -a
Distributor ID:    Ubuntu
Description:    Ubuntu 9.10
Release:    9.10
Codename:    karmic

The latter is slower but gives more information.

Pimp my router! Linksys WRT54GL on steroids… or at least on Tomato

I while ago I got my hands on a Linksys WRT54GL broadband router. This little fellow runs on Linux. Nice, I thought. After fiddling around with it for a while I found that the firmware had bugs.

Linksys WRT54GLI added timed access restrictions (to cut off my teenagers Internet access automatically in the evening). This worked fine until I added another rule that had nothing to do with the first and suddenly my teenagers had Internet access all night long. I also want an incoming VPN connection (PPTP) that I forward by using port forward. This worked fine for a week and of course, it stopped working when I was abroad and needed it the most. Apart from that, there is no telnet or ssh login to the router (it is running on Linux you know).

Read more

MySQL community protests against acquisition by Oracle

The MySQL community around the world are getting worried about the possible acquistion of Sun Micosystems by Oracle. MySQL is community driven and often competes head to head with Sun Microsyftems commercial Oracle products. More than 14.000 MySQL users, developers and enthiusasts have signed a petition sent to regulators at the European Commission, Russia, China and other countries as a protest against the aqcuisition. According to eWeek it might be to late as the European Commission is expected to approve the deal within the next month.

You can sign the petition here to support the protest.

FreeBSD 6.3 end-of-life January 31, 2010

FreeBSDThe FreeBSD 6.3-Release is heading towards it’s End-Of-Life on January 31, 2010. This means the release is no longer supported and maintained by the FreeBSD security team. Users are strongly recommended to upgrade.

Conservative users can upgrade to FreeBSD 6.4-Release (EoL November 30, 2010) or FreeBSD 7.1 (EoL January 31, 2011) which both are extended life releases. Others should upgrade to FreeBSD 7.2-Release or 8.0-Release.

For more information, see FreeBSD.org.

New year – and a little year 2010 bug

The 200x ended and we went into 2010. So we got ourselves a little 2010 bug. It was in the spam filtering software Spamassassin. Or to be more precise in it’s rulesets.

The problem was actually discovered and fixed months ago but someone forgot to include it in the rulesets for Spamassassin 3.2.x. No hard feelings about that. Those guys are doing a great job and shit do happen. It was fixed in a couple of hours on January 1, 2010.

The problem was that all incoming mail filtered by Spamassassin was flagged with FH_PAST_DATE_20XX and given an extra +3.4 spam score which results in false positives.

Those that were running sa-update by cron had this automatically fixed as the updated rules were on the servers around noon on January 1, 2010. Those not running sa-update by cron… still have problems unless they have run sa-update manually. Saying that, running sa-update by cron might be a good idea to keep your Spamassassin rules updated 🙂 A script for doing so and getting a mail with the result can be found here.

Some FreeBSD users reported that sa-update was not able to pull down the updated rules. A manual workaround and links to details around the problem is found here.

FTP not working in passive mode – proftpd, iptables and ISPconfig

If you are using proftpd FTP server together with iptables firewall, which is the case if you for example are using ISPconfig, you will probably have problems using FTP against your server in passive mode. The problem is that the iptables firewall will not allow the incoming connections in passive mode.

The solution is to configure proftpd to use a small, defined range of incoming ports and open iptables for this range.

Read more