In the latest post to her site, Lorna Mitchell walks you through the creation of a first Phing plugin, an extension to the popular PHP-based build tool.

I'm a huge fan of Phing and use it regularly for build and deployment tasks. Often, I'll ask about a plugin that I wish existed, and get a very courteous "patches welcome" from the nice people in the #phing channel on freenode. This has happened a few times, so I thought I should probably look at how to make a new phing plugin, this article shows you how to make the simplest thing I could think of: a simple "hello world" plugin.

She points you to the location to grab the latest version of the tool (the github repository) and how to define a configuration file for your test runs. Then she includes the sample code showing how to create the "HelloTask" plugin. It takes an input value of "name" and displays a greeting when executed. She shows the syntax for defining this in the XML build file and the sample result when executed.

In this most recent post to PHPMaster.com Alex Stetsenko takes a look at the Zend Job Queue functionality, a part of the Zend Server installation. He talks about some basic usage to make HTTP requests and a more extended example showing report generation.

Web applications usually follow a synchronous communication model. However, non-interactive and long-running tasks (such as report generation) are better suited for asynchronous execution. One way to off-load tasks to run at a later time, or even on a different server, is use the Job Queue module available as a part of Zend Server 5 (though not as part of the Community Edition). Job Queue allows job scheduling based on time, priority, and even dependencies

In his two examples, he shows the code involved to create a new Queue object and define a HttpJob in it. The first just calls a "sample.php" script that's exposed as a part of your external-facing site and shows how you can get the current status of the job. The more advanced example shows a call to a "report.php" script with a set of options defining things like "type", "length" and "priority". He also points out some other options that can do similar things like Gearman, NodeJs and RabbitMQ.

Tom Schlick has a new post to his blog talking about a tool he's written for FuelPHP-based applications called Wrench. It's a command-line tool to make taking your site "offline" simpler.

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.

Josh Adell has posted about a bit of automation he set up with Phing and PHP's phar packaging to create an archive as a part of his build system. It's a simple five step process mad even easier by the fact that Phing already has a PharPackage task.

One of the cooler features of PHP 5.3 is the ability to package up a set of PHP class files and scripts into a single archive, known as a PHAR ("PHp ARchive"). [...] I decided to see how easy it would be to wrap up Neo4jPHP in a PHAR for distribution. [...] Since I also started playing with Phing recently, I decided to see if I could incorporate packaging a project as a PHAR into my build system. It turns out, it's pretty easy, given that Phing has a built-in PharPackage task.

He points you towards Phing's PEAR channel to get the tool installed and includes a command-line call to update your php.ini to allow PHP to generate phar files. Code is included to create the phar-generation stub as well as the XML for the Phing build file. You can find his end result here.

Sander Marechal has been working with Phing in some of his recent development and has created something useful for compressing Javascript and CSS files on the deployment of your application - a YuiCompressor task.

I am going to write several useful extensions, the first of which is a YuiCompressorFilter. Phing already has support for a JavaScrip minifier in the form of the JsMinTask, but the yui-compressor is more useful. Not only does it usually compress better than JsMin, it can also compress CSS files. Also, because my YuiCompressor extension is implemented as a filter instead of a task you can do fancy things like minifying and concatenating files in a single step.

He includes both a sample of the task and it's configuration (the XML) in the post as well as a link to its source over on github.

On the "PHP and Me" blog there's a new entry from Pinpin Bysma showing how to use the PHP-based deployment tool Phing to update your production website via an FTP connection, automated by a Phing build.

If you're working on a PHP project, like with any other project, probably comes a time when you need to "build a new release," e.g. update the production web site with the latest version of the code. And doing the whole thing manually isn't the most efficient way to get things done, especially if you're lazy, or have to do that every once in a while, over a long period of time. [...] Obviously if updating the site itself could be done without FTP but through a simple svn switch, things would be easier. Still, Phing would allow to make things easier just as nicely. It could for example still be used to create the new tag, trigger the switch, etc

He introduces the process by showing a basic Phing build file that uses the PEAR VersionControl_SVN component to get the latest from the repository and push it to another directory. There was one thing that he wanted to do that the default SVN task couldn't - export the difference between two tags. To make this happen, he had to extend Phing and make a new task - SvnExportDiff. He includes the code for this new task and an updated build file to show it all in use - complete with the FtpDeploy to push the code live.

On the PHPClasses.org blog Manuel Lemos has posted part two of his look at techniques to help speed up your site - a few things that you maybe hadn't thought of before.

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.

On SitePoint.com there's a new tutorial posted in their "PHP & MySQL tutorials" section about using a feature of WordPress that some might not know about but can be extremely handy when you need it - using WordPress tasks.

Scheduling the execution of certain functions at a time in the future is a key feature of the WordPress API, having been introduced in WordPress version 2.0. It's also a topic that's poorly understood by many developers, as it's only briefly covered in WordPress's documentation. Apart from facilitating maintenance tasks, scheduling code to be executed in the future opens up a lot of interesting possibilities for plugin developers.

He talks a bit about how the WordPress tasks work (via the wp-cron.php script) and the two types of tasks - one-off and recurring. He includes code and examples of how to set up each and some other handy features like custom timing for tasks, getting the list of scheduled tasks and a few things to watch out for when working with the feature.

In this new post to his blog Adam Jensen looks at creating cron jobs with the help of the Zend Framework without having to load up the entire MVC architecture to get there.

So, we're going to need a new application bootstrap and entry point, one that eschews the MVC routing and dispatch process in favor of something simpler. Essentially, all we'll need is to be able to run an arbitrary collection of cron "task plugins," the list of which can be configured in plain text via any of the various Zend_Config formats (e.g., the default application.ini file).

He starts with the base functionality, a task plugin interface that allows you to set up a "framework" to run the tasks in. He also creates a simple cron service that handles the execution of the tasks (this is the main executable) and includes the code for creating the bootstrap for the Zend Framework to understand how to use it all. Then to create a new task, all you have to do is extend the CronInterface.

In a recent post to his blog Ian Christian has written up an example of how to send a multipart email from a Task inside your Symfony application.

I recently needed to send the result of an action in symfony via email daily. E-mail has changed slightly in symfony 1.3/1.4 - here's how I did it. I really don't like my solution at all, the use of get_partial() from within a Task seems very wrong to me - but I'm in a rush so it will do for now, I'd love to hear feedback.

His class extends the sfBaseTask and sets up an execute method that builds a database connection, fetches a few rows and, with a newly created mailer instance, sends the information using the get_partial method to define both HTML and text content parts of the email.