The Dev Pages

A knowledge base for simple (and beyond) web applications development

Archive for the ‘PHP’ Category




In what was one of the worst bugs I have come across in a while, mainly my fault, I learned the hard way that using the name ‘length’ for an object attribute may be a bad idea. Along the same lines as using ‘window’ as an attribute name. These things tend to cause clashes in framework and javascript libraries.

So more specifically with the yii framework, which uses jQuery to handle gridview filtering, I debugged the hell out of other people’s JavaScript code until I learned from line 59 on the jQuery core library that the each method on a jQuery object uses the length property of a jQuery and javascript object to iterate over its properties.

It goes as follows. Say I have a ‘windowdrape’ table and object. This has a length and width, in inches, of how big the drape is. So I make a ‘length’ column. The yii framework hands my model object off to javascript. So now in javascript I have a windowdrape object. So WindowDrape.length to jQuery is how many attributes the WindowDrape has. I expect it to be how long the window is in inches. So I set it to 98, and now all of a sudden jQuery will iterate the thing 98 times, and the attributes on WindowDrape are all messed up because of the bogus length attribute.

The lesson here, especially if you use the yii framework is Don’t name a column or model object attribute ‘length’. These things are also why I avoid using ‘name’ or ‘window’ etc. for attribute names.




Note: If you have a one-off php script that just needs to shoot out emails, consider using the PEAR Mail class, or something similar. You can just pass it an SMTP server (e.g. that of your gmail account) with credentials (e.g. your gmail login) and it will work swell. See http://email.about.com/od/emailprogrammingtips/qt/PHP_Email_SMTP_Authentication.htm

Note 2: This was done on an ubuntu server using postfix. This assumes you have postfix or sendmail installed on your server. On ubuntu you just do a ’sudo apt-get install postfix’ (or sendmail). To configure your MTA (Mail Transfer Agent e.g. Postfix, sendmail, etc.) to be secure, you’ll need to take additional steps, beyond the scope of this article. If you’re not concerned about the contents of you’re email being sniffed out, you’re probably ok if you’re just using outbound mail (a null client) with no smtp server listening for incoming traffic on port 25. I personally don’t care if a comment from someone using my website is emailed to me in plaintext (but maybe they would). See http://www.n8williams.com/devblog/linux/using-postfix-on-linux-for-sending-only-outgoing-messages for postfix null client setup for just outgoing mail. You can do the same with sendmail, and even kill the sendmail daemons.

Open your php.ini file (ubuntu: /etc/php5/apache2/php.ini) and find the line that says:

; For Unix only. You may supply arguments as well (default: “sendmail -t -i”).
;sendmail_path =

Change this, by uncommenting out the second line, to:

; For Unix only. You may supply arguments as well (default: “sendmail -t -i”).
sendmail_path = /usr/sbin/sendmail -t -i

Where /usr/sbin/sendmail may be a different path for your linux distro. To find it you can issue ’sudo find / -name sendmail’ (note this does a recursive find starting at the root dir so it may take a little while, 7 seconds for me. Ctrl-C to cancel out of it when it finds it). the -t -i options have something to do with using email headers to determine who the email is from, and ignoring weird lines with a period. All I know is it has worked better with these flags. You can research them if you want.

Now here’s the crazy thing that I failed to get at first. If we’re using postfix, then why the hell are we dealing with sendmail_path? Well it turns out that sendmail_path is a common php.ini option, and the sendmail binary is commonly used by all sorts of things. So postfix, when installed, makes a sendmail binary called /usr/sbin/sendmail to be a sort-of backwards compatible sendmail interface for things that expect sendmail (which has been around for a while). So even though your calling upon a binary called sendmail, this is a postfix file. This confused me to no avail when I had installed sendmail first, than uninstalled it with the package m anager, and installed postfix. I was failing to understand why the uninstall didn’t remove the sendmail binary until I realized it was actually a postfix file after reading http://www.postfix.org/sendmail.1.html.

Now restart apache/php and the mail function should work. Let’s hope. There’s a million cluttered google results about all the various reasons why mail() runs, and may hang, but no email gets sent. One key is reading your logs. Get familiar with the mail log. On ubuntu this is /var/log/mail.err, etc.




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.