The other day I announced the release of my new password hashing library, PasswordLib. As I’ve come to expect, Reddit was full of interesting commentary on the topic. Some was good, some was bad and some surprised me. What surprised me was the insistence on a global salt (otherwise known as a “pepper”). So, I started thinking about it some more, and I figured I’d write a post on why I don’t use peppers in my hashing algorithms (and why you may want to rethink it too).

Today, I’m proud to announce the immediate availability of a new password hashing library for PHP: PasswordLib. The project is a spin-off of another that I started about a year ago, CryptLib. I was unable to find a clean solution to a few problems in CryptLib, so dev work stalled for a while. I realized recently that the password hashing functionality was complete, so if I stripped out the incomplete parts, it would still be a very useful library. And so PasswordLib was born.

I read a rather interesting post yesterday called PHP: a fractal of bad design. It’s been getting a lot of traffic among the PHP community lately because it’s rather inflammatory. But to be honest, it does make a lot of really good points. It also makes a lot of mistakes and misses a bigger picture.

Part 4 of the PHP’s Source Code for PHP Developers series is up over on Nikic’s Blog. In it, he discusses how arrays are handled in PHP internals. He talks a lot about hash tables and symbol tables, and how they work together to make PHP a working language. Part 5 will be back over here, and we’ll talk about objects and classes! Enjoy!

Lately, I’ve found myself in a number of discussions about Technical Debt and how it applies to project development. Overall, I think it’s a very powerful tool that – when used wisely – can be a great asset to any team. It seems to me that most of the people that I’ve been talking to really don’t agree, and see Technical Debt as a plague that should be eliminated at first sight. So, I figured I’d share my opinions, and see what you think…

In this third post of the PHP's Source Code for PHP Developers series, we’re going to expand on the prior posts to help understand how PHP works internally. In the first post of the series, we looked at how to view PHP’s source code, how it’s structured as well as some basic C pointers for PHP developers. The second post introduced functions into the mix. This time around, we’re going to dive into one of the most useful structures in PHP: variables.

Part 2 of the PHP’s Source Code for PHP Developers series is up over on Nikic’s Blog. In it, he discusses how internal PHP functions are defined, and how to figure out what they do. Part 3 will be back over here and will cover how variables work internally (The ZVAL). Enjoy!

As a PHP developer, I find myself referencing PHP’s source code more and more in my normal everyday work. It’s been very useful in everything from understanding what’s happening behind the scenes to figuring out weird edge-cases to see why something that should be working isn’t. And it’s also very useful in the cases when the documentation is either missing, incomplete or wrong. So, I’ve decided to share what I’ve learned in a series of posts designed to give PHP developers enough knowledge to actually read the C source code behind PHP. No prior knowledge of C should be necessary (we’ll cover some of the basics), but it will help.

This is the first post of the series. In this post, we’ll walk through the basics of the PHP application: where to find it, the general structure of the codebase and a few really fundamental concepts about the C language. To be clear, the goal of the series is to get a reading comprehension of the source code. So that means that at some points in the series, some simplifications will be made to concepts to get the point across without over-complicating things. It won’t make a significant difference for reading, but if you’re trying to write for the core, there is more that will be needed. I’ll try to point out these simplifications when I make them…

Additionally, this series is going to be based off the 5.4 codebase. The concepts should be pretty much the same from version to version, but this way there’s a defined version that we’re working against (to make it easier to follow later, when new versions come out).

So let’s kick it off, shall we?

A common problem that developers face when building applications is how to allow the application to be “plug-able” at runtime. Meaning, to allow non-core code to modify the way an application is processed at runtime. There are a lot of different ways that this can be done, and lots of examples of it in real life. Over a year ago, I wrote a StackOverflow Answer on this topic. However, I think it deserves another look. So let’s look at some patterns and common implementations.

As any of you who follow the PHP internals list know, scalar type hinting has been a hot topic as of late. You’ll also know that I’ve submitted two new RFC (Request For Comment) proposals for inclusion of two new major features in the PHP language. I figured it was worth going into both RFCs and patches a little deeper, explain my rationale and (hopefully) garner some more visibility of the proposals.