• Static page caching support in the routing configuration
• Payment validators with docblock assertions, including error messages for failures.

These features are all a part of the upcoming Symfony 2.2 release that's planned to be moved in the "stabilization" status in early 2013. It should be able two months following that when the stable version will be released.

Zend Server has a very cool Page Caching feature. Basically, you can provide URLs or URL regular expressions, and tell Zend Server to provide full-page caching of those pages. This can provide a tremendous performance boost, without needing to change anything in your application structure; simply enable it for a set of pages, and sit back and relax. [...] However, this feature is not entirely straight-forward when using a framework that provides its own routing, such as ZF2. The reason is because it assumes by default that each match maps to a specific file on the filesystem, and prepares the caching based on the actual file it hits.

Since configuration is mostly done through Server's web interface, this could be a problem. Thankfully, he shows you another setting that allows you to cache multiple versions of pages based on parameters you define. Using this and a setting of "_SERVER" with a value of "[REQUEST_URI]" you should be good to go.

When I started rewriting this blog, I knew from start that I want to use Zend Framework's full page caching, as, I think, that's the best cache for this purpose. Not much going on on the front end, much more reads than writes, no ajax or any other "dynamic" content. While implementing the cache, I ran into two issues.

His issues revolved around the feature not creating valid cache files due to a duplicate "startSession" call in his code and having the Google Analytics code included in the template (with different keys every time). You can find out more about this functionality in the Zend Framework manual.

In this tutorial, we will be creating a simple about page that is powered by PHP, HTML5 and CSS3. It will present your contact information to your visitors, with an option for downloading it as a vCard (useful for importing it in third party applications). You can use today's example as a placeholder for your upcoming personal website, or as an actual about page.

He includes all of the code, markup and styling you'll need to get it put together. The PHP is used to store the contact details and, based on a flag in the GET request (easily modifiable to any other method, like a HTTP header) it returns the basic page, a JSON set or a vcard of the contact data. The page also includes spots for linking to Facebook and Twitter accounts.

PHP has several [three] new documentation features that the community should be aware of.

They've introduced the following:

• PHP manual pages (man pages) - pman - installed via PEAR
• An enhanced CHM (Windows help) version of the manual with user notes
• The Online Documentation Editor allowing edits from anyone.

Now I didn't know it but is seems that php's session handling is blocking on a per request basis. Kinda makes sense if you think about it, that if two requests simultaneously try and change a session variable then you would get constancy issues. So php handles this by making session_start() a blocking action and will wait for any other request to either finish or close the session using session_write_close().

The only reliable fix he found for the issue was to only selectively use the session in certain circumstances (or on certain pages) and closing it out when you were done with it.

One of the golden rules when we want a high performance web site is minimize the HTTP requests. Normally we have several JavaScript files within our projects. It's a very good practice to combine all our JavaScript files into an only one file. [...] But if your project is alive and you are changing it, it's helpful to spare your JavaScript files between several files. [...] So we need to choose between high performance and development comfort.

He includes a quick script that runs through your javascript directory (recursively), grabs all of the javascript content from each, combines and minifies them to serve gzip compressed out to the browser.

In a previous blog post called How to Count Facebook Fans in PHP I've shown a code snippet of how to count the number of fans on a fan page using PHP. Times have changed, the Graph API has been introduced, and due to some responses I introduce here the new way of retrieving your fans count using the new Graph API and php.

He uses the Facebook PHP SDK to make the connection and call the "api()" method on a page (his example is the one for Mashable) and return back an array that includes the "fan_count" value.

After your websites getting more pages and links, the chance that a visitor will follow a dead link to your site exists. If a visitor is trying to access a page on your site, the server will report (normally) a 404 error. The response is by default some unfriendly page with some spare information about the error which let most visitors stop visiting your site. But using the 404 error the right way, you the site owner can collect important information.

He talks about some of the data that could be collected - what page they were requesting, where they came from, access statistics and more. The tutorial shows you how to harvest some of this information and how to put Google's Search and Adsense tools on the page as well as Google Analytics for tracking.

Error pages. Most people don't really consider error pages when building a website or application. They usually contain some debug information so that when something goes wrong the developer knows what is wrong. But in a lot of cases when an application goes into production, this information is still exposed.

He points out a specific example of a recent time when the only thing thrown to the page was an error about a database connection rather than anything more informative or useful to the typical visitor. He recommends that, at the very least, a website should still present these errors in a template similar to the rest of the site.

Your average visitor will come to your site expecting information. If something goes wrong (which can always happen), they only need to know that something went wrong, and perhaps they should get a phone number or e-mailaddress where they can report the error.