In a new tutorial today from PHPMaster.com, they show you how to combine Javascript and a PHP feature to track the progress of an upload to your web application.

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).

<> On PHPBuilder.com today there's a new tutorial from Leidago Noabeb showing how you can track your website's users with the help of sessions and cookies, the handling for which are already included in PHP.

So, why can't you maintain state with HTTP? The main reason is because HTTP is a stateless protocol, meaning that it has no built-in way of maintaining state between transactions. For example, when a user requests one page followed by another, HTTP does not provide a way for us to tell which user made the second request. In this article we will look at what maintaining state in PHP applications entails.

They introduce cookies and how they can be used to store information about the user's session on their client for a certain amount of time. This makes it much simpler for the cross-page or cross-session details to persist. There's a bit of code showing how to set and get a cookie and how to do the same with a session.

On PHPBuilder.com there's a new tutorial posted showing you how to create a user authentication system that uses sessions to handle the logged in user's information.

Outside of installation and configuration issues, reader questions pertaining to user authentication and session management almost certainly rank among the most common I receive on an ongoing basis. The logic itself is pretty straightforward; however, even a simple implementation involves a number of small but important details which aren't always so easy to figure out the first time around. This tutorial serves to dispel much of the confusion by guiding you through the implementation of a simple user authentication feature which will subsequently keep the user logged in via a session.

He helps you create the simple login form, a table in MySQL to store the user data in and the PHP script (complete with input filtering) to handle the login. The system also tracks the last login of each user by updating the table with a timestamp each time they successfully log in.

Till Klampaeckel has put together this new post looking at the track_errors ini option (that will always put the latest error message in $phperrormsg) and how it can help you more efficiently handle the errors your application throws.

track_errors provides the means to catch an error message emitted from PHP. It's something I like to use during the development of various applications, or to get a handle on legacy code. Here are a few examples why!

He gives the example of a failed file_get_contents that results in a warning. He suggests that, instead of suppressing the error, you set display_errors to "off" and throw an exception when on the failure. There's trade-offs though including the fact that it's in the global scope and additional work would have to be done to handle problems inside other scopes.

Kore Nordmann has a new post to his blog about this year's FrOSCon and the PHP track they're organizing for it.

This years FrOSCon - one of the most awesome open source software conferences - is right ahead and we are organizing a PHP track again this year. We want to thank all speakers who made it possible to publish this awesome program`. And I want to especially thank Christian, who helped a lot organizing this years PHP track.

This year's FrOSCon will be happening August 21st and 22nd in the computer science department of the University of Applied Sciences Bonn-Rhein-Sieg.

On the Zend Developer Zone today there's a new post about the PHP track at this year's Dallas TechFest (happening July 30th).

On July 30th in DFW, take part in the Dallas TechFest! It is a one day technical conference and we're happy to say that we have a good PHP track. Let's blow out the attendance. It's on a Friday so you won't be getting anything done anyway.

You can find the full list of speakers (cross-language and platform talks!) on the TechFest site. PHP-related topics include using the Zend Framework, scalable applications and application deployment.

Often times developers only think about tracking the bugs in the code for their "real jobs" and don't worry about issues that might pop up in their personal projects. Brandon Savage suggests that they should both be important and that not tracking bugs on your personal projects can be a bad thing for the quality of your code.

Too often, it seems like these development practices are abandoned, especially with regards to the use of a bug tracker. I know I have personally been guilty of failing to use a bug tracker, even though I use things like Subversion and develop specifications. It's easy to forget, but important to remember.

He lists five reasons why you should use a bug tracker for your personal development:

• Our minds are imperfect repositories of information.
• Bad development practices can form.
• It makes it harder to force ourselves to use bug trackers for private paying clients.
• Predicting time to completion becomes more difficult.
• Seeing progress being made is that much more difficult.

PHPBuilder.com has posted the second part of their series on creating a sample application - a time tracking app - with PHP and Adobe Air.

Welcome back. In part 1 of this series, you created some PHP remote services and the Clocked! widget application. Part 2 covers PHP administration and completion of the timer widget.

They're developing a Flex-based application (rather than the HTML/Javascript combo that can also be used with Air) so they'll be doing their work in Flex Builder. They set up a few placeholder functions like getClients, getProjects and getProjectsResult as well as support for the ticket and timer objects. Add in a few interface items like dropdowns for client and project selection and a start/stop button and you have the basic app laid out. The PHP interface to all of this Flex code comes in the next article of the series.

On PHPBuilder.com today there's a new tutorial by Richard Bates that will walk you through the creation of a simple time tracking application that combines the Adobe Air and PHP technologies to make a simple desktop client.

The scenario calls for a lightweight, cross-platform desktop application that does its job and stays out of the users' way. It also needs a powerful management interface that can be accessed from anywhere. To address both needs, you first create a desktop application for AIR that leverages PHP back-end services for persistent storage and extra horsepower. Then, you create a simple and quick PHP/Hypertext Markup Language (HTML) browser-based interface for management and output applications.

The Air client is really just a frontend to the PHP backend located on the server (so there's no need to install PHP locally too). The system is based around a few objects - the Client, a Project, a time-tracking Ticket and an Invoice for the time spent. To make things simpler, he uses an instance of the Zend Framework to do most of the heavy lifting on the backend.

The rest of this article sets up the backend scripts - creating the service interface and making some of the initial methods (like getClients and logIn). The next part in the series will get into the actual Air application.

On DevShed today the latest article in their XDebug series has been posted, a look at tracking the function call stack with help from functionality the extension provides.

Despite this inconvenience [pf not being able to get more in-depth], in this final part of the series, I'm going to show you how to work with a function of the library called "xdebug_get_function_stack()." This function can be used to keep track of the stack of function calls generated by a PHP script, in this manner completing this starting guide on this helpful extension.

After reviewing the script from the previous part (using xdebug_time_index) they get into this new function and what sort of output it provides. The stack is the trace of what functions and values were passed around in the script including information like the function name, parameters and the file it was in.