I just spent a half hour narrowing down a bug in an application I’d fut some polishing touches on in PHP5. When it was moved onto the production server earlier, it came up with blank pages. I wasn’t on hand to check it out, so couldn’t help over the phone. I had to wait until I could get to a computer to debug it.
The end problem was in a line similar to the following:
$n=$db->query('select id from some_table')->numRows();
The above worked in every server I had available – except the one it was supposed to go on.
To get that code working in PHP4, you must break the object results down:
$n=$db->query('select id from some_table');
It’s an annoyance – but at least it’s not a large thing to fix, and the lines that need changing can easily be found by grepping for numRows().
IE6 and IE5 do not support CSS2’s ‘:before‘. This is a pity, as it allows some pretty cool stuff to be done.
I’m currently working on an InkJet cartridge supplier’s website. One of the elements that the designer came up with is panels that have an interesting border effect at the top:
The image above is a screenshot taken with Firefox. The code to produce that effect was:
background:transparent url(/extras/i/panelcorner.png) right top no-repeat
border:1px solid #8c8c8c;
background:url(/extras/i/paneltopbar.png) top repeat-x
Note that there are three images mentioned. The two corner images are provided with the :before construct (you can use the same method to do rounded corners), and the background gradient is provided by the main element.
In order for the background gradient to show, it is important that the :before pseudo-element be truly transparent, as defined in the CSS. Unfortunately, the IE7 script cannot do this, as it was written to use object elements, which are not transparent in IE.
Here’s an IE screenshot. This is using IE7 0.8.
Note the big blank rectangle where a gradient should be. This is caused by the object taking on the background colour of the main element, but not the background image.
If you look at the source of that page, you will see that there is a script “/j/jsloader.js” loaded at the head of the page, and the only indication of where to apply the script is done by giving the navigation’s wrapping element a class of “magicmenuleft“. The script searches for that, then applies certain functions to elements containing that class.
The method used by Ben Nolan is similar, but even less intrusive. We both use CSS selectors, but his is possibly more efficient, bandwidth-wise.
I had a very strange problem yesterday. I upgraded my office server recently, as I intended to use GD as my graphical library, instead of ImageMagick, which I had been using up until that point. The major difference is that ImageMagick is an external program which must be re-called every time it is used, and GD could be compiled as a linked library, making it quicker to use (imho).
So anyway – I did the upgrade, choosing PHP5 over PHP4 (not that I use its new OOP methods, fantastic as I’m sure they are).
Not being sure how all this would go, I chose a very simple configure script:
This compiled perfectly, with absolutely no warnings.
As I have four different machines that I test on – my laptop, my home server, the office test server, and the production server, I didn’t notice up until yesterday that the compilation wasn’t quite as perfect as I thought.
I’ve recently converted webme cms to use Pear’s Image_Transform instead of ImageMagick to perform its image manipulation, and was told yesterday that it wasn’t working on the office server.
A quick look was puzzling – no errors, no crashes – the scripts would just run, until an image was manipulated, then it would stop.
It took a bit of digging to find the problem. In order to find it, I first had to correct a few warnings in the Pear modules I was using (the Pear administrators have a policy of not giving a shit about strict code compliance, which means that their code is full of deprecated syntax and commands). I eventually tracked it down to an innocuous line, which called imagecreatefromjpeg.
Placing a line “echo 'test';exit;” before the line echoed ‘test’, but placing it after the line didn’t, so that was definitely the line.
I was a little bit stumped. I tried recompiling with the following configure script: