Things That Matter Most

Things That Matter Most

World Domination through WordPress Security

by 1 Comment

WordPress powers over a quarter of the Internet. That’s quite a statement for a platform that began its life as a fork of a blogging engine. It’s also quite refreshing since WordPress is the reason I learned to write code in the first place.

One of the reasons WordPress is so popular is because it’s so easy. It’s easy to use as a writer. It’s easy to manage as a site administrator. It’s easy to code as a developer. This learning curve associated with WordPress is relatively flat – many devs and users can dive right in and get something functional from day 1 with little to no outside help.

Another reason for WordPress’ popularity is its long memory. WordPress has been around for over a decade, and the core development team has always prioritized backwards compatibility with the platform. Users of older versions of the software can upgrade to the latest version with, often, no loss in functionality. 1

Unfortunately, this long tenure also means that many in the community have a long memory of WordPress as well. They remember the days before plugins. The days before CSRF tokens were in common use throughout the codebase. The days when everyone just assumed WordPress was insecure by default.

Is WordPress Insecure?

Along a similar vein, WordPress is still very insecure.

At conferences I often remind people that the core code that powers WordPress is, in itself, vetted, secure, and reliable. The insecurities in code arise when administrators add a custom theme or start installing unverified third-party plugins. Any time you add someone else’s code to the system, you add a potential inroad for code-level vulnerabilities.

That being said, there are also specific platform-level risks 2 that affect the system.

Among the various risks presented by WordPress, there are four in particular that I see most often in conversation:

Insecure Logins

A few versions back, WordPress removed the default “admin” username and started enforcing stronger passwords for authentication. These are both good changes to make, but don’t necessarily take things far enough. WordPress does not ship with a multi-factor authentication system. The core team has been working to build one; unfortunately the current solution bundles so many potential options as to paralyze site administrators. They can choose anything from FIDO U2F to Google Authenticator to an email-based system.

It’s a good start, and will definitely help secure WordPress logins, but it’s bringing too many options to the table.

Insecure Emails

If you forget your WordPress password, you can easily request a reset link from your site by providing either your username or your email address. The downside with this functionality is that anyone with access to your inbox can then use this link to reset your account.

You use a different password for Gmail and for your blog? Great! Unless someone steals your Gmail password … then they can also steal access to your WordPress account.

Insecure Front-ends

Many WordPress sites are rocking HTTPS thanks to Let’s Encrypt and the awesome integrations managed WordPress hosts are forming with the project. Sadly, just as many sites are failing to prevent mixed content or are trusting the scripts on their site to CDNs or other remote providers who may or may not be injecting malicious code. The sheer number of people who recommend using a CDN-hosted jQuery versus the version that ships with WordPress 3 shows how often developers are lead to trust an outside party to load executable code onto their site.

Insecure Upgrades

WordPress ships all updates (core, themes, and plugins) from a central server, but does nothing to ensure the integrity of the code downloaded. On the one hand, if the central WordPress.org server distributing updates were ever breached, more than a quarter of the Internet would be vulnerable to malicious software.

On the other hand, if your server is behind any sort of proxy and that proxy is attacked, whether or not WordPress.org is shipping rock-solid code becomes a moot point. There’s still no way for you to verify the proxy didn’t modify the payload before you received it. 4

Changing the Conversation

I’m tired of people lamenting the state of security with WordPress and doing nothing to address it. To be certain, there have been some significant efforts to address these security risks, but they either haven’t landed or have been de-prioritized to the point of obscurity. That’s a major disappointment, but I’m not going to just sit back and do nothing.

Instead, I’m going to open source the solutions I’m personally building to help fix the holes and turn the conversation around.

Insecure Logins

I continuously beta test various login security plugins to see how they can help average users stay more secure. The Two Factor plugin the core team is kicking around is great for people who know what they’re doing and want multiple options for authentication. I like it because I can use it with a Yubikey. I don’t like it because most users don’t even know what a Yubikey is.

I started with that plugin as a core, but reworked it to focus just on using a time-based OTP app and released a simplified fork named Dovedi. This plugin uses a lot of the same techniques, but is tested to work with everything from Google Authenticator on Android to Windows Authenticator on Windows Phone. 5 I wanted to target technology many users already have – even if they’re not already using an Authenticator app, it’s something portable enough they can use it with other systems as well.

Dovedi was my first step in helping to make WordPress secure.

Insecure Emails

I’ve written extensively elsewhere on the need for and ease of configuring encrypted email systems. I use both GPG and S/MIME myself to ensure messages are signed whenever I send them and encrypted when they need to be. Once you have an email client capable of receiving and decrypting messages, the next trick is getting WordPress to send encrypted messages.

This past weekend, I released a new plugin called Secure Messaging that uses GPG to automatically encrypt password reset emails before they’re sent to a user for reclaiming their account. Once you’ve given WordPress your GPG public key, no one but you (with your private key) can ever steal your account, even if they somehow manage to hack your inbox.

Insecure Front-Ends

One of the coolest tools I’ve seen lately is Mozilla’s Observatory. This tool scans your site for compliance with many different security features:

  • A content security policy that whitelists the domains allowed to serve scripts, images, fonts, and iFrames
  • Whether or not your site properly implements HTTPS and if it strictly prevents TLS downgrade
  • Whether or not your site implements sub-resource integrity for remote scripts
  • If your site is protecting against cross-site scripting or frame-injection attacks
  • And so on

By default, it’s difficult to get WordPress to score well under these tests. 6 I’m collaborating with a couple of other developers to flesh out a plugin that helps configure a WordPress site to score much better according to these scans.

Remember, a higher score means a more secure front-end and a safer experience for your customers.

Insecure Upgrades

It doesn’t look like the core team will be cryptographically signing updates or payloads any time soon. That being said, I still want to ensure sites I interact with are receiving vetted, secure code. To that end, I will be publishing a list of signed hashes for core files (and a handful of plugins and themes) myself.

I will also be writing a plugin to force the WordPress updater to verify these hashes before completing the upload.

This obviously won’t fix a hacked site, and it won’t protect against all possible avenues of attack. However, it will help ensure that critical code being download through an automated update (via a proxy, for example) is guaranteed by me to be free from outside manipulation.

Next Step: Profit?

All of this is a labor of love. The tools above are, like almost everything else I do, freely available as open source. Where possible, I license under the terms of the MIT license (but use the GPL on tools like Dovedi, which are forked from others). All of the above constitute a fair amount of work on my part, but my goal is to provide these tools to the community and help change the conversation about WordPress and core security.

If you want to help, feel free to reach out to me on Twitter. If you want to contribute financially, donations are always gladly accepted.

The best way to help, though, is to raise awareness and offer feedback. Where are the rough edges in WordPress or in the systems that secure it? What could be done to make the “secure” way to do something the “easiest” way?

Notes:

  1. I personally upgraded a WordPress 2.3 site to 4.0 once. For context, version 2.3 came out 7 years before version 4.0. Still, the upgrade went flawlessly with zero lost content. The old theme even still worked on the newer platform! ↩
  2. I use the term “risk” instead of vulnerability here because each of these potential issues requires specific expertise to exploit. They’re also easy to defend against in a rigorous system. They are still risks, though, because it’s even easier to fall prey to a hack merely by being lazy or misreading a configuration tutorial. ↩
  3. These two are not equivalent. WordPress enables “no conflict mode” by default by adding a line to their own script! ↩
  4. For all the talk about why update signing isn’t a priority, the risk of a hacked proxy is significant to anyone running on a managed host, in an enterprise environment, or retrieving data through any sort of cached proxy (or external update system like Packagist). ↩
  5. The hash spec is implemented roughly the same for both, but Windows requires a longer key than Google does. I needed to increase the byte length of device secrets to gain universal compatibility. ↩
  6. My “dev journal” on WordPress.com, for example, only scores a D where an A+ is possible. If WordPress.com is the “gold standard” for WordPress hosting, we’ve obviously got a lot of work left to do. This site, hosted on WP Engine at the time of this writing, does even worse with an F. ↩

Managing Gearman Securely

by 1 Comment

A few years back, I was introduced to the world of task and job queues. A friend was writing a tutorial on RabbitMQ, and I’d discovered Gearman as a potential solution for a large task I was working to complete. The idea of leveraging multiple servers to complete a single task in parallel was a foreign concept to me.

Once I’d mastered the idea of concurrent processing, I never looked back.

Learning Curve

The biggest downside of working with new server technologies is often that you need to learn the technology on a server. Keep in mind that I was learning Gearman while still using WAMP for local development; the idea of running a local VM hadn’t occurred to me, so I learned the API by cowboy-coding against a Digital Ocean droplet.

Version control made my lessons (and mistakes) very public, so I worked to learn quickly.

Learning quickly meant I missed a step or two along the way in my education. I haven’t worked with Gearman directly in a few years, so I took some time to brush up on the PHP interface to see what I could remember.

The Job Server

Gearman is split into two components – the server and workers. The server acts as a central “hub” that can accept job information from various clients and make it available to workers when they come online. There isn’t much to the application itself; it’s a daemon that runs persistently on the server and holds job data (both incoming and outgoing) in memory until it’s needed.

Gearman can work with a persistent database backend to keep information around in the event of a reboot. If your application is mission-critical (i.e. billing) or takes a long time to complete (i.e. sending email newsletter subscriptions), maintaining a persistent backend is a good idea.

Installation is straight-forward, thanks to package managers for all of the major Linux server distributions. Some developers have even built Dockerized distributions, if that’s your thing. The point is: you need a server somewhere, listening on port 4730, that both workers and clients can connect to.

Workers

Workers are, usually, simple PHP scripts that can be daemonized on the server. Your approach to daemonization is up to you – in the past, I’ve used Supervisord to keep a few copies of the script running or have Dockerized the process with a restart declaration.

The script itself merely registers a “function” with the Gearman server. Like any other piece of PHP code, this function takes arguments and returns data, it just takes its arguments from a dynamic process (Gearman) and returns data to the same.

Assume for now you have the desire to process PDF documents in bulk on the server, for optical character recognition, machine learning, or some other purpose. There are a lot of documents to import, so you want to parallelize the operation over multiple worker processes (and potentially multiple servers as well). Your code might take the form of a PHPImporter object with a single import() method:

// worker.php
$importer = new PDFImporter();
$worker = new GearmanWorker();
$worker->addServer( 'localhost', 4730 );
$worker->addFunction( 'import', array( $importer, 'import' );
while( $worker->work() );

For the sake of this example, the worker script will run on the same server that’s running Gearman itself, hence the binding to localhost above. In a real-world example, the local reference would be replaced with the IP address of the central server (or multiple servers in a distributed case).

This worker will run forever and will wait until a task is available on the local Gearman hub to process. It exposes a single function to the Gearman server, though it could expose many. Likewise, there could be multiple workers exposing different functions all to the same hub.

The beauty of Gearman is that you can use different languages to build the workers. This example uses PHP alone, but there are libraries for Java, Python, Ruby, Go, and many other languages as well. In theory, you could write have two workers written in different languages expose the same function to Gearman.

The Client

The client is just as simple. It’s an operation within PHP (or your language of choice) that connects to Gearman and publishes a job to be processed. Often, you’ll want to run a job in the background, meaning the main application doesn’t wait for the take to complete before completing itself. This would allow a single application to create multiple jobs at once, then exit back to a browser or command line for further instruction.

// app.php
$client = new GearmanClient();
$client->addServer( 'localhost', 4730 );
$job = $client->doBackground( 'import', $file . '||:||' . $email );
$db->record( $job );

Gearman automatically returns a job ID that can be used to query for the job’s status later on, if required. The example above fits with our PDF import illustration from earlier and instructs a Gearman server to execute a function named “import,” passing it a concatenated string with a filename and an email address for later notification.

Keep in mind that Gearman workloads (the second argument in the invocation) are only strings. In this example we’re passing a filename, but the workload could just as easily be the base64-encoded binary body of the file itself. Gearman supports messages up to 4GB in size – the only limit here is the bandwidth the client has available.

Security

When I first set up a Gearman server, I didn’t fully understand the ramifications of leaving the server in the public space. I was somewhat new to server maintenance, so while I could follow a tutorial to install a new application, I didn’t really understand what was going on. This meant the server I’d built was completely exposed to the Internet – anyone could connect to my Gearman server whether they were running my code or not.

Think about that for a moment.

Anyone who knew I was running Gearman and the IP address I was using could leverage my server for their own purposes. Among other things, they could:

  • Enumerate the functions I had registered on the server
  • Invoke a function I had registered (even with a malicious or inaccurate payload)
  • Register their own functions on the server

Given Gearman’s flexibility, a third party could even register a new worker to manage an already-registered function. Gearman would happily forward along any invocations, failing to distinguish between legitimate workers coded by me and malicious workers coded by a third party.

With the PDF processing server illustrated in the examples above, this might not be too much of an issue. Our machine learning database would be missing a few documents or might have some junk data inserted by a third party. If Gearman were instead being used to parallelize stock trades or process credit transactions or notify medical study participants of information …

The impact of an improperly-secured Gearman server grows with the importance of the application using it.

In the Wild

I use a tool called Shodan on occasion to check that my servers (and Raspberry Pi clusters) are properly locked down while still visible on the public Internet. Shodan is an amazing tool, but it’s also a treasure trove of information for potentially malicious parties as well. In addition to scanning specific IP addresses, it also maintains a directory of machines listening on specific ports.

My last check through Shodan showed over 8,000 individual servers listening on port 4730, the default port for Gearman. I didn’t drill down much further than that, 1 but Shodan ran a simple status query when it indexed these machines; the public database lists both the machines and their registered functions.

Remember, if your machine is visible to tools like Shodan, it’s visible to malicious third parties who can manipulate or steal your data.

Locking things Down

Thankfully, the situation doesn’t have to be dire. Gearman itself doesn’t have any authentication, but the server running it can protect the daemon from abuse. Simply configure your server’s firewall to block connections on port 4730 from everything except localhost and any specific, whitelisted servers. Shodan won’t be able to index you and third parties won’t be able to abuse your installation.

Gearman is a powerful application that you can and should be using to parallelize the processing done by your PHP server. It’s also something that can easily expose you and your team to undue stress if not properly configured and secured. Take some time today to lock your Gearman servers down.

Then take some more time to ensure your other hosted applications are properly protected as well.

Notes:

  1. I did not connect to any of these machines. I merely enumerated the cached listings stored in Shodan’s public database. Accessing someone else’s computer system without authorization is illegal. ↩

Introducing Sessionz

by 12 Comments

Not that long ago, I made an attempt to fix what I saw as one of the biggest issues facing session management in WordPress. Many larger sites use multiple servers for presenting content, but the lack of sticky sessions on the load balancer 1 means that standard PHP sessions, which live in the filesystem, tend to fail quite quickly.

My first attempt, WP_Session, was a great prototype and helped prove the need for a solid solution. Unfortunately, it was prone to many issues on its own.

The Issues

As I was trying to prove a WordPress solution, I used WordPress as a platform itself. This isn’t an issue, per se, but it meant my experiment was limited to only WordPress sites and feedback. The limited scope of the project was an issue.

I also used the WordPress database for session storage. Again, not an issue on its own, but my aim at not changing the database schema did become an issue. WP Session Manager stores data in the options table by default – for smaller sites, this is OK. For larger sites, this can slow the server to a crawl as that table isn’t indexed for the kind of data we were throwing at it.

Finally, the system I had built was a reinvention of a wheel that already worked quite well. Instead of using PHP’s native sessions, I built an entirely new system from scratch that required developers to learn a new interface and made their code completely reliable on my very specific implementation. Understanding how cookies were created and curated alone was problematic, and that was the smallest component of the system.

The New Player

Over the past year, I’ve been able to step away from WordPress a bit and have learned how other platforms (and languages) are choosing to solve similar problems. I’ve been blown away by how fluent and efficient systems for request middleware have become, and I started to think about how that might affect session management as well.

Enter my new experiment: Sessionz.

Sessionz is a middleware-inspired session management stack that works for any PHP application running on PHP 5.6 or better. 2 Like a request middleware stack, you can add in additional handlers to take care of different abstractions for your session.

Right now, Sessionz has implementations for:

  • The default PHP session store
  • Storing session data in-memory for persistent PHP applications
  • Encrypting data before it’s written out (and decryption before it’s loaded back in)

The project itself uses PHP’s native session implementation, so there’s no additional library to learn. Just add the project with Composer, initialize and set up your stack, then use $_SESSION everywhere else like you normally would. Sessionz works transparently in the background to make your life easier.

What’s Next

I’m working on a new version of WP Session Manager that will leverage Sessionz under the hood. The old interfaces will still work, but will trigger a deprecation warning. Like the older implementation, I’ll still use the WordPress database for persistence, but will set up a hidden post type so we don’t fill up the options table. 3

I’m always open to feedback and suggestions! Take a look and let me know what you think.

Notes:

  1. This one change, making sessions sticky, can often correct the issue on its own. That said, some hosting environments don’t allow enough control over the stack to make such a change in the first place. ↩
  2. Yes, I could run this on older PHP, too … but older PHP is no longer supported. If you’re running anything less than PHP 5.6 in production, you’re just asking for someone to hack your site. Quit it. ↩
  3. Using a CPT will also allow us to query for and purge expired sessions using an actual date field in the database. There is no understating how much this will improve the plugin’s performance. ↩

Deprecate Magic Constructors in PHP

by 3 Comments

The PHP community is currently voting on whether or not to deprecate var in favor of public for classes starting in version 7.1. This is an interesting idea, to say the least, but the arguments against it are even more compelling.

So there’s a small mental tax for a human to read and interpret the entire line. It’s generally accepted that shorter lines are better, and when ‘scanning’ a file from top to bottom, it’s better that the important keywords (the name of the function) are closer to the left-edge of the screen.

Along the same lines of this argument – to make code easier to understand for quick readers – I want to propose something a little less radical and just as useful for devs: Deprecate the magic __construct() function.

Rationale: It’s Ugly!

PHP is one of the easiest-learned languages available for fledgling developers. Documentation is deep, code examples exist just about everywhere, and it’s such a flexible language that you can write horrible code and have it still just work. 1 But we still have certain “magic” functions in our code layer that make things harder for non-experts to understand.

I’m looking at you, __get(), __set(), and __construct().

The getters and setters can easily be ignored by merely making everything public to begin with. After all, even internal var properties are public by default, so why even use a getter? It’s just additional OO cruft added to confuse newcomers.

Reading through a class quickly, catching the reference to a __-prefixed magic method can be difficult. It makes a developer pause to consider what they’re doing. It’s even more confusing since, traditionally, leading underscores used to mark a method as “private.” With a double underscore, it almost makes it look like the constructor is “double private.”

And who ever wants to call MyClass::__construct() to build an object? That’s just nonsense!

Alternative

Instead, we should introduce a completely new paradigm in future versions of PHP that support a constructor named identically to the class itself:

<?php
class MyClass {
  function MyClass() {
    // Do constructory stuff here
  }
}

When you read that code, it’s obvious the function is the constructor because of their shared name. You’d never want to write MyClass::MyClass() – that would just look dumb – so remembering to use the new keyword for instantiation is an intuitive bonus this pattern wins for us.

Thoughts?

Once we get the ball rolling with removing the ugly __construct() setup, we can start targeting the other magic methods and truly make PHP an accessible language for even those who don’t know how to write code. That’s the dream of programming, after all.

What other features of PHP should we drop as we move forward with future versions?

Notes:

  1. I’ve seen bugs in PHP code only surfaced and fixed when the maintaining dev team has started refactoring the code for a new system like Ruby. The old bug had been there for years without impacting the function of the application. Isn’t that awesome?! ↩

Clean up your clutter

by Leave a Comment

A developer friend of mine asked an interesting question 1 yesterday on Twitter.

This question was interesting for a multitude of reasons:

  1. It’s not that uncommon. Many developers in the WordPress (or even just PHP) space use globals as a way to quickly and easily transport objects from one file or context to another.
  2. It demonstrates a too-common design pattern that is the largest stumbling block to new developers trying to learn object-oriented programming.

The Rationale

Many developers conflate object oriented programming (OOP) with using classes. Unfortunately, there are many things you can do with a class in PHP that look object-like but are in fact not.

Let’s say you have a set of utility functions you need to use multiple places throughout your code:

Functions are miniature programs that can live in our out of classes and provide some sort of functionality that is both stateless and independent of where it’s called. Methods are a specific type of functions that belong to an object and act only in the context of that instance of an object.

When working on a complex project, it’s often easier to just drop a utility function into an existing object definition so that function becomes available wherever the object exists. When a project is large, filled with legacy code, or you’re just so far in that a client won’t give you room to refactor (as in this particular case), this is often the easiest way to get what you need done, done.

Unfortunately it also pulls some really bad coding designs into your project and helps to perpetuate a misunderstanding (in the PHP world) of how OOP and functions really work. If you need a function in PHP that behaves in a certain way, it shouldn’t be part of an object at all. 2

Methods on objects should relate to the object on which they’re defined. Static functions wrapped within an object definition should still relate in some way to the object being defined. If you need a truly stand-alone function, leave it as a function and put it in a namespace instead.

One example of how some are doing things:

class My_Stuff {
  public function my_function() {
    // .. do something awesome
  }
}

$Globals['my_stuff'] = new My_Stuff();

// In another file
global $my_stuff;
$my_stuff->my_function();

An example of how things should be done:

namespace My_Stuff;

function my_function() {
  // ... do something awesome
}

// In another file
My_Stuff\my_function();

Globals

The “how some are doing things” example creates a standalone instance method rather than a static class function. If the function were static, a developer could easily just call My_Class::my_function() anywhere in their code without issue.

If instead this is a method, then the developer needs a reference to a class instance to call it:

// Either
$my_stuff = new My_Stuff();

// Or
global $my_stuff; // instantiated elsewhere

// Then
$my_stuff->my_function();

If your class is defined in one file, instantiated in another, and the instance method is needed in yet another function (and for some reason you can’t create a second instance of the object), you’ll be tempted to store the original instance in a global variable.

This is a bad idea.

Global variables exist for every part of your application. From the time they’re instantiated to the time the PHP thread invokes shutdown(), your object will be sitting there, occupying memory, waiting to be used. One global object isn’t too bad; once you introduce the pattern, though, the global namespace begins to get crowded as more and more objects will be lying around as new developers join the project and copy-paste your design.

Lots of objects in the global namespace equals lots of memory consumption by your application.

Instead, be very careful about what information you actually need at different stages of the application. If you need an object in a function, take that object as a parameter to the function call. If for some reason you can’t add another parameter, create an object factory that can reliably return the object instance you need regardless of where you reference the factory. 3

The short version: global variables are bad, clutter your code, and can be a major stumbling project in terms of project maintainability. Don’t use them.

Notes:

  1. I don’t fault Michael for this question at all. I’ve been in exactly the same boat with a project and asked the exact same question myself. Globals are a messy but very tempting non-solution to several problems that come up in PHP development. I’m often reminded by my team of how much I despise the use of globals because, honestly, they still show up in my code occasionally. ↩
  2. A caveat here is when working with PHP < 5.3. Earlier versions of PHP lack namespacing capabilities, so static classes that represent a collection of statically-defined methods are often used as pseudo namespaces. This is acceptable, so long as you remember that you’re not building objects and thus not doing OOP. ↩
  3. Storing a reference in an object factory will still keep it around and use memory. But the factory can also be smart about memory management and recycle the object if needed later. Also, either using a factory or passing an object by reference makes your code more unit-testable as it eliminates hidden dependencies on globals. ↩

Scripting vs Programming: PHP and OOP

by 10 Comments

When I started my professional career as a developer, I dabbled in several programming languages. I built software in Visual Basic, C#, PHP, Ruby, Python, JavaScript. I hadn’t settled down on one particular language, and it made getting help a bit difficult.

What as the most confusing was how different professionals categorized each language. Some were “programming languages.” Others were “scripting languages.” I didn’t have any idea what that meant; it felt incredibly arbitrary and was often a distinction used in a condescending manner.

Now, with a few years of experience under my belt, I’m comfortable explaining the difference.

Scripting

A scripting language is one used, typically server-side, to script the behavior that handles a request. A client makes a request though their browser or application, the server parses that request and passes it to a script, the script generates a response and passes it back to the client through the server.

When you make a request to WordPress, you’re using PHP as a script. When you make a request to a Django app, you’re using Python as a script. When you make a request to a Rails app, you’re using Ruby as a script.

You’re not using a long-lived program, you’re using a script.

Programming

Conversely, a programming language is used to build a long-running application. A single instance that handles multiple requests. Visual Basic, C#, and C++, for example, are all compiled programming languages that, when compiled, produce a binary application. These applications can be instantiated on a server (or client) and run indefinitely, handling requests as they come in and producing the appropriate response.

Similarly, JavaScript is an interpreted programming language that runs through a just-in-time compiler to produce a compiled, long-running, in-browser application that can listen for and process multiple requests from the browser. This long-running, event-driven nature of JavaScript makes it a great candidate for server-side programming as well thanks to Node.

In any case, JavaScript and its compiled relatives are programming languages, not mere scripts.

The Consequences

Talking about object-oriented programming in PHP is all the rage right now. Conferences feature numerous presentations on “OOP best practices,” the number of PHP books about object outnumber those in other languages on the shelves at Barnes and Noble, and most technical blogs are covering different object-related design patterns and tips.

OOP doesn’t make much sense when we’re talking about a scripting language, though.

Because PHP is a scripting language, your carefully-constructed objects only live for a single request. Debating Singleton patterns in a world where your object is only ever instantiated once during a request is bikeshedding. Learning proper object lifecycle management – I’ve only seen a developer use a proper destructor once – isn’t really necessary when the script flushes everything down the drain at the end of the request.

The consequence of using a scripting language to power the web is that we spend too much time trying to shoe-horn object-oriented programming concepts into a place where they don’t really make a different in the way of performance.

That said, the patterns we use when building an OOP application do help for better code organization and readability. We just need to be very careful when heralding OOP as “the only way” in a scripting world, as it’s not. It’s not even the most necessary metric against which we judge our PHP applications.