A problem that has plagued web developers for years is how to add real-time information to their applications, such as a progress bar for file uploads. [...] JavaScript can access a file's name, type, and even the width and height of a local image, but it wasn't until HTML5 that it could access a file's size. [...] In this article I'll show you how [the session.upload_progress] feature can be used to create a simple upload progress bar without any external libraries or browser dependencies.

The tutorial provides all the steps you'll need to get it working - defining the form with the extra required field, styling it and plugging the Javascript in to call a small script to get the progress of the upload. It returns the difference between the content-length of the file and the current size (as a percentage of 100).

Here is a quick step by step guide on how to get mongodb and PHP5.2 mongo pecl extension going on your MacOSX in 32bit mode! NOTE: 32 bit mongodb binaries have 2GB address space limit so you wont be able to process too much on your laptop. You will still be able to code and connect to remote instances just fine.

His process includes five steps - well, eight if you count the optional "install MongoDB" ones too - complete with the commands you'll need to get things compiled, ready for copy and paste. You can find the MongoDB PECL package here.

Today I needed to get a client application up and running on my local system. This application uses the Geoip PECL package, so I needed to get this up and running. This turned out to be slightly more difficult than just a PECL install, as you're missing some libraries by default, so here is my log of things to do to get it up and running.

He gives the complete list of steps his followed including downloading the source and his way around this "System could not load this extension" issue. The trick was to recompile the source with the correct architecture. By default his extension was built with i386 instead of 64-bit but updating some of the CFLAGS settings (and a few other environment variables) got things compiling correctly.

Now that we know how to use DBus to communicate with Pidgin from PHP and how to listen to DBus signals, it's time to put it all together by creating a simple chat bot! Nothing fancy, just a simple script that runs somewhere on some server and, by using a Pidgin account, can respond to some basic queries we send it.

His new code listens for an incoming message on the "PurpleInterface", grabs the name of the sender and calls a "PurpleConvImSend" method with the conversation object and the message to send. You can find the complete source for the project on his github account.

The good part is that not can we only call different methods against Pidgin's libpurple API, we can also listen to different signals on different events, that are sent via Dbus. [...] The PHP Dbus extension allows us to watch for one exact signal on an interface, or for all signals on an interface. Of course, we can add watches on multiple interfaces at once.

In his example he shows how to set a listener on the session to watch for an incoming instant message from another source. Sample code is included showing how to set the listener on the interface and be able to tell when a message comes in (watching a $signal interface for an event). You can find more signal catching examples in his github repository.

Earlier this week I got an idea of trying to communicate with Pidgin, a chat client, via the terminal. [...] Surely I wasn't the first one to come up with this idea and after a bit of a googling found out that Pidgin's libpurple has a nice API for that, exposed via D-Bus. I first planned to write some scripts for this in Python or C, but when I finally sat down over the weekend to hack on this, realized there is a PHP D-Bus extension, thanks to Derick Rethans!

He goes through the whole process you'll need to get it up and working on your system - installing the extension via PECL, creating a DBus proxy to the Pigdin interface and getting a list of the currently connected users. You can find the first versions of this code in his account on github.

I think the fact that we have $_POST and $_GET lulls some of us into the false sense that we should have $_PUT and $_DELETE objects, since that would map to the commonly-desired set of HTTP verbs that REST likes to use. But what should be inside those things, or should we be moving towards a more Pythonesque solution where a Request object, as part of core or via a only-really-for-the-brave- PECL extension?

He mentions opinions from other PHP community members (Laura Thompson and Elizabeth Smith) and a bit about what he (and I'm sure other developers) are looking for in a more full-featured request/response handling feature.

Why care about another PHP framework? especially one that's actually called Yet Another Framework? Because Yaf isn't just a framework. It's a PHP extension (listed on PECL), so it's written in C -- so it's very, very fast. How fast? Here's a benchmark (requests/sec).

The only framework (of the list he compared) that came in faster was MicroMVC and that's not as full-featured as the Yaf functionality is. Disregarding that, it has a huge requests/second difference between even the next on the list, CodeIgniter.

A while ago, Fabien asked me to have a look at porting one of Twig's slowest methods, TwigTemplate::getAttribute(), into a PHP extension. It is a complex method that does a lot of different checks and look-ups. Fabien's benchmarks showed that this method was responsible for quite a large amount of time. On top of that, it didn't seem that it could be optimised any further as PHP code itself.

He points to the twig-ext extension that's a reworked version of the "getAttribute" method from the tool and the performance gain (about 15%) it gives. Compiled templates will automatically call this new method in the extension. This update has already been merged into the main Twig repo.

Application profiling can help us determine bottlenecks and possible problems during development. But sometimes we also need to diagnose problems in production environment. Frequent performance problems are connected with functions and methods using too much memory.

The tool allows you to set up thresholds for memory consumption and, if the scripts exceeds it, add warnings to your log files. He includes the simple instructions to install it (via PECL) and enable it in your php.ini. Some sample code to create a memory overvload is included to test it out. Configuration options let you set the limits and define functions to ignore if you know for sure there's trouble spots.