PHP and buttons

PHP correctly reports the value of a "type=submit" button in the $_POST array. But if you use a type=button button (eg because you want to validate data before deciding whether to submit) then the value of the button pressed is NOT present in the $_POST array - the button name isn't in the array at all.

Not a big deal (easy enough to set a hidden value, assuming that you use Javascript) but that didn't stop me wasting a lot of time trying to work out what I was doing wrong.

PHP rendering differently from View-Source HTM

One of the obvious things to do when tackling appearance problems on a PHP page is (on Firefox) to use the "Web Developer" addin's "View Generated Source" function, copy the HTM and then save it in a separate HTM file. Then remove chunks of the page to isolate the problem.

But it isn't always that simple. Today I did this, and found that IE6 rendered the PHP version badly, but the HTM version perfectly. The error turned out to be a missing close-span tag - and I suspect that the inconsistency between PHP and HTM was because Firefox had not only forgiven the missing tag, but corrected it too.

Smarty variables in CMSMadeSimple

Smarty (template system) within CMSMadeSimple lets you set and retrieve variables WITHIN THE HEAD of a document. But try reading that variable after the /head tag and the value has gone!

Re-assign them after the body tag,  and then you can read them elsewhere in body - but there doesn't seem to be a ready way to transmit values from head to body

Even assigning a php variable doesn't get over the problem.

When Firefox shows SELECTED values that are different from those shown in the Source

Another quirk that cost me hours:

Firefox can be "two-faced" in the way it handles SELECT (or Combo) boxes if you have errors on your page.

Try View Selection Source (or use Web Developers' View Source or Inspect Element) and the code looks perfect. And the boxes lay out nicely and show the right list of options. BUT look at which items are ACTUALLY selected, and they aren't the same ones that show with selected="selected" in the source.

Fix the errors elsewhere on the page and all works as you would expect!

Sortable.create - Sortable is Not Defined

The DragDrop capability offered by Scriptaculous is tremendous, but is not good on error messages. What does one do with the error "Sortable is Not Defined" on a "Sortable.create" statement?

The answer, from my experience, is to look hard at the coding of the page. When I have hit this problem it has normally (perhaps always) been because "echo" statements for debugging had resulted in a page source which showed the "body" tag appearing far sooner than I had intended, and that seemed to be what was spooking the Sortable.

vertical-align - ok on td but not table (or tr or tbody)

The vertical-align css property appears to be valid only at a td level. There is a hint of this (but not explicit statment) in the w3.org documentation

Styling select options using span or strong?

Searching around, it looks as if this cannot be done in HTML with or without CSS.

To quote :

option tags do not allow other tags within them (it's not valid html).
firefox, for example, simply removes them from the DOM when it renders it. 

It's easy to style the whole option tag. What you don't seem to be able to do is to style just part of an option.

The application was a list of users within our village. Name formats will vary, and it won't always be obvious which is the right one to sort on. Eg "Newtown Tennis Club" might be known just as the "Tennis Club". The solution was to specify a separate sort name for each user, and to sort the options in that order. I wanted to highlight the sorted term in bold: cannot do. Capitalising is the best I have been able to do.


Isn't HTML a pain?