Dreaming Of Beetles

A Misanthropic Anthropoid With Something to Say

Archive for the ‘PHP’ Category

The Proper Way To Use UTF-8 (PHP/MySQL)

Posted by Chris Latko On July - 2 - 2009

phpAfter living in Japan for six years and doing web programming for most of that time, you would think I would have this down by now. I used many combos – from Lasso/FileMaker to PHP/MSSQL and even PHP/PostgreSQL – but never used PHP/MySQL for any CJVK work. So I did some Googling and found four pages that claimed to have the answer:

  1. Use UTF-8 No BOM for each page. That is Byte-Order Mark, which does help in other languages like Cold Fusion, but not for me in PHP. NOPE!
  2. Use a PHP header tag:
    header('Content-Type: text/html; charset=utf-8');

    and use a HTML meta tag:

    NOPE!

  3. Use SET NAMES ‘utf8′; when instantiating your database object. NOPE!
  4. Change the column to utf8_general_ci and the collation to utf8_general_ci. NOPE!

I saw that PhpMyAdmin was displaying the characters correctly, so how were they doing it? I did a deep dive into the code and wound up at the mysql dbi connector where the following statements were set for EVERY query:

mysqliObj->query("SET CHARACTER SET 'utf8'");
mysqliObj->query("SET collation_connection = 'utf8_general_ci'");

This, along with the column set to utf8_general_ci did the trick. The processing pages were set to Western (Mac OS Roman) which did not cause any problems inserting or displaying Japanese data.

This post is more for myself so I don’t ever forget how this is done. This can be black magic sometimes so I need some documentation.

Popularity: unranked [?]

Compiling 64-bit Apache/PHP on Mac OS X 10.5.6

Posted by Chris Latko On January - 31 - 2009

Update: The below installation still works on Snow Leopard with PHP 5.3. You can use the latest and greatest of each library/project below and it will still work. However, there is one gotcha. There is a bug somewhere (PHP blames Apple and vice versa) when compiling PHP. To get around this, run the following on the command line before the ./configure string:

# export EXTRA_LIBS=-lresolv;

I will update this with a new tutorial once I compile everything with Clang.

Warning: This installation was not done on a virgin machine. Everything has been tested and works on my heavily hacked system.

Ok. We’re going to compile Apache with PHP on OSX 10.5.6. To make things interesting, we’re going to do a 64-bit install. If you don’t know if your machine is 64-bit or not, follow this rule: Core Duo == 32 bit, Core 2 Duo == 64 bit. I haven’t found a way to reliably display the chip architecture from the OS X command line, but on most GNU/Linux variants, you can use lshw. On the mac, you can try `uname -p`, `arch`, `system_profiler SPHardwareDataType` but all of this will make you think you are running 32 bit. As the man page for `arch` states:

The most common use is to select the 32-bit architecture on a 64-bit processor, even if a 64-bit architecture is available.

So everything is defaulted to 32-bit. What we need to do is set some environment variables so gcc knows the architecture we want to compile against. Another thing, I’m going to do all of this as root (back off unix weenies – I know what sudo is and use it regularly, I’m not here to argue about this). You can do this with the following (the # represents the prompt):

# MACOSX_DEPLOYMENT_TARGET=10.5
# CFLAGS="-arch x86_64 -g -Os -pipe -no-cpp-precomp"
# CCFLAGS="-arch x86_64 -g -Os -pipe"
# CXXFLAGS="-arch x86_64 -g -Os -pipe"
# LDFLAGS="-arch x86_64 -bind_at_load"
# export CFLAGS CXXFLAGS LDFLAGS CCFLAGS MACOSX_DEPLOYMENT_TARGET

I’m also going to ratchet up the complexity a bit because I need a GD library, IMAP, iconv, and OpenSSL. So here goes:

1) Grab All The Tarballs
Here are the links to the tarballs needed. Most of these you can grab with `curl -O` or `curl -O -L` to follow a redirect:

I’m not going full bore with the GD Library here, I just want to create some basic graphs, manipulate images, etc. so I’m not getting XBM or WBMP. I’m going to download all this stuff into /usr/local/src/.

2) Compile The GD Libraries
First we’ll start with the GD libraries as these are pretty straight forward and shouldn’t give you any problems. When on the `make` step of each of these libraries, you’ll see the familiar “-arch x86_64″, this means we’re doing it right.

FreeType

# tar -xzvf freetype-2.3.8.tar.gz
# cd freetype-2.3.8
# ./configure
# make
# make install

libjpeg

# tar -xzvf jpegsrc.v6b.tar.gz
# cd jpeg-6b
# ./configure
# make
# make install

libpng

# tar -xzvf libpng-1.2.34.tar.gz
# libpng-1.2.34
# ./configure
# make
# make install

t1lib
You will need to modify the “configure” file after you untar the file. So open “configure” and modify line 8656 to read:

archive_cmds='$CC -arch ppc -arch ppc64 -arch i386 -arch x86_64 -g -Os -pipe -dynamiclib $allow_undefined_flag -o $lib $libobjs $deplibs $compiler_flags -install_name $rpath/$soname $verstring'

The architecture types must be explicitly stated for configure to work properly. There is an alternate method of modifying the resulting Makefile, but I won’t go into that. Commands are:

# tar -xzvf t1lib-5.1.2.tar.gz
# cd t1lib-5.1.2
# vi configure (make changes above)
# ./configure
# make without_doc
# make install

Some of these installs might give you lip about certain directories not being found. Make sure you have the following directories on your system:

/usr/local/include
/usr/local/bin
/usr/local/lib
/usr/local/man/man1

3) Compile OpenSSL
Since many components rely on this. We want to get it compiled and in place fairly early.

# tar -xzvf openssl-0.9.8j.tar.gz
# cd openssl-0.9.8j
# ./config --prefix=/usr/local/ssl
# make
# make install

4) Compile IMAP
This is pretty easy, but some extra steps need to be taken because make install doesn’t seem to exist:

# tar -xzvf imap.tar.gz
# cd imap-2007e
# make oxp
# mkdir /usr/local/imap
# cp -pr c-client /usr/local/imap/

5) Compile libicon
A very useful library that doesn’t seem to get much love. This will convert between character sets (UTF-8, etc.). Maybe dealing with Japanese characters for so long gave me this appreciation.

# tar -xzvf libiconv-1.12.tar.gz
# cd libiconv-1.12
# ./configure
# make
# make install

6) Compile Apache
This assumes you already have MySQL on your machine. The 64-bit package installer at http://dev.mysql.com/downloads/ should be all you need to install this. I would stick with 5.0.x even though 5.1 is GA (Monty of MySQL fame has some choice words about this). Even though I love compiling my own apps, MySQL does such a good job with their installer, I’ve left it to them for the past couple years.

# tar -xzvf httpd-2.2.11.tar.gz
# cd httpd-2.2.11
# './configure' '--prefix=/usr/local/apache2.2.11' '--with-included-apr' '--enable-module=most' '--enable-shared=max' '--enable-headers' '--enable-rewrite'
# make
# make install

A couple things to note:

  • You normally don’t have to explicitly state which apr to use, your system will figure this out. I had a version installed by darwin ports for subversion and the compiler wanted to use that one and would choke (this is Versions‘ fault).
  • You don’t need the enable-headers and enable-rewrite. I like to do funky things like mod_rewrite for pretty URLs and mod_proxy for Tomcat. Choice is yours.
  • From httpd-2.2.9, the configure options got all out of whack with slight syntax modifications to some important flags. To normalize this, you need to run `./buildconf` in the src directory before configuring. Seems like things are back to normal for 2.2.11.
  • In my config string, I spell out which version of the software I’m using – apache2.2.11 – then later symlink /usr/local/apache2 to /usr/local/apache2.2.11. This is useful for running multiple versions.

7) Compile PHP
The final step. Here is where you’ll be able to see if you’ve done everything above correctly.

# tar -xzvf php-5.2.8.tar.gz
# cd php-5.2.8
# './configure' '--prefix=/usr/local/php' '--with-apxs2=/usr/local/apache2.2.11/bin/apxs' '--with-zlib=/usr' '--with-mysql=/usr/local/mysql/' '--with-mysqli=/usr/local/mysql/bin/mysql_config' '--with-gd' '--with-png-dir=/usr/local/php' '--with-jpeg-dir=/usr/local/php' '--with-freetype-dir=/usr/local/php' '--with-t1lib=/usr/local/php' '--with-xmlrpc' '--with-pear' '--enable-mbstring' '--enable-cli' '--with-curl=/usr/local/' '--enable-soap' '--with-openssl=/usr/local/ssl/'
# make
# make install

Some things to note:

  • You may not need all these compile options. Pick and choose what you feel you need.
  • I compiled my own version of curl, but you can leave this out of the config string if you are ok with the default OSX curl. I’m a huge fan and power user of curl. Maybe someday I’ll write about what that means.

Other Configuration Stuff:

  • Change user/group to www:www in conf/httpd.conf
  • I’m not going to get into it too much, but make sure you compare your old httpd.conf file (/etc/apache2/httpd.conf) with the new one. There are several Apple specific directives in there to keep your webserver safe.
  • Make sure to add support for mod_php:

<IfModule mod_php5.c>
AddType application/x-httpd-php .php
AddType application/x-httpd-php-source .phps
</IfModule>

  • If you want this new version of Apache to start automatically at startup, make sure it is enabled in sharing, then do this:

# cd /usr/sbin/
# mv apachectl apachectl.bak
# ln -s /usr/local/apache2/bin/apachectl apachectl

Now fire up apache and load a page with <? phpinfo(); ?> to see that everything has installed correctly.

I’m more than happy to answer any questions you have about this process, so fire away!

Warning: This installation was not done on a virgin machine. Everything has been tested and works on my heavily hacked system.

Popularity: unranked [?]

suPHP Premature end of script headers

Posted by Chris Latko On January - 19 - 2009

I don’t really advise using suPHP these days when the power and flexibility of mod_php will handle most of your needs. However, for a shared dev environment where you want to specify the apache user in the config file, suPHP works pretty well.

There is one major problem with it though and that is the logs fill up pretty fast and once you hit a 2GB log file, apache will start throwing 500 errors. The first thing people check are the apache log files and see the dreaded “Premature end of script headers”. And since this offers no other useful info, you go search on Google for what the hell this means. Google comes back with the official suPHP site which gives you some mumbo jumbo on CLI versions being installed in the place of CGI versions. But you know this isn’t the case, because you haven’t touched the machine in months and everything was working fine. You panic.

Most of the other stuff Google brings back are threads of people panicking because these 500 errors are being thrown on live sites. Some threads suggest you look at the log files. And this is good advice. However, there are a couple things to watch out for:

  1. usually the suphp.log file is the culprit. It lives in /var/log/suphp.log. If this has hit 2GB, roll it and apache will be good to go.
  2. there is no suphp.log file in /var/log. In this case, check your suphp.conf file for the location. The conf file is usually located in /etc/httpd/suphp/ or similar.
  3. if your conf file is pointing to a log file that is under 2GB, you need to dig a tad deeper. Check out your php.ini file and see if/where you are saving your php error file. Check if this file is over 2GB.

If the above doesn’t solve the problem. You need to take some drastic measures and find all files on your system that are 2GB or larger. The “find” command will work nicely for this.

Popularity: unranked [?]

About Me

Interested in all things tech. Apple, iPhone, OSX, Xcode, LAMP, Obj-C, Cappuccino, Atlas, Sproutcore, JavaScript, Ruby, Python, GNU/Linux.

Twitter

    Photos