Lorna Mitchell is back with another post in her "Building a RESTful PHP Server" series today with this new post showing how to work with output handlers (her focus is on JSON).

So far we've covered parsing requests to determine exactly what the user is asking for, and also looked at routing to a controller to obtain the data or perform the action required. This post gives examples of how to return the data to the client in a good way.

She advocates using output handlers instead of the usual views you'd think of in a typical MVCish sort of application. The difference here is that there's not a lot of extra overhead to produce the results - it's literally an output directly from a class extending the base view (including the correct headers). She also briefly mentions the inclusion of JSONP functionality, allowing you to specify a local callback to execute when the request is returned. A few other "nice to haves" are also mentioned like the number of results returned and pagination support.

Lorna Mitchell has posted a quick tutorial about a feature of the upcoming PHP 5.4 release, the built-in web server, and some tips on doing things like routing requests and changing the hostname.

One of the big features arriving with PHP 5.4 is the addition of a built-in basic webserver for use in development environments. Quite a few of the other scripting languages have something like this so I'm very pleased to see it in PHP. Using a server like this makes it easy to quickly try out some scripts without needing to configure apache or really do anything much! I had to look up a few things to get started, so I thought I'd write them down for posterity.

She includes instructions on how to get the server up and running from the command line, updating the location of the document root with a command line option and using a simple "routing.php" script to act as a front controller. Changing the hostname is as simple as changing "localhost" to something else when starting the server.

Lorna Mitchell is back with a second installment in her "Building a RESTful PHP Server" series with this new post about handling and routing the incoming requests. (You can find the first part about working with the request here)

This is the second part of a series, showing how you might write a RESTful API using PHP. This part covers the routing, autoloading, and controller code for the service, and follows on from the first installment which showed how to parse the incoming request to get all the information you need.

She shows how to grab the controller name from the incoming request (based on her previous code), create the object for it and execute the requested action name. Also included is a sample autoloader and a basic controller - a UsersController with "getAction" and "postAction" methods for responding to GET and POST requests.

On the PHPClasses.org blog today there's a new post looking at the security vulnerability that effected not only PHP but lots of other languages making them susceptible to attack from the outside.

In PHP and several other languages used to implement Web applications, arrays are used to store the values of request variables such as $_GET, $_POST, $COOKIE, etc.. IF you receive a request with a large number of request values, until recent versions PHP may run into trouble.

He goes on to explain why there's an issue with the array overloading and what PHP has done in recent releases to help correct the issue - the max_input_vars setting in the php.ini. He also points out that this is not a new issue - it was originally identified back in 2003 (with a video of the original presentation). He points out that the most recent releases of the PHP language have this fix in them and, if at all possible, you should upgrade to protect your applications.

As is mentioned in this new post to DZone.com, one of the features of the upcoming PHP 5.4 release, including things like traits and array dereferencing support, will also have an interesting new feature - a built-in simple web server.

Yet another new feature to look forward to in PHP 5.4.0 - the CLI SAPI will now provide a built-in web server which is geared toward developmental purposes. It shouldn't be used in production right now.

The PHP manual has been updated with the latest on this upcoming feature:

URI requests are served from the current working directory where PHP was started, unless the -t option is used to specify an explicit document root. [...] If a PHP file is given on the command line when the web server is started it is treated as a "router" script for the web server. The script is run at the start of each HTTP request. If this script returns FALSE, then the requested resource is returned as-is. Otherwise the script's output is returned to the browser.

The PHP 5.4.x series is still in beta as of the time of this post - you can download the beta1 on the downloads section of the PHP site (or the Windows binaries).

Adam Peterson has posted an interesting idea for those out there running an internal staging server they want to constantly keep up to date with the main line of code (without manual intervention) - a git pull web frontend combined with git post-receive hooks.

This [move from svn to git] left a bit of a gap in my process where I could no longer test on a remote server without updating it manually by S/FTP or opening terminal and manually calling a git pull. Open terminal and manually git pull it did break up the work flow a bit so using the Dingo framework I created a very simple Git helper and gave it its own URL something like git/pull.

He added a post-receive hook to his git server that calls this "git/pull" URL on the staging server and updates the code on the server. This provides an easy asynchronous way to update things on another server. Note, though, that this should never be done on a publicly accessible server - it's a pretty large security hole (or at the very least made secure somehow). He used Dingo to create his interface, but something like the Slim micro-framework could have worked just as well. You can view his code on github.

On SitePoint.com today there's a new post from Craig Buckler showing you how to create a simple XML to JSON proxy server in PHP with a SimpleXML object at its heart.

Unless you're new to this web development lark, you'll know the 'X' in 'AJAX' stands for XML - eXtensible Markup Language. But you're probably not using XML. If you are, you'd probably prefer not to. All the cool kids are using JSON or JSON-P: it has a smaller payload, is easier to use and faster to process. [...] Fortunately, there are a couple of solutions which allow you to retain the benefits of XML data interchange but provide the ease of JSON in JavaScript. In this article, we're going to create an XML to JSON proxy server in PHP.

Of course, this will only work with well-formatted XML documents, but it's a quick little hack that pulls in the XML data with a curl request and parses it via SimpleXML and uses json_encode to push it back out as JSON.

Christian Weiske has a quick post about a handy PEAR-related project that might be in risk of fading away - a plea for help with pearhub.org.

Troels Knak-Nielsen, father of pearhub, wrote to the pear-dev mailing list: "Unfortunately I have absolutely no time at hand for this project and probably won't for a foreseeable time. I still think it fills a need, so I'd be happy to hand over the keys to anyone who will take it upon them to move the project forward. I'll try to assist as best as I can, but probably won't have much time to spare. But the project is fairly simple anyway, so it should be relatively easy to get the main idea."

If you're interested in hosting or helping out with the project, let Troels know. Pearhub lets any project with a publicly facing repository be installed via a PEAR channel quickly and easily. For more information, see the project's FAQ.

In this recent post to Reddit, a question is asked that's an issue for many developers testing the email sending abilities of their applications - how can it be tested effectively without outside services flagging you as a possible spammer.

So how do you guys do it? My current solution is to just output the email template HTML straight to the browser, but this doesn't always work. [...] I have considered sending emails through to my GMail, but I run my tests quite often and I'm not sure Google would be too happy with the amount I send. [...] I'm sure there's a better way I can handle this without modifying my code too much. Suggestions appreciated.

Suggestions from the comments include:

• a local SMTP/IMAP server configured to catch all emails being sent
• Changing the address based on an environment flag
• Using "@example.com"
• Saving the email as a .msg file for later review

There's also suggestions of other Mac or Windows software to mimic the mail server like smtp4dev and MockStmp

On the VXTIndia blog there's a recent post that gives you a very complete guide to setting up a VPS server running Ubunut with all of the software you'd need to get a (more than) complete server up and running.

Every time you purchase a new Linux VPS, you need to go ahead and set it up for use. Even though we manage to do one server a month, we always seem to forget one thing or the other. So we decided to write down the things that we do. I thought it would be a good thing to share it with everybody as well, so that we could get a few comments about what we're doing wrong, and people who do it the first time can probably pick up a few things from here.

Steps and software involved in their process include:

• Updating to the latest Ubuntu packages
• Creating other users for the system
• Installing the web environment (including PHP, MySQL, phpmyadmin and Apache2)
• Minin for monitoring
• Configuring IPTables
• Installing Fail2Ban

All of this comes complete with the additions you'll need to make to configuration files and the commands to get everything installed (via aptitude).