Sorting a numeric array of numbers

When called upon, I couldn’t even write out a working version, but this one works.


PHP 4.3.9 $_SESSION values not being retained

Symptoms: After calling session_start() and assigning key-value pairs to $_SESSION, calling print_r($_SESSION) on subsequent pages result in an empty array; i.e. $_SESSION values are not retained across pages.

Solution: Assuming your php.ini (session) save_handler, save_path variables are set correctly, also check if sufficient disk space is available.

I spent 90 minutes trying to resolve the problem thinking it was a PHP-related issue, but in the end, nullifying the 5+ GiB of httpd error logs promptly resolved the problem. Doh!



Singapore PHP User Group Meetup @ Oracle

Attended this yesterday. I was terribly late, but Blair Layton did give a good presentation on Oracle technologies. I do not have much practical experience with websites that require hardware load balancing, a hundred web/database servers so I can’t comment on what 11g brings to the table, but I’ll certain explore the developer DVD they so kindly provided.

Also demo-ed was the Oracle Application Express, which is a step-by-step (simple) web application builder. From a CSV file, a CSS-styled, one-table application with list(sortable)/add/edit/delete functionality was built in a matter of minutes. That’s pretty impressive.

If you’d like to attend more of such events, do check out: The presentation was videoed, so the slides/video should be up on the website fairly quickly.

#oracle, #php

Programmer questions

What is the output for the following 3 code snippets?

$x = 3;

if (4 < $x) {
print "The quick brown fox jumps over the lazy dog.";
} else {
print "She sells seashells on the seashore.";
$x = 1;
$x = ++$x * 2;
print $x;
$x = 1;
$x = $x++ * 2;
print $x;


CodeIgniter: Charset issues

I was having some internationalization (i18n) issues with one of my sites recently. At this (relatively) advanced level of development on the web, I was still using the ANSI charset to encode my views. This was a big problem, as the end-user often used characters that fell outside of ANSI. These characters were somehow being saved correctly in the database, yet were being rendered incorrectly each time. In fact, in Firefox, simply switching to ISO-8859-1 encoding would resolve all issues. But I didn’t want it to be like this, I wanted the browser to use ISO-885901 all the time, rather than having the user switch around.

To solve this problem, I tried four solutions:

1. Use the meta HTML tag.

This did not work at all in my trials. Firefox (or rather: Iceweasel) would switch to Windows-1252, even when I was on Debian 4.0r0. Opera would blithely use UTF-8, but words with accents and graves showed up as a Chinese character! Oops.

2. Use the header() call to set the header; e.g.

header("Content-Type: text/html; charset=UTF-8");

The browser would render the HTML page as plain text instead, no go.

3. Check php.ini to see if any encoding had been set there:

;default_charset = "ISO-8859-1"

Nope… it was commented out, so the developer is actually free to define the charset!

4. The final (and correct) solution lay in Google-ing (but of course):

Turns out that the wget command is really useful, as you can see what character set is being sent out by the server.

$ wget --server-response

Look for the Content-Type flag. My server was setting the content type as UTF-8, whilst my views were saved in ANSI. This resulted in the vast shift in character set, therefore the solution was to open every view and save as UTF-8.

#internationalization-i18n, #php

Codeigniter: Strange Image_lib error resolved

I was writing a CodeIgniter-based app which accepts an image (gif|jpg|png) from the browser and resizes it using calls to Image_lib.php library. Everything was going well on my development machine, even for large (1600×1200 pixels) JPEGs.

Then I got a call informing me that if you uploaded images greater than a certain width/height — size constraint was already in place — the script would fail. A blank page was returned.

I was puzzled since I distinctly remembered that we had taken in larger images before without any issues. I thought it might be the Upload.php library, but then no, the file was being uploaded successfully.

It took some determination to produce the stack trace:

blah::_resize('blah.jpg'); // in blah.php controller
Image_lib::resize(); // ... now in Image_lib.php library
Image_lib::image_create_gd('blah.jpg', 2); // some file, jpg image type
imagecreatefromjpeg(); // called by image_create_gd(): dies at this point

At this point I was sorely wishing that PHP had a better way of setting breakpoints than just using print_r and die. Best is to have a “Watched Expressions” feature so we can really figure out at which point did the script (abnormally) terminate.

Scroll down a little for the answer — my ex-colleague who is an experienced programmer gave me the answer, in like 3 minutes.


The problem was with the php.ini setting memory_limit. It was set to 8M on the staging server, whereas it was 16MB on my development machine. Restarting Apache with the value set to 16MB solved the problem! Gah!

#codeigniter, #php

PHP4 issue (v4.4.5)

I just spent the last 3 hours trying to figure out how come, after upgrading the PHP version on my web server, two websites were broken.

In particular, these two were done using my colleague’s new framework — which is pretty good — but they just wouldn’t work.

Apache2 would prompt to download the .php file, and when I saved it, it was blank. Great. In the 2nd website, the page would be blank instead.

Now, I’m not really very cool about upgrading PHP, in fact I’d much rather get my sysadmin to do it, but tonight called for urgency. Yeah. So it was up to me.

So i used almost the same ./configure parameters except I wanted the imap_* functions:

# ./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-mysql \
--with-curl --disable-debug --enable-ftp --enable-inline-optimization \
--enable-magic-quotes --enable-mbstring --enable-mm=shared \
--enable-safe-mode --enable-track-vars --enable-trans-sid \
--enable-wddx=shared --enable-xml --with-dom --with-gettext \
--with-regex=system --with-xml --with-zlib-dir=/usr/lib \
--with-zlib-dir --with-ttf --with-freetype-dir=/usr/local/include/freetype2 \
# make
# make install

All went fine of course. I tried with different options, with-apxs2, with-mysql and with-imap. Didn’t work as well. Then I sought Google:

“php script downloaded instead of rendered”

Nothing much actually. Maybe it was the search keywords. There was a post on the WordPress forum about Apache, okie so I decided to upgrade Apache as well. Risky, but it was late, so what the heck. Pissed off already. After compiling the new Apache 2.0.x version, I recompiled PHP. Nope, didn’t work.

So I figured I’d to trace the PHP script, comment/uncomment until I came to this one line:

session_register("foo", "bar");

Ahhah! Later I went into the Apache2 logs and lo and behold, there was a segfault error message which I had blithely not thought to read. Yeah. This bug is resolved in CVS, but I’m really pissed now, so I reverted to v4.4.4, and it worked like a charm.


#apache, #linux, #php

PHP5 on Fedora Core 6 (64-bit)

# gunzip -dc php-5.2.1.tar.gz | tar -xof -
# cd php-5.2.1
# ./configure --with-apxs2=/usr/local/apache2/bin/apxs \
--with-mysql \
checking for MySQL support... yes
checking for specified location of the MySQL UNIX socket... no
checking for MySQL UNIX socket location... no
configure: error: Cannot find MySQL header files under yes.
Note that the MySQL client library is not bundled anymore!
localhost# mysql -v
zsh: command not found: mysql

Great! MySQL is not installed! Gotta head over to the MySQL website for more progress. Look for Linux (non RPM downloads), for platform Linux (AMD64 / Intel EM64T).

Now… Linux is really powerful, way more than Windows ever could be IMO but to even have a decent LAMP — that’s Linux, Apache, MySQL and Perl/PHP — for development purposes only going, the learning curve is so steep.

In contrast, I could just get XAMPP and have a development server on Windows running really quickly.

* update *

Yessss… the install for the AMD64 binary went through like a dream! I didn’t even know it was a binary at first:

# gunzip -dc mysql-standard-5.0.27-linux-x86_64-glibc23.tar.gz | tar -xof -
# ./configure
NOTE: This is a MySQL binary distribution. It's ready to run, you don't need to configure it!
Starting the mysqld server.  You can test that it is up and running
with the command:
./bin/mysqladmin version
localhost# Starting mysqld daemon with databases from /root/mysql-standard-5.0.27-linux-x86_64-glibc23/data
STOPPING server from pid file /root/mysql-standard-5.0.27-linux-x86_64-glibc23/data/
070217 16:19:26  mysqld ended

OK, some problems, it started, then stopped on its own. Fine. I looked for INSTALL-BINARY, and lo and behold:

# groupadd mysql
# useradd -g mysql mysql
# cd /usr/local
# mv /root/mysql-standard-5.0.27-linux-x86_64-glibc23/ /usr/local/
# cd /usr/local/
# ln -s mysql-standard-5.0.27-linux-x86_64-glibc23 mysql
# cd mysql
# scripts/mysql_install_db --user=mysql
# chown -R root  .
# chown -R mysql data
# chgrp -R mysql .
# bin/mysqld_safe --user=mysql &
# ps -aef | grep mysql
root     18474  7962  0 16:14 pts/1    00:00:00 /bin/sh bin/mysqld_safe --user=mysql
mysql    18492 18474  0 16:14 pts/1    00:00:00 /usr/local/mysql/bin/mysqld --basedir=/usr/local/mysql --datadir=/usr/local/mysql/data --user=mysql --pid-file=/usr/local/mysql/data/ --skip-external-locking
root     19031  7962  0 16:23 pts/1    00:00:00 grep mysql

Yes… it worked!

Now back to PHP:

# cd /root/php-5.2.1/
# ../configure --with-apxs2=/usr/local/apache2/bin/apxs \
--with-mysql \
--with-libdir=lib64 \
--with-mysql=/usr/local/mysql \
checking for MySQL support... yes
checking for specified location of the MySQL UNIX socket... /usr/local/mysql/data/
checking for MySQL UNIX socket location... /usr/local/mysql/data/
configure: error: Cannot find libmysqlclient under /usr/local/mysql.
Note that the MySQL client library is not bundled anymore!

Hmmm. I installed MySQL server, now I need the client.

# rpm -ivh MySQL-client-standard-5.0.27-0.rhel4.x86_64.rpm
error: Failed dependencies:
perl(DBI) is needed by MySQL-client-standard-5.0.27-0.rhel4.x86_64

Noooooooooooooooooooooooooooooooooooo. Luckily I am familiar with installing CPAN modules. But I wonder why Perl DBI is required?!? Nevermind. Will figure that out again. I guess.

# gunzip -dc DBI-1.53.tar.gz | tar -xof -
# cd DBI-1.53
# perl Makefile.PL
# make
# make test
# make install

Same goes for DBD-mysql, since I am be doing Perl development in future.

# gunzip -dc DBD-mysql-4.001.tar.gz | tar -xof -
# cd DBD-mysql-4.001
# perl Makefile.PL
# make
# make test
# make install
# rpm -ivh MySQL-client-standard-5.0.27-0.rhel4.x86_64.rpm
error: Failed dependencies:
perl(DBI) is needed by MySQL-client-standard-5.0.27-0.rhel4.x86_64

Argh. What’s wrong? Here’s what’s wrong. This is the 3rd time I have encountered issues with 64-bit. So much for bleeding edge. The advice was to skip the dependency checking:

# rpm -ivh --nodeps MySQL-client-standard-5.0.27-0.rhel4.x86_64.rpm

*update2 *

I STILL can’t get php to compile with MySQL support, the error is something like “can’t find libmysqlclient”. Shall skip the –with-mysql options until I can figure out what’s wrong. Google-ing resulted in alot of links but no help so far.

#apache, #mysql, #php, #red-hat

WordPress 2.1

I just downloaded and installed WordPress 2.1 over the weekend. The UI is beautiful.

I would have wanted to develop my own tool (WaynePress, you know), but upon evaluating the competition, I think I just might refrain from this foolish inclination. Check it out:

#php, #wordpress

Connection refused

I was recently put in-charge of overseeing the database server migration — from Oracle to MySQL.

We had all worked really hard, making sure we stick to the schedule as prescribed. Until two days before the final migration, I realised that the web server couldn’t connect to the database server.

“Connection refused” it said.

“It must be the firewall!” I thought. Our client had co-located a web server, a backup web server and their old Oracle database, and we were not managing the firewall, so it was easy to pin responsibility on the much-maligned firewall. Then I looked at the firewall — it was allowing incoming/outgoing connections on the MySQL port, no issue. Hmmm.

So I wrote a script to test for connectivity:

$link = mysql_connect('w.x.y.z:3306:/tmp/mysql.sock', 'wayne-devel', ...);

if (!$link) {
die('Could not connect: ' . mysql_error());

echo 'Connected successfully';

There was no return value, not even the “Could not connect” message. So it was the weirdest thing.

It turned out, in ascending order of heartache:

1. the firewall on the database server was blocking incoming mysql connections
2. the firewall on the web server was blocking outgoing mysql connections
3. PHP was not compiled with mysql support on the web server

ARGH. Well. Better now then later I guess.

#linux, #mysql, #php