Daniel André

May 072012

Disclaimer: This isn’t going to be about php, so if that doesn’t tickly your fancy feel free to skip this entry. It’s also a bit of a rant.

Every now and then you figure out you want to do some cool css trick or update some css or markup that’s been lagging behind. Last friday I was in total weekend mode so I figured I’d update some of the old markup and css in the project I’m currently working on. The header area in that project was one of the first pieces of html and css created when we started developing it, and it has been left largely untouched since those early days in 2009. It was in desperate need of some tender CSS love.

The first thing I wanted to fix was the header background. It’s got a gradient background image, with a logo that has the gradient as background color. Depending on which browser you’re using, the background image and the logo is always one or two pixels off, because that’s just the way the markup is. We still have to support relatively old and obscure browsers like IE7, so keeping backwards compatibility is important to not unnecessarily annoy our customer(s). So, since we’re living in 2012 nowadays it should be as easy as adding a css background gradient with a fallback to the background image:

background: url("/images/navbar_top.png") repeat-x; /* legacy background image */
background: linear-gradient(to bottom, #434A50 0%,#2B3036 80%); /* W3C */

Yeah, not so much. The CSS level 3 specification for background gradients is still not finished and all browsers that has implemented it so far has done so based on early drafts, their own interpretation of the specification as well as their own desires about how the specification should work. According to the MDN page about CSS linear gradients, achieving this effect across all browsers is not at all trivial.

First of all: the background gradient CSS3 specification is of course not yet final and it is still subject to changes. Also, every browser on the planet has its own way of specifying background gradients, and they’re all non-compatible as well as wildly different. If that wasn’t enough to completely turn you off CSS gradients, bear in mind that each browser also has different browser-/vendor-specific implementations depending on the browser version, as the recommended implementation has been changed quite a lot since Apple introduced this feature back in 2008. To end it all, the currently final version of the CSS3 recommended standard has switched around one of the keywords – instead of specifying where you want the gradient to start (“top”), you specify the direction (“to bottom”) – making the final recommendation inversely compatible with the currently available browser-specific implementations. So, to implement something as trivial as a background gradient you need to take into consideration several different versions of a multitude of browsers, as well as a totally moving specification. With that in mind, here is the bit of CSS I ended up using for that header background gradient:

background: url("/images/navbar_top.png") repeat-x; /* legacy background image */
background: -moz-linear-gradient(top, #434A50 0%, #2B3036 80%); /* FF3.6+ */
background: -khtml-gradient(linear, left top, left bottom, color-stop(0%,#434A50), color-stop(80%,#2B3036)); /* KHTML */
background: -webkit-gradient(linear, left top, left bottom, color-stop(0%,#434A50), color-stop(80%,#2B3036)); /* Chrome, Safari4+ */
background: -webkit-linear-gradient(top, #434A50 0%,#2B3036 80%); /* Chrome10+, Safari5.1+ */
background: -o-linear-gradient(top, #434A50 0%,#2B3036 80%); /* Opera11.10+ */
background: -ms-linear-gradient(top, #434A50 0%,#2B3036 80%); /* IE10+ */
filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#434A50', endColorstr='#2B3036',GradientType=0 ); /* IE6-9 */
background: linear-gradient(to bottom, #434A50 0%,#2B3036 80%); /* Current W3C recommendation */

I kid you not.
Luckily, with this blob of CSS we’re able to support pretty much all browsers in use today. Yay for us! Only marginally smaller than the byte size of the image we’re currently using!

I’ll follow up with a new post soon, with more juicy CSS fun. Comments are much appreciated!

Feb 072011

The Bug Genie version 3.0 released

Last week, The Bug Genie 3.0 was released, together with an updated website.

The Bug Genie is a PHP-based issue tracker and project management tool in development since 2002. Version 3.0 is based on PHP 5.3 and has been in development since late 2009.

Visit http://www.thebuggenie.com for more information!


Nov 252010

update: The contents of this blog post has now been merged into the Doctrine 2 cookbook entry (http://www.doctrine-project.org/docs/orm/2.0/en/cookbook/sql-table-prefixes.html)

A few months ago, we started using Doctrine 2 on the project we’re developing for a customer of ours. Doctrine 2 has proven to be both fast and stable which has certainly saved us time and effort. We recently had to implement table prefixes on our tables in Doctrine 2, which turned out to be not so trivial, and led me to a journey inside the Doctrine 2 metadata parser, event hooks and relation mapper. Fun stuff!

Prefixing regular tables

The first thing I had to do was to get prefixes working. Contrary to Doctrine 1, where you could use the Doctrine_Core::ATTR_TBLNAME_FORMAT to set a table prefix (or suffix), there isn’t yet a similar feature for Doctrine 2 (looking at some bug reports like this one, it doesn’t look like it’s high up on the list of priorities either). However, the solution suggested was to add a loadClassMetadata listener to provide the table prefixes by rewriting the defined table names as they were being generated and add the prefix programatically in that event. The cookbook entry describes the procedure for implementing this in detail, and after adding the suggested lines of code to our Doctrine loader tables were being prefixed all around.

Prefixing many-to-many jointables

However, the many-to-many automatically generated jointables were *not* being prefixed, and there turned out to be a good explanation. The loadClassMetadata event was being fired in the table that defined the many-to-many joined relations, but there was no separate loadClassMetadata event fired for the generated jointables where I could rewrite the table name with the configured prefix. As Benjamin Beberlei mentioned in a follow-up comment to the bug report we filed for the cookbook entry, this was both (semi-)intended behaviour and a known limitation of the code in the cookbook entry with an “easy” fix. The fix meant I had to look into taking a peek at the table’s metadata and perform an explicit rewrite on the related jointable. Luckily that’s all documented behaviour and the pointers Benjamin gave me were more than enough to get me started.

The behaviour of the code in the cookbook was to just get the table name from the class metadata as it was being loaded, prepend the table prefix and set the table name back to the new prefixed name. Easy peasy.

$classMetadata = $eventArgs->getClassMetadata();
$classMetadata->setTableName($this->_prefix . $classMetadata->getTableName());

However, to rewrite the table name for many-to-many relation jointables, we have to also traverse the classmetadata properties, look for related tables and rewrite them if the join type is many-to-many:

foreach ($classMetadata->getAssociationMappings() as $fieldName => $mapping) {
if ($mapping['type'] == \Doctrine\ORM\Mapping\ClassMetadataInfo::MANY_TO_MANY) {
$tableName = $classMetadata->associationMappings[$fieldName]['joinTable']['name'];
$classMetadata->associationMappings[$fieldName]['joinTable']['name'] = $this->_prefix . $tableName;

Turns out that it wasn’t that much effort needed, and the result is neatly prefixed table names all around. As an extra, we of course also added a ZF application.ini entry to define the table prefix for easy configuration. But that’s a different blog post.

May 072009

Last night I nailed an annoying bug in my bug tracker that has been tricky to locate, and was related to MySQL, transactions and apparently only certain MySQL versions which behaved correctly.

To ensure consistency in the bug tracker, I use a transaction to commit several changes. In this case, after an issue was created, it wouldn’t save stuff being inserted after the transaction->commit(). However – the id fields which were auto_inc – would all increment by one for each row that was never inserted. This would only happen on a select few MySQL versions, which lead me to believe it was actually a bug in those specific MySQL versions, and not in my code (it’s never me, of course :P ). This was also based on the assumption that doing a commit() would stop “transaction mode” and turn “autocommit” back on. One glance at the PHP manual proved me wrong.

It all did come down to the fact that in the class file that was creating an issue, the “autocommit” parameter for mysqli was never set back to “true” after committing a transaction. According to the manual, this should mean that all subsequent queries for that connection would “fail” unless a new “commit()” has been made. However, this obviously didn’t happen, as I have most of my bug tracker installations running properly, without this problem happening at all.

Under no circumstance was a commit() called after that point – which should mean that any queries being executed after that point were being rolled back. However, that only happed on a specific few MySQL versions, and none of the ones I tested on (confirmed at least 5.0.61 and 5.1.3). To make matters worse, the auto_inc id field did increment by one, even though the row was never saved!

The solution was simple – either do a second commit() at the end of the function to make sure all the queries after the initial transaction were commited, or make sure that the transaction turns on autocommit when it was done. In this case, I created a second function in the transaction class to commitAndEnd(), which turned autocommit back on after committing.

Lesson learned: Read manuals, don’t make assumptions. And don’t blindly trust MySQL.

Apr 212009

In the last few days (evenings) I have been revisiting several games that I found amusing when I was younger. Some of these games I spent endless hours playing – both single- and multiplayer. I also convinced a friend of mine to try playing some of these games with me – apparantly he also enjoyed playing some of them in the past.

As it turns out – these games aren’t as good as they once were. Or – our perceptions, expectations and gaming habits have changed. We want more. The graphical standard – which were breathtaking at the time – now makes the game look old, outdated, boring and uninteresting. The intense gameplay we experienced back then has now turned into boring tasks, repetitive assignments and uninvolving gameplay. The AI is still stunning – although now it is not because it is so good, rather that it is mindnumbingly bad.

Truth be told – I didn’t have as much fun revisiting some of these games as I thought I would.

What on earth does that have to do with PHP? Well, by coincidence, this weekend I also found a backup CD I had lying around – and it had some of my older PHP projects on it. I think you know where I’m going with this now ;)

Yes, you are right – I was amazed by how badly coded these projects were. They are riddled with amateurish mistakes, shortcuts, half-assed solutions and just in general messy code. Functionality that I still remember spending endless hours implementing turns out to be nothing more than semi-intelligent calculations written in poorly designed PHP code.

Notices are being thrown all over the place, short open tags everywhere (and completely at random), $_GLOBALS variables used inconsistently, naming confusion, duplicate functionality in different functions, no classes (well, actually there was one, with one function in it but it wasn’t even used), and no concept of how an application is structured.

Suffice to say I wasn’t as impressed looking at it now, as I was when I was writing it. However – this is a good thing! Spotting obvious mistakes in old code shows that you’ve learnt. I have learnt a tremendous amount of new stuff over the past two, three years, it’s hard to even think about it all!

So – if for nothing else than to give you a good laugh – dig up some old code and have a look at it. Try to remember the good times you had writing it – the challenges you faced and how good you felt when you finally found the ultimate solution. Which turns out was probably not so much the universal ultimate solution, but rather “the best you could come up with, at the time”.