Greg Freeman has posted the second part of his "hacked PHP application" series (part one is here). In this new post he looks at the aftermath - what to do and check to do cleanup and fixes so it doesn't happen again.

This is a follow up post from my previous post "How to Tell if Your PHP Site has been Hacked or Compromised". This post will discuss some the first steps you should take when you have identified that your site has been compromised. The first sections discuss a few points that are not relevant to everyone, the later sections will discuss how to fix the exploits.

He includes a list of things to think about including:

• What kind of hosting you use (and if that contributed)
• The option to redirect all requests for your site to one page
• Get a list of all PHP files to locate something malicious
• Locating "non-PHP PHP files"
• Finding files with possible malicious content

He also includes a few suggestions to help prevent issues in the future - update to the latest versions, patch your code, rethinking your permissions and monitoring for potential repeat attacks.

On PHPMaster.com today they've published a new article from Remi Woler about preventing "code rot" in your applications through the use of unit testing. He advocates that tests, when applied correctly, can help make refactoring easier and safer, allowing you to change your code and know things stlll work.

Unless you're working on a fresh project right now, the codebase you work with most likely has such code you take for granted. And the more challenging your current assignment (or fresh project) is, the more likely it will become a legacy part as well on short notice. Since it's infeasible to fully comprehend all problems that your codebases solve, as well as all their solutions, something else needs to be done to prevent code rot. One way or the other: the code needs to be refactorable to live happily ever after.

The breaks down the steps that a unit test should follow on its most base level - assemble the environment to test inside, act on the code and assert that the output was as expected. He walks you through each of these steps, detailing what's involved and including some sample code to illustrate. He also includes a few tips on the successful application of tests like:

• Don't forget to write integration/acceptance tests as well.
• Name your unit tests verbosely.
• Write unit tests for bug fixes.
• Never change the code under test.

On the Zend Developer Zone there's a new post from Cal Evans about five ways to get involved in the PHP community that take about five minutes each (and can both help you and the community).

ome developers develop because it pays the bills. They don't want to be part of the community, they have other passions. I am ok with that, I don't want anyone involved who doesn't want to be. Other developers however tell me they didn't know the community existed, they don't know how to get involved or they are just too shy to step up. It is to this second group (and anyone who is already involved but wants more) that I want to talk to. If you want to get involved in the PHP community here are 5 quick ideas to get you going.

His five things are simple and cover a lot of different media, from blogs to twitter:

• Email your local PHP User Group and offer to speak.
• Setup a PHP tag on your blog.
• Submit something to DevZone!
• Re-tweet something about PHP.
• Find at least one other PHP developer that is not involved in the PHP community and convince them to read this list and take action.

He equates this last one to a "chain letter" but it's key to helping th community grow. It's all about people getting together around a language they love and sharing that with more and more people.

On JoomlaBlogger.net there's a recent post that wants to help you understand the Joomla templating system in "five easy steps".

There are very few tutorials on how to build templates. There are two books and a handful of other resources scattered around the web. So, we set out to build the very best template class we could. Here are first five sessions of the class: Joomla templates are not rocket science. You can learn how to build and modify them. We can show you how. Interested?

They break it up into the basic parts:

• Template setup and templateDetails.xml
• Index.php
• CSS/Cascading Style Sheets
• Images
• Security

Kevin van Zonneveld has posted seven steps that you can follow to help the documentation for your PEAR class come out better and be more useful in the end.

If you've written a PEAR package, it's probably a good idea to submit some end user documentation. Here's how to do it.

He explains what it is (XML in CVS, easily convertible with phpd) and how the process flows - save the current docs, add your own, build locally and submit to CVS. Here's his tips to help things go smoothly/turn out better:

• Gather the prerequisites
• Save current documentation
• Try building the docs
• Write your own XML docs
• ReBuild peardoc
• Commit your XML
• (There is no seventh step - you're done!)

As all of the WordPress users out there know, the "admin" section of the installations is one of the most important areas of your site. That being said, it should also be one of the most well protected parts. This new article from Smashing Magazine has ten tips that you can use to help protect you and your blog from prying eyes.

The administration area of a Web application is a favorite target of hackers and thus particularly well protected. The same goes for WordPress: when creating a blog, the system creates an administrative user with a perfectly secure password and blocks public access to the settings area with a log-in page. This is the cornerstone of its protection. Let's dig deeper!

Here's their ten tips:

• Rename and Upload the wordpress Folder
• Extend the file wp-config.php
• Move the wp-config.php file
• Protect the wp-config.php file
• Delete the admin User Account
• Choose strong passwords
• Protect the wp-admin Directory
• Suppress Error Feedback on the Log-In Page
• Restrict Erroneous Log-In Attempts
• Keep Software Up to Date

On the Developer Tutorials blog today, there's a new post talking about the "three easy steps" to making an RSS feed for your blog:

Adding an RSS feed to your site is quick and painless, and can be done with pure PHP (and some kind of data source). After the jump, 3 simple steps to building an RSS feed in php.

The steps are pretty simple - figure out what content you want to serve, set up the basic RSS XML structure, and loop through your data to push it in to the template and echoed out. Some simple example code is included.

On her blog today Nessa has written up a tutorial on getting SuPHP working along with cPanel on your system.

I wrote this tutorial a while back and figured it would be good to post because suPHP is growing more popular as an alternative to phpSuExec. The instructions assume that you are on a Linux cPanel server and are familiar with how to install PHP, but do not want to use EasyApache's suPHP installer in WHM.

It's a long process but a lot of it is just configuration changes and grabbing the right software. Every line of each of the config files you'll need to change is there ready to cut and paste into your files as well as the command line calls you'll need to make to configure/compile and move files to where they need to go.

On the Zend Developer Zone today, there's a new article by Dotan Perry and Shie Erlich talking about what kind of scalability and responsiveness that the Zend Platform's Job Queue functionality has to offer.

The Zend Platform Job Queue is used to make applications more responsive by allowing tasks to be performed on other machines (e.g.: dedicated machine), and scheduling tasks to a future time (usually to low-traffic hours). [...] Job Queue offers both a web-based management UI, and a programmer-oriented rich API, which allows embedding sophisticated logic into applications. This article will demonstrate basic usage of Job Queue, through an imaginary company wesellalot.com.

They start by presenting a scenario where a simple cluster of machines behind a load balancer all work with the same database. Because of some of the tasks they want to perform, things could get overloaded very easily under a high load. Enter the Job Queue and their four step process to integrate it into this setup:

• Step 1: Off Load to a Dedicated Server
• Step 2: Scheduling to low-traffic hours
• Step 3: Breaking down tasks using dependencies
• Step 4: A recurring cleanup job

They also include an explanation as to why this method is preferable over just using croned scripts for the same purpose.

Christopher Jones shows us today how to set up and run tests (using the built-in extension testing PHP has) to test the OCI8 functionality that that extension provides.

The test suite can't test everything. You should test your applications with your new PHP too. This gives load and real-life testing not possible with PHP's script based test suite.

[...] The tests in ext/oci8/tests verify the behavior of the OCI8 extension. To run them follow these steps.

There's four steps he gives that will help you check your Oracle compile installation including what the response of the test results will look like.