Installing Libmcrypt on a Godaddy Virtual Dedicated Server

Friday, July 11th, 2008

We recently deployed a web site using ’s virtual dedicated server. Everything about the default installation was fine, except that was not available. When I asked the support staff “How do we enable for ?” their response was far from helpful:

Thank you for contacting Server Support. Unfortunately 3rd party installations and configurations are not supported.

Rather than argue with the support team about what constitutes a 3rd party installation, I decided to google around and see if I could do it myself. Hours later, I succeeded. Here are the steps for installing :

  1. su root
  2. yum install gcc-c++
  3. yum install lex
  4. yum install libxml2
  5. yum install libxml2-devel
  6. yum install flex
  7. wget http://downloads.sourceforge.net/mcrypt/-2.5.8.tar.gz?modtime=1171868460&big_mirror=0
  8. tar -xzvf -2.5.8.tar.gz
  9. cd -2.5.8
  10. ./configure
  11. make
  12. make install
  13. wget http://museum..net/php5/-5.1.6.tar.gz
  14. tar -xzvf -5.1.6.tar.gz
  15. cd -5.1.6
  16. ./configure –with-mcrypt=shared,/usr/local/lib
  17. make (after running ‘make’, DO NOT RUN ‘make install’)
  18. cp modules/mcrypt.so /usr/lib//modules/
  19. Add a file /etc/.d/mcrypt.ini
    ; Enable mcrypt extension module
    extension=mcrypt.so
  20. /usr/sbin/apachectl restart

That’s it! To confirm a successful install, just run phpinfo() and look for the mcrypt section

Setting locale to tr_TR (Turkish) lowercases class names

Thursday, April 3rd, 2008

So I was working away at localizing some pages and for some reason they all worked except tr_TR. What was the problem? The server had an outdated installation with a bug that lowercases class names which ends a fatal error.

Why it it so? After some investigations I came across this bug and came to the conclusion that in the Turkish language, the latin i is not equal to capital latin i.

AWESOME!

WTF!? preg_replace() returns null?

Friday, January 25th, 2008

On one of our sites were were running into a problem when we tried to pass HTML content from a database through an email obfuscation function to prevent spiders from scraping our clients’ emails. We quickly discovered that some of the longer pages were showing up completely blank. The () function we were using to run the obfuscation code on email addresses was returning null. After some hunting I found the answer.

(more…)

ISO Week and Year in PHP and PostgreSQL

Thursday, January 10th, 2008

The new year always brings with it a few small things that go bump in the morning. 2008 was no different. Intervals started behaving oddly on New Year’s Eve morning — the default timesheet was a year behind schedule. What happened?

In our code, we are using the week number of year, as specified on the PHP date function page, but we weren’t using for the year. The week number specifies the last monday of a year as the first week of the new year, if that new year begins before thursday. Intervals thought it was the first year of 2007!

In , the fix was as easy as converting all instances of date(’Y') to date(’o'), according to php.net:

year number. This has the same value as Y, except that if the ISO week number (W) belongs to the previous or next year, that year is used instead. (added in 5.1.0)

That fixed everything on the side of things. But next we had to dig into the queries and get them to use the ISO Year.

Snag.

PostgreSQL 8.2.5 doesn’t support ISO Year in the Extract function. EXTRACT(ISOYEAR, timestamp) is being included in 8.3, as specified here in the RC1 documentation. But 8.3 hasn’t been released yet, and we needed to fix things immediately.

Our final fix was to instead use the TO_CHAR(timestamp, ‘IYYY’) function. It’s not ideal to be using a string formatting function for data comparisons, because it slows down some of the queries. But we had to trade some performance to get things working properly again in the new year. As soon as the PostgreSQL developers release a stable version of 8.3, we’ll change our queries back to using EXTRACT(ISOYEAR, timestamp).

PHP 4 end of life announcement

Friday, July 27th, 2007

The PHP team has announced that they will discontinue support for PHP 4. Now it’s really time to stop procrastinating and upgrade.