Category Archives: Coding

The Coding Blacklist. No 52: PHP array_search

PHP has a few “gotchas” which have bitten me in the past. I just got bitten again, today!

I used this PHP code:

$foods = Array();
$foods[] = 'ice cream';
$foods[] = 'hamburger';
$foods[] = 'brussels sprouts';

function do_important_things() {
	echo 'Important!';
};

if (array_search('ice cream', $foods)) {
	do_important_things();
}

I banged my head against the wall for a few minutes when the do_important_things function never got called. I printed out the $foods array and could see that 'ice cream' was in it. So, array_search should return true, right?

So what was going on? Go figure it out for yourself if you want…. or scroll down to get the quick answer.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

PHP’s array_search returns the key of the first value that was matched in the array. Since 'ice cream' had key zero (first item in the array), 0 was returned. In PHP, 0 evaluates to FALSE when it is used in a boolean sense. Like here. They kind of warn you about that in the array_search documentation, but who looks up the docs every time they use an array function?

I kind of went ‘Doh!’ when this happened, because I’ve had this experience once before. I’d just forgotten it. This is a case where an editor plugin might help, but I don’t know of any good solution, except to be careful when using PHP array functions.

Got comments? Send me an email at fullstackdev@fullstackoasis.com. If you found this interesting, you can hit the subscribe button above. I write a new post about once a week.

Quirks of HTML forms – can you GET and POST at the same time?

TL;DR: You can effectively GET and POST information using a single form. The trick is to set a query string in your action – the form is still POSTed, but the server will see the query string as GET data. Also, if a user comes to your web page with a query string already set, that query string will be retained when POSTing a form, as long as you use the empty action (action="") for your form.


HTML forms are a rudimentary part of web deveopment, but you can be productive implementing them without a lot of specialized knowledge. That’s a plus and a minus, since there are some “gotchas”. Here is a quick review of some things that might have escaped your notice.

an empty action attribute?

You can add a form to a page simply by enclosing some content with the <form> tag. This tag does not require any attributes. Here’s an example:

<form>
  <div><label>topping: <input></label></div>
</form>

In this example, nether the method nor the action attribute are specified. What happens in this case? Can this form be submitted? Here’s a sample page which has only this form on it so you can experiment with it. (The quick answer is yes, the form submits in Chrome, but no actual data is submitted, so the form is not useful.)

In this next example, the form also has no attributes. However, the input is named – it has a name attribute, like this:

<input name="topping" value="pepperoni">

Take a look to see if this example with a named input works to send request data to the server. (It does! You will have to type something into the form and hit enter for it to work.)

Here’s a page which submits two variables, “topping” and “crust”, using a blank form (<form>), again. Does it work? Try it! (The quick answer is “no!” – even though both inputs are named.) I only tested this in Chrome, and I don’t think the spec is clear about how to deal with this case. It does show you that it’s important to be very clear about the contents of your forms. In this case, adding a submit button fixes the problem. Here’s a demo which fixes the problem by adding the submit button.

be specific

Given the quirkiness of those forms above, usually you will want to specify the form’s method and action attributes, and also name all the inputs, like this:

<form action="topping.php" method="POST">
  <div><label>topping: <input name="topping"></label></div>
</form>

Notes about the action:

  • The action should be a valid URI; the spec doesn’t say what will happen if your URI is not valid.
  • URIs can be relative, like ../pizza.cgi or customer.php.
  • Important: the URI can include a query string, like ../pizza.cgi?topping=pepperoni.
  • If the form’s action is the empty string, then the action defaults to the URL of the document that contains the form – the URL of the page that you’re currently looking at. I couldn’t find anything in the spec that says what happens if the form does not even specify the action. I think most browsers treat this as the empty string.

Here’s a page which contains several different forms, with different actions set. You can play around with that demo to see how the different types of action attributes work.

what about that query string?

If a user comes to a web page that has a query string, and your form’s action is empty, then when you submit the form, the URL for the resulting page will contain the original query string (the address bar will show the URL with the query string). Here’s an example – this link has a query string, and the form on the page has an empty action. Notice that when you submit the form, the server sees both GET data and POST data. Try it!

So this is a quirk when using a form with an empty action attribute. It will retain the query string with which the user came to the page – this can be useful when sharing links. Some users will copy the URL in the address bar for sharing, and if that query string is important for what displays on the page, you want it to remain even after a form submission.

It’s also useful for reloading a page. If a user submits a form using a POST, and then tries to reload the page, they’ll get a question asking them if they want to re-POST the data. If the user doesn’t want to re-POST, but does want to reload the page, then they can copy the URL – including its query string – and paste it into the browser’s address bar, and hit enter to avoid the re-POST.

Got comments? Send me an email at fullstackdev@fullstackoasis.com. If you found this interesting, you can hit the subscribe button above. I write a new post about once a week.

difference between == and === in javascript

The “triple equal”, “===”, is a strict comparison operator in JavaScript. It is used to compare two “things”, and returns either true or false.

The “double equal”, “==”, is an abstract comparison operator. It is also used to compare two “things”, and returns true or false.

They seem like the same thing! So, what’s the difference between “===” and “==” in JavaScript? And how do you remember which is which?

abstract comparison operator ==

When the “==” operator is used, the two operands – the things being compared – are converted to the same type by JavaScript before comparing.

This can be a source of some headaches! If you don’t realize that the two operands are actually being “messed with” before the “==” comparison occurs, you’re going to find this operator very confusing at some point!

You should mosey on over to the ECMAScript 5.1 specification, where the abstract equality comparison operator is explained.

Go ahead, take a look! Notice that there are 10 logic steps that are considered in computing the result of this operator, and the first one has 6 different substeps. It starts to become clear why the “==” (double equal, abstract equality comparison operator) can lead to “gotcha” bugs in code!

I am not going to quote the ECMAScript spec here, nor am I going to explain it in detail. Instead, I will give a couple of examples:

var a = ("1" == 1); // a is the boolean true
var b = ("true" == true); // b is the boolean false

If you aren’t already familiar with this behavior, the fact that ("1" == 1) is true may come as a surprise. And given that ("1" == 1) is true, it seems non-intuitive that ("true" == true) is false! This is where bugs can creep into code. For example, suppose an object {"custom" : "true"} is sent from the server to your client in the web browser, and the code to check for this custom option reads:

if (obj["custom"] == true) {
    doSomething();
}

The bug report says that when some custom option is checked, the doSomething method is not called, but it should be. So you start by printing out the value of obj["custom"], and you see true in the JavaScript console… how is that possible? Pain ensues!

strict comparison operator ===

In contrast, let’s take a look at what the spec says about the strict equals operator. There are 6 logic steps for this operator, and no substeps. It’s still not 100% straightforward (what’s that stuff about GetValue)? However, it’s definitely a bit less confusing.

Let’s look at how the triple equal plays out in the above code snippets:

var a = ("1" === 1); // a is the boolean false
var b = ("true" === true); // b is the boolean false

At least to me, these results seem much more obvious than the ones using “==“.

a mnemonic for remembering the difference

It’s difficult to get a truly intuitive feeling for what values will be returned by these two operators. However, I have a mnemonic that I use to help me. The three equal signs in the strict equals operator make me think “really, really, really!”. As in, the two operands are really, really, really equal. In particular, there’s no type conversion before the comparison. So if one operand is a string and the other is a number, you will always get false. On the other hand, the == operator will return true even if the two operands are “sort of” equal. That’s the way I think of it.

I almost never use the double equal, abstract comparison operator. In fact, I cannot think of the last time I used it! It strikes me as a source of hard-to-uncover bugs. And it’s hard to remember all the rules when using ==. However, I do know that there’s a difference between the two different operators. I think that’s the most important thing: experienced JavaScript developers should be aware that there’s a difference, and have a pretty good idea of what that difference is, even if they can’t quote the spec on it. If you’re a person who has expertise in several different languages, it gets hard to keep track of the finer details of a language. But you can still be very productive as long as you keep in mind some fundamental principles. In this case, make sure you notice when == is used and when === is used, be careful about which way you use them, and if you’re looking for a bug, keep in mind that the comparison operator is a place to check for the problem.