All posts in “PHP”

Phoobox – An MVC Version of PHP Fusebox

Pretty early in my professional programming career, I got hooked on the Lasso/FM stack, which most people probably never heard of… and for this reason I was able to get the Lasso code introduced to the 99 Bottles of Beer website – “One Program in 1,500 variations”. My other contribution at that time was to figure out the right combination of Lasso 3.6.x and FMPro Japanese to produce workable double-byte characters. This was all before the year 2000.

I graduated to ColdFusion and used that for several years. This wasn’t all pain and misery, I did get introduced to the inner workings of the JVM and to the Fusebox 3.0. framework. In its purest form, it was a great way to organize code, but really did not help separate logic from display and things like MVC were off in the distance in Fusebox 4.0+. Debugging was a huge pain as all routes went through a single file so all errors were invariably in the index.cfm file. Grr. When 4.0 came along, the bloat caused me to abandon the framework and I discovered the power of MVC in Mach-II.

I graduated to PHP and saw the near limitless number of frameworks and was lost in a sea of mediocrity. The current state of affairs is much better than it was in 2004. I saw this as an opportunity to port the Fusebox framework to PHP and deal with a lot of the shortcomings I felt needed fixing… and that brings us to Phoobox.

I basically cherry picked the parts of Fusebox I loved (routing, nested layouts, circuit-wide settings) and added object oriented PHP to the mix, giving the framework the true power of MVC. It allowed me to amass a huge library of classes that I could pick and choose for each project and in the parlance of red bull, gave me wings. I’m happy to finally share this framework with the world, but am doing this piecemeal. I want to eventually share my entire class library, but the code must be reviewed and embarrassing comments removed. I will also share some of the advanced capabilities of the framework, such as form rendering and validation; css/javascript tidy, minify, and obfuscation; and templating plugins.

Check out the README.md for more info on Phoobox.

Mountain Lion, PHP and Clang

It seems that Apple has finally ditched gcc and any remnants of it in Mountain Lion (OS X 10.8). This has been a while in coming so should surprise nobody. If you think you have gcc, fire off an ‘ls -la /usr/bin/gcc’ and see the symlink glory.

I’ll write a more comprehensive post on compiling php, httpd, lib*, openssl, etc. when I have the time. But to share the most important piece of the puzzle, you must use the -lresolv flag when compiling php (and make sure to use the darwin 64-bit configure of openssl). You must also have libmysqlclient.18.dylib in the correct place. For some reason, the library load paths in my .bashrc are being ignored. The easiest way to do this is:

#ln -s /usr/local/mysql/lib/libmysqlclient.18.dylib /usr/lib/libmysqlclient.18.dylib

So here is part of my standard php config.nice:

‘export EXTRA_CFLAGS=-lresolv ‘\
‘./configure’ \
‘–prefix=/usr/local/php’ \
‘–with-apxs2=/usr/local/apache-2.2.22/bin/apxs’ \
‘–with-mysql=/usr/local/mysql/’ \
‘–with-mysqli=/usr/local/mysql/bin/mysql_config’ \
‘–with-gd’ \

If you don’t do the above, you’ll most likely result in this error (yes, keyword stuffing):

Undefined symbols for architecture x86_64:
“_res_9_dn_expand”, referenced from:
_php_parserr in dns.o
_zif_dns_get_mx in dns.o
“_res_9_dn_skipname”, referenced from:
_zif_dns_get_record in dns.o
_zif_dns_get_mx in dns.o
“_res_9_init”, referenced from:
_zif_dns_check_record in dns.o
_zif_dns_get_record in dns.o
_zif_dns_get_mx in dns.o
“_res_9_search”, referenced from:
_zif_dns_check_record in dns.o
_zif_dns_get_record in dns.o
_zif_dns_get_mx in dns.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [libs/libphp5.bundle] Error 1

My other post on compiling 64-bit AMP on 10.5.x is surprisingly relevant still.

More soon.

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

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.

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

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.

suPHP Premature end of script headers

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.