I just published the slides from my <?php konferenca 2010 talk. You can download them here.
Seems like there’s really something special about window and document objects in IE. Just as with iterating over window properties, there seems to be some weirdness about deleting the properties in window DOM object.
I’m really glad to see Lukas planning to push PDO a step higher. I think it’s already a decent extension, and has a bright future — since I first used the extension I’ve never ever used anything else for any database. It’s object-oriented, has a lean interface, it’s fast, and supports a major feature: prepared statements. I’ve completely forgotten about having to escape, because I always insert/update through these. Seeing mysql_real_escape_string() anywhere in code makes me sad, and seeing $db = mysql_connect() and then passing the resource around makes me sick . Yes, you can use a class to wrap this up, but why would you? PDO is just that and more.
The only thing I miss is some sort of prepared statement inspection. You prepare it, and you pass the parameters, but you can’t find out what the query actually looks like. This would come in handy for logging, but it may be impossible to implement in the extension, because as I understand prepared statements are assembled by the database itself, unless they’re emulated by the extension.
I’ve encountered LiveNetLive a few times, it’s a service that runs on top of your website and creates a live community chat. Never had any problems with it, until yesterday, when I tried posting a comment on some blog.
Seems like LNL steals focus upon loading, which may happen a few seconds after you’ve already started writing a form. Needless to say that this is annoying at least.
But today, I’ve seen the problem in all of its glory. I’ve tried logging in to VideoLectures.net, I focused the username input, entered my username, tabbed to password input, entered password, pressed Enter, and only then realised that it stole the focus just before I typed the first letter of the password. My full password then went public to at least 8 people that were reportedly visiting the same page. What good is strong password hashing, XSS and session protection and whatnot, when you have a feature like this?
Needless to say I’ve changed my password immediately.
Update: I’ve contacted them and they replied promptly that this problematic auto-focus will be fixed soon.
Just looked at search terms leading people to my blog and found a few of “wideimage problem php”. Just to let you know, there are several support channels available if you get stuck using the library or find a bug. So, please, don’t let me guess what your problems are.
It’s friday evening and I’ve just released a new version of WideImage. I’m such a geek.
I’ve recently started a new project, called LayerCache. It’s an easy-to-use caching framework for PHP5, which allows you to cache items in multiple layers. When a requested item isn’t present in one layer, the framework reads from the next layer in the stack. If the item isn’t present in any layer, it’s retrieved from the source and stored in all caches in the stack.
An example of usage would be caching user profiles in Memcache (bigger, slower, global to all webservers) and APC (smaller, faster, local to each webserver). It also offers a mechanism called prefetch, which aims to reduce the database hit when an item is removed from the cache because of age (ttl).
Currently, the framework offers interfaces to Memcache, APC, file caching and local caching (PHP array with LRU, caching in a request scope). I’ll probably add more caching interfaces support as the project evolves. There is no documentation, apart from examples (see link bellow) and unit tests (yes, that counts as documentation). The current code is fully tested with PHPUnit, but no stable package is currently available.
For more, visit the following links:
For some reason php|architect’s June issue failed to list Symfony among 6 frameworks that are supposedly worth mentioning. I’m not going to speculate on why, but I will say that it’s wrong from at least one perspective.
If a serious magazine tries to present itself as a valuable source of PHP information, and half of the issue is dedicated to frameworks, and they put a big caption saying “PHP HAS BEEN FRAMED – A rundown of popular frameworks” on the front cover, but then at least two of the frameworks listed are far from maturity (and userbase, and documentation) of the big players, and you fail to list at least one of the most popular frameworks, then it’s a fail. Whether it be because they couldn’t find anybody that would write an article, or they didn’t try hard enough to find anybody, or they just didn’t think about it, it’s still a fail. They should’ve. And the same could be said for a few other PHP frameworks.
I wonder what were the criteria for the framework selection. Popularity couldn’t be the only one, because that would mean at least three frameworks replaced by others.
Even though, it’s an interesting issue, framework articles included.
When it comes to (un)serializing objects in PHP, some things may surprise you. In this post I show what I’ve found out last week, when I was testing serialization with different class definitions. This is generally a bad practice, and shows one of the biggest drawbacks of using serialization for persistent object storage: the serialized data holds a frozen version of an object. As project evolves, and classes change, the serialized information doesn’t change with them. When objects are unserialized with the new class definition, it can result in unexpected behavior. You should take care when using serialization for persistent or temporary storage (ie caching objects in memcache), because every change in the class definition may affect the unserialized objects, causing numerous bugs and crashes.