In this recent post to his blog, Chris Hartjes answers his request for a "rant topic" by responding to a question about "how to not suck at PHP" (from Travis Northcutt).

I thought about this question for a while and have some thoughts on what it really means to know how to not suck at building things using PHP. In my never even remotely humble opinion I think the key is to understand what PHP is really good at.

He talks about how PHP had the early-adoption advantage at first with Apache, but how things have changed so much since then. Now, he proposes, PHP's popularity and usefulness is based on what it can do as a language without messing with frameworks at all. He's worried that, once someone picks up a framework, it'll become so ingrained that they won't know what "plain old PHP" can do (or how to work with it).

So my advice to Travis is that he should worry about learning to use PHP like glue and correctly identify the problems he is trying to solve NOW instead of worrying about the problems he might have to solve later. There will be time to fix your problems. Some of those will be solved by using tools that are not written in PHP, but PHP can still glue them together.

In a new post to his blog Paul Reinheimer talks about replacing sessions with cookies and some of the (security) pitfalls that can come with it.

I've seen several instances where people have demonstrated the ease with which encrypted cookies can replace sessions within PHP. Michael Nitschinger wrote a piece recently demonstrating the switch with Lithium, while CodeIgniter does this by default (optionally encrypting). The problem is that while replacing sessions with cookies works, it introduces a few risks not present with native session support, and these risks tend to be under documented.

He gives an illustration of an attacker who sits between Amazon and one of their warehouses. Despite encrypting their order details, all it would take is the attacker to grab an order and copy it and resend (a "replay attack"). He's created an example application to illustrate the point (source on github). The attacker doesn't even have to know what the encrypted information contains - they only have to replicate it.

In this new post to Reddit, the author shares a bit of their knowledge on what they think everyone should know about strip_tags and some of the issues that can come with it (including security problems).

strip_tags is one of the common go-to functions used for making user input on web pages safe for display. But contrary to what it sounds like it's for, strip_tags is never, ever, ever the right function to use for this and it has a lot of problems.

Specific problems mentioned include "eating" of valid text, not preventing typed HTML entities, the whitelist of tags opening holes and character set issues that could have security implications. Other tools are recommended in both the article and the comments like HTML Purifier, the option of BBCode and Markdown.

On the DeveloperDrive.com site there's a recent post anyone wondering about cross-site scripting should give a read. They introduce you to the basic concept and two things you can do to help prevent them.

This little fable describes the most common vulnerability found in web sites, the Cross Site Scripting (XSS) attack. According to a report from WhiteHat Security 83 percent of websites they tested have had at least one serious vulnerability and 66 percent of all websites with vulnerabilities are susceptible to XSS attacks making it the most common vulnerability web developers face. To fix this, it takes 67 days on average. Tools like WebScarab and Paros Proxy can be used to scan sites for possible vulnerabilities.

They offer two simple pieces of advice that it's all too easy to forget when developing applications - validate all user input to ensure it's what it should be and escape any untrusted output (even sometimes your own!) before pushing it out to the page.

In a new post to his blog Marco Tabini offers some quick advice to younger developers looking to make their mark in their profession (PHP-related or not). He shares five tips to keep in mind as you hone your process and write your code.

Every now and then, I get asked by developers who are just getting started in the trade if I have any suggestions to help them out - favourite language, tips and tricks, and the like. None of these things matter, really, but there are a few things I wish I had known when I started out that have nothing to do with the mechanics of software development.

His tips each come with a paragraph or so of explanation:

• Be humble
• There is no magic
• Programming is a craft, not an art
• Software solves problems
• Code doesn't leave sawdust

Cal Evans, one of the organizers of the php|tek 2011 conference, has some words of advice for anyone out there looking to submit a proposal to a technology conference for the topic of your choice...and have a better chance of being accepted.

Recently on twitter, @johncongdon asked me about proposals for conferences. Specifically, he asked if I had any examples that I can share because he was considering submitting to a conference. While I don't have any examples to share, I can give you some advice on the topic.

He offers some recommended reading of one of his other posts and points out that there's not a single version of a proposal that'll work for all events. He also recommends finding a way to be noticed immediately, whether it be by name or by catchy content.

On DZone.com today there's a new post from Chris Shiflett sharing some timeless advice from an older copy of a PHP Quick Reference (published in 2009) about performance and security.

While cleaning out my desk, I found an old copy of a PHP Quick Reference I helped make a few years ago. On the front page are a few performance and security tips that I thought I'd share. (Performance tips are from George Schlossnagle.)

Performance tips include profile early/profile often, cache when possible and don't over-optimize. The security hints include some of the usual suspects - trust nothing, filter input/escape output and use prepared statements.

Cal Evans has posted the second part of his series targeted towards clients contracting developers and how they can both get the most out of the relationship and work with them the best way possible (part one is here).

Look, if you could do this yourself, you would. The fact of the matter is there is just no such thing as "I *just* need a shopping cart." Do you have any idea how complex a shopping cart is? Even modules for things like Drupal, WordPress or Joomla require setup and proper configuration.

He suggests to the client that they don't assume the technology they might need (unless they know exactly what it is). Don't start things with "I need " - you're paying the developer for a reason. You are the one that knows the problem to be solved, let them worry about the technology.

On her blog today Anna Filina takes a look at developer communities (the first part of a series) - what they are, seeking them out and how you can make your own contributions.

So you have never been involved with a developer community before. What is a community? How do you find one? What can the community do for you? There are as many answers as there are communities. Everybody runs it in his own way.

She talks about communities that share passions, ones that are based on a certain area (city, state, etc.) as well as the different sort of events they might have, both social and educational. She also notes that, because of the way that several developer groups work, there's really not that much expected of the members. This doesn't mean you shouldn't want to help out, but there shouldn't be pressure about it. Her next article will talk more about the last point - starting a community if you can't find something near you.

WordPress developers (or just site admins) will be happy to know that a new book is in the works (by Alison) about securing, monitoring and generally "unhacking" WordPress.

I'm at the very early stages of writing a book about how to secure, monitor and un-hack WordPress. This book will be the culmination of everything I know about keeping WordPress hardened against attacks, how to keep an eye on your install so that you're the first to know if something has happened, and how to handle the situation if you bought the book too late and got pwned anyway.

The book will be released as an e-book and she explains some of the specifics of that in the post - cost, pre-ordering, why an e-book and her qualifications to write and release the book as a good thing to follow.