If you have been following what I've been up to lately you would see that many of my recent projects are based on FuelPHP. Since Fuel is so awesome and allows you to create "packages" that can be dropped into your application, I have created a few that help me quickly piece together apps. The first package I'm "releasing" is called Wrench.

The tool works with the oil command-line tool already included in the framework to swap out the default action with a "Down for Maintenance" message. It will look at the current state of the app and switch it to the opposite when run, but you can also define "start" and "finish" manually if you'd like. You can find the source for the package on Tom's github account.

Given the scale of how client-side technologies (such as JavaScript) evolved, most of dynamic functionality can be implemented using client-side scripts + remote web-services (e.g. Disqus for comments). More than often we a going down that road even on our completely dynamic sites - it makes things more simple.

He gives the example of being able to write the content in VIM and run a single application - Phrozn - and generate the new page to add to the site. He sees it as a good alternative to something like WordPress where most people only use 1% of the functionality it offers. You can find out more about the project by looking into its documentation or you can just dive into the code by grabbing it from github. As a side note, several other tools, like Jekyll are "blog aware" and can be used similarly.

In the previous article I talked about one important factor that often seriously affects the user perception of the speed of a site, which is the presence of content from external sites that slows down the load of pages, such as advertising and widgets. In that article I presented a technique that I am using to make external content not affect the user perception of the site speed. In this article I am addressing another factor that may also affect the user perception of site speed, but this time is related to aspects of the server side environment.

In this article he looks at things like other server-side background processes, throttling their CPU usage, throttling PHP's CPU usage and the use of a monitoring class to help you and your applications (and sysadmins) stay on top of what's happening with the server.

As I've learned (and continue to learn) PHP and Microsoft technologies, I've found some very helpful resources on the web. But, they are sometimes hard to find, and they certainly aren't usually found in one place. So, before I begin drilling into some of the things I suggested in my first post, I thought I'd take a stab at consolidating the resources that I've found to be especially helpful.

Sites included in the list are things like:

• IIS.net's guide for running PHP on IIS
• Accessing SQL Server from PHP
• StackOverflow's section on PHP
• the blog of Ruslan Yakushev a project manager for the IIS team

Features covered include:

• Content Staging and Merging
• Support for Multiple Websites and Stores
• Administration Permission System Roles and Users
• Web Services API
• Fully 100% Customizable Design Using Templates

If the series interests you, you can mind more great parts in the series in this category on the Blue Parabola blog.

I haven't studied how other engines do it, but here's how I do it. First off, some benefits to sharing the CMS across separate sites: reduced resource usage, easier upgrades, easier bug-fixing. Convinced yet? Of course you are. Here's how you do it.

There's four steps to his process:

• Separate out the site-specific files from one another
• Serve all site-specific files out through a "proxy" script that can intelligently grab the needed ones based on the site
• Override the default configuration at request time (forcing it to use that "proxy" script)
• Create that proxy file that the web server can funnel the requests through (his example is included).

In this article we will be exploring the registration script of our site. This script is responsible for registering new users for the website. We will also be looking at database security; since the registration script also uses a database table, we will implement some of the concepts that we will be discussing.

Their example is relatively simple - it checks to ensure that none of the fields are empty, that one password matches the other and that the email address is in a valid format (using a regular expression). If it passes completely, its dropped into a MySQL database table that stores current user information.

Recently there have been many changes to PHP Freaks. A significant change is the total rewrite and redesign of the main site. The old one was taken down after vulnerabilities were found in the source code. For the last couple of months we have been working on making what you are currently looking at now. The release has been postponed a couple of times, but people have been patiently waiting for the site.

They've added a blog to the mix (which this post is a part of) to help keep visitors up to date on the site's happenings and various other news from the admins. If you find a bug, let them know, otherwise - enjoy the new site and check out all of the same great content.

After a bit of discussion on the php.ie mailing list, Kae Verens and David Coallier set up http://planet.php.ie to bundle together blog postings from people within the Irish PHP community - a big thank you is deserved for them.

There's currently five bloggers added to the planet so if you'd like to be added, either contact Ken or Kae.

This article describes software development practices that have been used to prevent problems that can break Web sites.

Included in his list are things like:

• Handle unexpected conditions Test your code
• Monitor your site errors and act upon them
• Do not disclose errors to the users
• Do what you can as you can never get defensive enough