CSS Vertical Overlapping of floating divs

I thought this involved some trickiness. I needed to have a row of floating divs have the content underneath it pulled up over it, just a little bit, so that some body tabs appeared to the right of one of the floating images in the header.

After much testing and trial and error I figured out that the content below overlaps the content above depending on the dimensions of the div above it. The content below will STOP overlapping when it hits the image above UNLESS you make the height of the above div (that contains the image/content) to be smaller than the image/content itself. It appears by default, the height of the div containing the image is the same as the image (makes sense).

So the trickiness is in fooling the div below to overlap the div above, when the div below sees the above div as smaller in height than the image it contains.

I’ll post my html in the off-chance that someone can find and use this info.

PHP and MySQL setup on Mac OS X 10.5 Leopard

Full fledged open-source MAMP development environment with php, mysql, and apache on Mac OS X 10.5 Leopard

Goal: A complete php development environment using Mac OS X 10.5 Leopard’s out of the box apache2/php install, and an install of the latest mysql and eclipse software with all the necessary plugins for php debugging. ALL 64-BIT!

Admittedly, it was a challenge to get a fully functioning php dev environment up based on Mac OS X 10.5 Leopard’s configuration. But I succeeded in not installing a separate apache/php 32-bit install, or bailing out to use a linux Virtual Box.

Enabling PHP


This one was pretty easy. Just uncomment out the line

#LoadModule php5_module        libexec/apache2/libphp5.so

in the httpd.conf apache config (/etc/apache2/httpd.conf) so it includes the php5 module that comes with the OS.

Make sure your extension_dir in php.ini points to /usr/lib/php5/extensions/no-debug-non-zts-20060613/ or go nuts and do your own extension directory.

Debugging 64-bit

This was one of the trickier things. You need to get an X-Debug extension setup. Hopefully you can just use my 64-bit extension file, and put that in your extensions directory (/usr/lib/php5/extensions/no-debug-non-zts-20060613/). Then add the zend_extension directive to the php.ini, along with the X-Debug settings, pointing to your (local or remote) host. In your php.ini:

(left bracket)xdebug(right bracket)
xdebug.remote_host=natest.crimereports.com  ; if debugging on remote server, put client IP here

xbedug.so (specific to 64-bit Mac OS X)

If that short version doesn’t work, you need to compile a 64-bit extension from the xdebug source, which was sort of tricky. You’ll need to get a compiler installed on your Mac OS if you haven’t got the right developer tools installed (XCode from the install disk or mac;s website), and then follow the instructions in this article.


Installing MySQL

Use the installer from MySQL’s site, and it goes pretty seamlessly. You may have to edit the php.ini to use the mysql server.

The tricky part of this is if you use a framework, or your code uses the pdo database interface. Again, you can try my 64-bit version, or compile your own pdo_mysql extension. Enable the extension in the php.ini by addin gthe line extension=pdo_mysql.so

pdo_mysql.so (specific to 64-bit Mac OS X)



So there is a Cacao version that is 64-bit. I guess the difference here, as I’ve read online, is that the Carbon version is more stable, but also legacy and in the future will be deprecated soon.

I love using the update site to get plugins. That seemed to work best for PDT php, aptana, SVN (subclipse), and various editors, etc.


I sort of copped-out here when I learned the 64-bit version of eclipse doesn’t work well with Flex-Builder as an Eclipse plugin. I’m planning on installing the stand-alone version of flex builder, and using that separately (a little but resource wasteful, but far more convenient).

Prepared statement errors with PHP 5.3 and mysqli. call_user_func_array returns null. Type error?

Prepared statements using mysqli seems to be having issues with PHP 5.3. I kept getting null from a prepared statement command that worked fine in PHP 5.2, namely, the mysqli_stmt_bind_param

Null means that the array you passed didn’t match the function signature.

The following worked in php 5.2, but when I updated my Mac to Snow Leopard (PHP 5.3 included) the following function stopped working

call_user_func_array(‘mysqli_stmt_bind_param’, array($stmt,’isis’,$args));

I kept getting a null return value (note – different than false). See bottom of the following bug:  http://bugs.php.net/bug.php?id=47554&edit=1

"Returns the function result, NULL for an invalid callback, and FALSE
for all other errors."

Toying with the array (translates to method signature of the callback function) passed to call_user_func_array was key. After much head banging (on desk) and much head banging (to music) I found that the following made my one specific test query work:

call_user_func_array(‘mysqli_stmt_bind_param’, array($stmt,’isis’,(int) $args[2],(string) $args[3],(int) $args[4],(string) $args[5]));

I wonder if the library that mysqli uses is in c (so that mysqli_stmt_bind_param is eventually run at a level where typing needs to be determined), and is requiring typed values that the php is screwing up somewhere in the translation. Or on the mysqli level. And I wonder what other explanations there could be for this behavior.

Usually when code is this buggy it is a developer’s coding errors, but someday I hope to run into a bug that isn’t my fault. On second thought, finding a bug in your development language probably causes a lot more pain in trying to figure it out, so I’m not sure that would be much of an accomplishment.