Part 3 – Hacking the library
Code libraries essentially provide abstraction. Abstraction is good. But anyone who regularly uses third party code in their work has at some point hit the knowledge wall; that point where the abstracted nature of the library leaves you helpless in resolving an apparent problem. You have limited choices – Wait for a patch, hit the forums, or hack it yourself. The latter is probably the worst thing to do, but deadlines are deadlines.
To hack or not to hack
I’d like to point out straight away that I don’t condone the hacking of third party code. If you hack a library it is much harder to update if a new version comes out. The biggest risk is that you may destabilize another part if the system without realizing it. The author knows much more about the code than you, so unless it’s a project you’re deeply involved in it’s probably best to leave it alone. Ultimately if a reputable library is causing you problems, the chances are that either you’re using it wrongly, or you’re using the wrong tool for the job. However, theory and practice don’t always correlate, so bring on the anecdotes …
Smarty
Smarty is almost synonymous with PHP templating engine. Smarty and I go way back and I’ve generally had a good experience, so I decided to use it recently in a bespoke CMS for one of our clients. I used the disk caching features extensively and the CMS back office was designed to clear the cache whenever content is edited. It worked great, and when the client’s server team asked how the application would cope across multiple web servers all accessing a common NFS, I said it should be fine. I figured that the OS would take care of file locking and other such low level stuff that I generally don’t have to worry about, but mainly I was putting my trust in Smarty – A project that’s been around this long surely would have died out if it couldn’t cope with such a common server configuration. I was wrong. As it turns out, Smarty cannot cope with multiple servers reading and writing from the same cache. The reason for this took me hours to work out.. PHP has a file status cache, which will cause some serious confusion when multiple processes are modifying the same files during a script execution. The library didn’t seem to make any attempt to recover from errors that might be caused by this –
– so I hacked it.
I’ll post my full solution at a later date, but basically it involves clearing the stat cache at certain, critical points.
WordPress
Another very popular PHP project – you are looking at right now. I’ve installed it a number of time on various different servers, but today I ran into trouble. To my astonishment even the latest version of WordPress (2.7) doesn’t support the mysqli extension. Only the old, arguably obsolete, mysql extension is supported. Depending on your server, you may not be able to install the old extension. This is the situation I ended up in today. I failed to find any trustworthy patches out there –
– so I hacked it.
It was fortunately fairly easy to replace all mysql_* function calls with mysqli_* function calls, but only time will tell if it will cause problems.
If you have any library hacking anecdotes, please post a comment