The PHP language is experiencing a renaissance. PHP is transforming into a modern scripting language with helpful features like namespaces, traits, closures, and a built-in opcode cache. The modern PHP ecosystem is evolving, too. PHP developers rely less on monolithic frameworks and more on smaller specialized components. The Composer dependency manager is revolutionizing how we build PHP applications; it emancipates us from a framework’s walled garden and lets us mix and match interoperable PHP components best suited for our custom PHP applications. Component interoperability would not be possible without community standards proposed and curated by the PHP Framework Interop Group.
Modern PHP is your guide to the new PHP, and it will show you how to build and deploy amazing PHP applications using community standards, good practices, and interoperable components.
Before we explore modern PHP, it is important to understand PHP’s origin. PHP is an interpreted server-side scripting language. This means you write PHP code, upload it to a web server, and execute it with an interpreter. PHP is typically used with a web server like Apache or nginx to serve dynamic content. However, PHP can also be used to build powerful command-line applications (just like bash, Ruby, Python, and so on). Many PHP developers don’t realize this and miss out on a really exciting feature. Not you, though.
You can read the official PHP history at http://php.net/manual/history.php.php. I won’t repeat what has already been said so well by Rasmus Lerdorf (the creator of PHP). What I will tell you is that PHP has a tumultuous past. PHP began as a collection of CGI scripts written by Rasmus Lerdorf to track visits to his online resume. Lerdorf named his set of CGI scripts “Personal Home Page Tools.” This early incarnation was completely different from the PHP we know today. Lerdorf’s early PHP Tools were not a scripting language; they were tools that provided rudimentary variables and automatic form variable interpretation using an HTML embedded syntax.
Between 1994 and 1998, PHP underwent numerous revisions and even received a few ground-up rewrites. Andi Gutmans and Zeev Suraski, two developers from Tel Aviv, joined forces with Rasmus Lerdorf to transform PHP from a small collection of CGI tools into a full-fledged programming language with a more consistent syntax and basic support for object-oriented programming. They named their final product PHP 3 and released it in late 1998. The new PHP moniker was a departure from earlier names, and it is a recursive acronym for PHP: Hypertext Preprocessor. PHP 3 was the first version that most resembled the PHP we know today. It provided superior extensibility to various databases, protocols, and APIs. PHP 3’s extensibility attracted many new developers to the project. By late 1998, PHP 3 was already installed on a staggering 10% of the world’s web servers.
Today, the PHP language is quickly evolving and is supported by dozens of core team developers from around the world. Development practices have changed, too. In the past, it was common practice to write a PHP file, upload it to a production server with FTP, and hope it worked. This is a terrible development strategy, but it was necessary due to a lack of viable local development environments.
Nowadays, we eschew FTP and use version control instead. Version control software like Git helps maintain an auditable code history that can be branched, forked, and merged. Local development environments are identical to production servers thanks to virtualization tools like Vagrant and provisioning tools like Ansible, Chef, and Puppet. We leverage specialized PHP components with the Composer dependency manager. Our PHP code adheres to PSRs—community standards managed by the PHP Framework Interop Group. We thoroughly test our code with tools like PHPUnit. We deploy our applications with PHP’s FastCGI process manager behind a web server like nginx. And we increase application performance with an opcode cache.
Modern PHP encompasses many new practices that may be unfamiliar to those of you new to PHP, or to those upgrading from older PHP versions. Don’t feel overwhelmed. I’ll walk through each concept later in this book.
Most mature programming languages have a specification. In layman’s terms, a specification is a canonical blueprint that defines what it means to be PHP. This blueprint is used by developers who create programs that parse, interpret, and execute PHP code. It is not for developers who create applications and websites with PHP.
Sara Golemon and Facebook announced the first PHP specification draft at O’Reilly’s OSCON conference in 2014. You can read the official announcement on the PHP internals mailing list, and you can read the PHP specification on GitHub.
An official PHP language specification is becoming more important given the introduction of multiple competing PHP engines. The original PHP engine is the Zend Engine, a PHP interpreter written in C and introduced in PHP 4. The Zend Engine was created by Rasmus Lerdorf, Andi Gutmans, and Zeev Suraski. Today the Zend Engine is the Zend company’s main contribution to the PHP community. However, there is now a second major PHP engine—the HipHop Virtual Machine from Facebook. A language specification ensures that both engines maintain a baseline compatibility.
A PHP engine is a program that parses, interprets, and executes PHP code (e.g., the Zend Engine or Facebook’s HipHop Virtual Machine). This is not to be confused with PHP, which is a generic reference to the PHP language.
The Zend Engine is improving at a rapid pace with new features and improved performance. I attribute the Zend Engine’s improvements to its new competition, specifically Facebook’s HipHop Virtual Machine and Hack programming language.
Hack is a new programming language built on top of PHP. It introduces static typing, new data structures, and additional interfaces while maintaining backward compatibility with existing dynamically typed PHP code. Hack is targeted at developers who appreciate PHP’s rapid development characteristics but need the predictability and stability from static typing.
We’ll discuss dynamic versus static typing later in this book. The difference between the two is when PHP types are checked. Dynamic types are checked at runtime, whereas static types are checked at compile time. Jump ahead to Chapter 12 for more information.
I don’t foresee Hack and HHVM replacing the Zend Engine, but Facebook’s new contributions are creating a giant splash in the PHP community. Increasing competition has prompted the Zend Engine core team to announce PHP 7, an optimized Zend Engine said to be on par with HHVM. We’ll discuss these developments further in Chapter 12.
It’s an exciting time to be a PHP programmer. The PHP community has never been this energized, fun, and innovative. I hope this book helps you firmly embrace modern PHP practices. There are a ton of new things to learn, and many more things on the horizon. Consider this your roadmap. Now let’s get started.