Keith Casey has an interesting new post to his site looking at a common dilema among development groups - whether refactor or rewrite is a better option for the state of the current codebase when it comes time for a change.

In software development, we're spoiled. We can write a single line of code and do some interesting things. If we add a framework, that single line of code is backed up by thousands.. and can do even more impressive things. [...] I can't tell you how many people have pitched me to "rewite web2project using [framework x]." At first pass, it sounds like a great idea. We can lay the foundation for doing things "right." We can use the latest and greatest tools, technology, and concepts. Even better, we don't have to figure out all that old crappy code! It's open source so it's free anyway. Everyone wins! How many times have you looked at an application and thought "I could rebuild that in a weekend!"

He points out the "seductive" nature of this kind of thinking and some of the things that it can hide from your immediate vision. These are things like: the lessons that were learned and implemented in the current code, catch up vs new development on the project and the possibility of "killing the community" as they'd no longer know which part of the project to contribute to.

He suggests instead of worrying about a rewrite, that development groups worry more about managing technical debt in their applications and reducing that piece by piece instead.

Hasin Hayder has a quick post to his blog today about how you can configure an AppFog instance to be able to run Zend Framework-based projects on them.

AppFog is quite a popular polyglot PaaS (Platform as a Service) provider and it comes with a generous free plan for the developers. [...] Recently, I was looking for a solution on how to host a Zend Framework based application in AppFog. The main problem was that the url must point to the /public folder inside the app and from there it is initialized. After searching for some time, I found the clue in AppFog's doumentation which is you'll have to redirect all the traffic from the parent domain to the /public/index.php file using the URL rewrite rules.

The rewrite rules are included in the post for easy cut-and-pasting. With the recently announced closing of their phpFog service (in favor of just supporting AppFog) I'm sure this tip could come in handy for a lot of developers out there.

Adam Culp has published the fourth part of his "Clean Code" series to his site today (see more about parts 1-3 here) with a look at the "Rewrite Dilema" - whether it's more productive to just rewrite or to try to refactor.

Unfortunately the first reaction to a poorly written application is usually a resounding "rewrite". Developers feel like a weight is lifted from their shoulders, as the manager hears a distant "cha-ching" sounds of money slipping away. [...] In the managers mind a rewrite means it must all be duplicated, and that's not far from the truth when we consider the salaries of an entire development team for the time it will take to rewrite the entire application.

Adam talks about some of his experience in the past with challenging applications and a typical scenario where one group in the company splits off and creates the new version while another maintains the old. He suggests, however, that refactoring may be a more viable option. While it might not seem easier to handle overall, the end results could lead to a more stable system and could take less time than starting from scratch.

Nikita Popov has a new post to his site looking at how you can add your own syntactic features directly to PHP (requires knowledge of the C language).

Several people have recently asked me where you should start if you want to add some new (syntactic) feature to PHP. As I'm not aware of any existing tutorials on that matter, I'll try to illustrate the whole process in the following. At the same time this is a general introduction to the workings of the Zend Engine. So upfront: I apologize for this overly long post.

He covers the usual "life" of a PHP script, how tokenization is handled and what happens when the script is parsed, compiled and executed. Code snippets are included to show you the points to add in your own syntax item - in their case, adding an "in" operator to see if a value is in an array (a one word version of this).

Derick Rethans has a new post to his blog showing how you can, using a few simple unix tools, figure out what PHP is doing when your scripts are executing.

Sometimes when you have a long running PHP script, you might wonder what the hell it is doing at the moment. There are a few tools that can help you to find out, without having to stop the script. Some of these work only on Linux.

He shows you how to use the following commands to track down exactly what your process is working on: strace, ltrace and gdb (a handy debugger that will probably give you more information than you're looking for). He includes some sample output for the commands and gives an example of a PHP script-to-gdb output relationship.

The PHP.net site as new post with some supplemental information for those users of the PHP CGI that might be effected by the recently announced bug, the reason for the most recent release. Unfortunately, this patch only fixes some of the cases of the problem, so they've amended their instructions to included a more effective mod_rewrite rule to help protect your applications.

PHP 5.3.12/5.4.2 do not fix all variations of the CGI issues described in CVE-2012-1823. It has also come to our attention that some sites use an insecure cgiwrapper script to run PHP. These scripts will use $* instead of "$@" to pass parameters to php-cgi which causes a number of issues. Again, people using mod_php or php-fpm are not affected.

The rewrite rule is there in the post, ready for copy and pasting into your config. Even if you're running the latest PHP 5.3.12 and 5.4.2., be sure to use this rule as a stop-gap measure for now. Another release is planned for tomorrow to fully correct the CGI flaw.

The PHP-Security.net site has two posts related to the recently discovered bug in PHP (hence the new versions) related to the CGI handling in certain server configurations.

In the first they detail more of what the bug is, how it could be exploited and link to the original advisory for the problem. Also included are more details on the issue, including sample avenues of attack.

In the second post they look at the recent PHP release and note that it does not completely rid the language of the problem. They point out that the Rewrite rule that's included in their post (not the one on PHP.net) should be used to prevent this issue from effecting your installations.

PHPMaster.com has a new tutorial posted today (by George Fekete) about preventing cross-site scripting attacks in your PHP-based applications.

Unfortunately, cross-site scripting attacks occurs mostly, because developers are failing to deliver secure code. Every PHP programmer has the responsibility to understand how attacks can be carried out against their PHP scripts to exploit possible security vulnerabilities. Reading this article, you'll find out more about cross-site scripting attacks and how to prevent them in your code.

Included in the tutorial is an example with a simple form and definitions of different types of XSS attacks - reflected XSS, persistent XSS and three ways to prevent them: data filtering, output filtering and data validation. He also links to a few "cheatsheets" to help even more (including this guide and a Zend Framework set of XSS test data.

Danne Lundqvist has a new post where he shares a bit of code he's written to "come to grips" with an existing XML structure.

Very often I find myself writing input filters for large XML files using PHP. Common enough task; and PHP offer a great variety of tools to do this effectively depending on the situation. Unfortunately, almost as common is the lack of documentation for the aforementioned XML files. [...] I have looked around for a simple tool but I didn't really find a tool that gave me the quick and dirty overview I wanted. A year or so ago I finally wrote a small PHP class to analyze large XML files.

He includes an example XML file, the HTML output of the parsing and a sample of how to use the class to parse and output the XML structure, complete with some CSS.

In this new post to his blog Gaurish Patil shows users of the Yii framework how they can update their configuration settings to hide the "index.php" in their requests and make cleaner URLs.

Finally we figure out the basics of Yii. While working on basic of Yii, I want to rewrite the url to SEO friendly. So I started to search on google, forum got useful information here http://www.yiiframework.com/doc/guide/1.1/en/topics.url To hide the index.php from url I did changes in config/main.php [...] and I created new .htaccess file in the same directory as my index.php file.

The changes are pretty simple - it's mostly a change to the "urlManager" setting to provide some rules for mapping controller and actions to the right place. The .htaccess file uses Apache's mod_rewrite functionality to grab the requested URL and remap it back to lay on top of the "index.php" front controller for the request.