PHP Fog Blog

Creating PHP Fog has been an amazing experience for me and it could not have happened without all of the developers who have been using it––thank you for your business and for your support. With your help, we’ve built an amazing PaaS for PHP developers. And along the way, we’ve applied what we’ve learned to creating our new product, AppFog.

AppFog is PHP Fog 2.0

AppFog is the future of our business, and we very strongly believe it is also the future of PaaS. So, in order to focus our team and efforts on continuing to build a better solution for developers, we will be fully shutting down the PHP Fog platform (in January for paying customers and in December for free-tier customers) and focusing solely on AppFog. As we move toward this final date, some services will be disabled along the way.

We have considered this change very, very carefully because we understand that this could present challenges for some of our customers. But in the end, we are confident that moving to AppFog will give our current and future users and customers additional flexibility, additional languages, additional infrastructures, and the ability to deploy apps to private cloud infrastructure as well as leverage the strengths of the OpenStack and Cloud Foundry ecosystems.

Your Migration to AppFog

Below are links to information to help you migrate to AppFog. We’ll be creating additional migration info and how-to’s, so keep checking back.

• Our Migration FAQ helps you begin or complete the migration process
• Migrating your PHP application code from PHP Fog to AppFog
• How to migrate your data from PHP Fog to AppFog
• How to download your entire application, not just code, from PHP Fog
• How to manage multiple MySQL databases in one place using phpMyAdmin (in AppFog)
• How to use Amazon’s S3 file storage system in conjunction with AppFog

If you have more general questions that are not necessarily related to migration, we recommend checking out our PHP docs, which cover a broader variety of topics, from deployment to database connections and beyond.

I am committed to making AppFog a product that will make you look back at PHP Fog and think, “I’m really happy I switched.”

Over on the AppFog blog, I’ve posted a tutorial on using Amazon’s Simple Storage Service (S3) in conjunction with a PHP application. I’ve used a very handy S3 for PHP module to manage PHP-to-S3 interactions. Check it out!

The other day, I posted a tutorial on migrating your application code from PHP Fog to AppFog, followed by a tutorial on migrating MySQL databases between the platforms. For some users, migrating application code via git clone will accomplish everything that needs to be accomplished. But PHP users know that many PHP frameworks, from WordPress to Drupal and beyond, make file changes on the app server that are not directly accessible via Git.

Fortunately, one of our lead support engineers, Rich Howard, came up with a great tool called ZipIt for pulling all application files from your PHP Fog repo and downloading them to your local drive in a single .zip file. Check out the GitHub repo or this StackOverflow thread if you want to have a look at the code and the inspiration for it.

Running zipit.php involves only a few simple steps:

1. Download the source code from GitHub: git clone https://github.com/zeroecco/zipit.git.
2. Copy the zipit.php to the root directory of your app.
3. Add the file to Git with a simple git add zipit.php.
4. Commit changes: git commit -m “zipit has been added”.
5. Push these changes to your PHP Fog repository: git push origin master.

Now, all that you have to do is navigate to the URL associated with your zipit.php file, and the script will start running. Your URL will probably look something like this:

http://www.my-app-on-phpfog.com/zipit.php

The script could take a fair amount of time, so don’t worry if the browser spins its wheels for a while. All the work of gathering all of the directory’s files into a single zip file is automated in the script. Once it is done, it will be downloaded to your default download directory in your browser and you’ll be all set.

Once the process has been completed, both the zipball and the zipit.php file will be removed for security reasons.

There are three caveats that you should be aware of:
1. Downloads of directories larger than 500 MB have occasionally run into timeouts and space limitations. If you have trouble, try running the script a few times.

2. This process will not work with multiple-server apps, which may affect a small percentage of users. If you are a user that falls into this category, please reach out to AppFog support and we can offer additional help.

3.  The directory MUST be writable by the process executing the script (writable permissions in the app console) to remove the zipit file itself.

In the next tutorial, I will cover using Amazon’s S3 file storage system in conjunction with PHP apps on AppFog. That tutorial will run early next week and will be followed by additional tutorials on our phpMyAdmin jumpstart and other aspects of the migration process.

On Monday, I posted a tutorial on how to migrate your application code from PHP Fog to AppFog. But as all of you know, migrating code is only one part of the process of migrating an application across platforms. Migrating your data is an equally essential part of that process. In this tutorial, I will cover how to use phpMyAdmin to pull your data out of MySQL on PHP Fog and then upload it to AppFog.

This process is a bit more tricky than migrating your application code, so make sure and follow closely and reach out to us at support.appfog.com if you have any issues. In the coming days, I’ll post part 2 of this tutorial, which will go through elements of this process in more depth and cover some other important aspects of the broader PHP Fog-to-AppFog migration process.

Accessing phpMyAdmin in the PHP Fog console

First things first, navigate to the console for your PHP Fog app. There, you’ll see a button for launching phpMyAdmin:

When you click on that button, you’ll be taken to a page that you should be quite familiar with if you’ve used phpMyAdmin in the past. Near the top of the page, click on the Export button in the toolbar. That will take you to a page that looks like this:

In this tutorial, we’ll through a “Quick” MySQL export. Feel free, however, to customize your export if the need arises. The “Custom” option allows you, for example, to save the output in a variety of file formats (we strongly recommend SQL), choose what kinds of CREATE, USE, and other commands you want contained in the file, and so on. Be aware, however, that the Quick option will in most cases provide the quickest database migration route.

When you click Go, a new <database-name>.sql file will be saved in your default download directory on your local drive. If you see this .sql file in that directory, then that means that the MySQL database that was previously powering your PHP Fog application is now on your local machine and ready to go.

Your .sql file is ready to go. Time to upload to download the phpMyAdmin jumpstart

Now that your MySQL database has been pulled down to your local machine, it’s time to use phpMyAdmin to push it up to AppFog. Fortunately, there is a phpMyAdmin jumpstart for AppFog that enables you to accomplish this very quickly.

Using this jumpstart involves the following steps:

1. Clone the Git repository for the jumpstart:

$ git clone https://github.com/appfog/af-php-myadmin.git

2. Navigate to the af-php-myadmin directory you just created with the Git clone.

$ cd af-php-myadmin

3. Create your phpMyAdmin credentials:

$ htpasswd .htpasswd <username>

This username can be anything you’d like it to be. Make sure and remember it, however, as you’ll need it to access phpMyAdmin on AppFog in the future (though you may change it later if you’d like). Once you’ve entered a username and hit Enter, you’ll be prompted for a password and then to confirm the password. Once that’s done, you’re ready to get phpMyAdmin up and running on AppFog.

Setting up phpMyAdmin on AppFog

All the necessary files for phpMyAdmin are now on your local machine, so let’s get the app up and running. From the af-php-myadmin directory, run the following command:

$ af push

In order for this command to work, you will need to have an AppFog account and have both Ruby and the af Ruby gem installed. For more on that, check the AppFog docs. If you do have both installed, and you have an AppFog account, and you’re logged in (if not, run af login and enter your credentials), then the af push command will bring up the following set of prompts:

• Would you like to deploy from the current directory? [Yn]:
  • Type in “Y” and hit Enter
• Detected a PHP application, is this correct? [Yn]:
  • Again, type in “Y” and hit Enter
• Then, you’ll be prompted to select an infrastructure. The options are AWS US East (Virginia), AWS EU West (Ireland), AWS Asia SE (Singapore), Rackspace AZ 1 (Dallas), and HP AZ 2 (Las Vegas). Select the one you wish to deploy to by number and hit Enter.
• At that point, you’ll be given the URL for your phpMyAdmin application. I have chosen lucperkins-pma as my app name and AWS US East as my infrastructure, so the resulting URL is lucperkins-pma.aws.af.cm. Copy this URL and hit Enter to confirm.
• Memory reservation (128M, 256M, 512M, 1G, 2G):
  • For most databases, a 128 MB memory reservation should work just fine. If it doesn’t, you can always retroactively increase the memory reservation by running af mem <appname> [memsize] to change the memory allocation.
• How many instances? [1]:
  • One instance is the default and should be sufficient for phpMyAdmin, so simply click Enter on this prompt.
• Bind existing services to ‘<appname>’? [yN]:
  • If you have not yet set up a MySQL service on AppFog, type in “n” and hit Enter. If you have indeed set up a MySQL service, type in “y” and hit Enter, and you will be prompted to select the MySQL service that you want to use.
• Create services to bind to ‘<addname>’? [yN]:
  • You will only be prompted for this if you do not currently have a MySQL database on AppFog to bind to phpMyAdmin. If you reach this prompt, type in “y” and hit Enter.
• At this point, you’ll need to choose a service type from the five available options: MongoDB, MySQL, PostgresQL, RabbitMQ, and Redis. You will need to select number 2, MySQL and hit Enter.
• Specify the name of the service [service-name]:
  • Here, you can either accept the randomly generated service name (which should look something like mysql-1234 or enter your own name. It’s up to you.
• Create another? [yN]:
  • No need to create another service. Type in “n” and hit Enter.
• Would you like to save this configuration? [yN]:
  • Yup! Select yes and hit Enter.

At this point, you should see the following output:

Manifest written to manifest.yml.
Creating application: …

It should take only a few seconds to create and deploy the application. Once you get a string of green OKs, enter the URL generated for your app, paste it into your browser, enter the credentials you just selected, and voilà. You should see a phpMyAdmin interface that should look something like this:

You’re almost there!

phpMyAdmin is now running on AppFog. Time to upload our DB!

The beauty of phpMyAdmin is that the UI is super intuitive, and something we’re all quite familiar with. That’s why we chose it as the preferred option for migrating databases across our two platforms.

First, however, there is one important change you need to make to your .sql file. Open that up file up in your favorite (preferably non line-wrapping) text editor.

Now, you need to replace the database name currently in your .sql file with the database name provided in your phpMyAdmin app. This is a little bit tricky, but it involves just a few basic steps. In your phpMyAdmin instance running in your browser, click on the Databases tab in the top toolbar, and you should see something like this:

That gibberish-looking database name is exactly the one we’re looking for! Copy it, and then go to the .sql file already open in your preferred text editor. First, delete or comment out the line that begins CREATE DATABASE `<database-name>` but make sure and leave the line that begins USE `<database-name>`.

Then, anywhere in the file that you see the database’s current name (mine is lucperkins2_phpfogapp_com), replace it with the name from phpMyAdmin. For me this meant changing this

USE `lucperkins2_phpfogapp_com`;

to this:

USE `d43ad481c1cc24371b64453d312ebdf57`;

Now, go into phpMyAdmin running in the browser, and click Import in the top toolbar. This will take you to a page where you can accomplish your .sql file import. That page should look like this:

To upload your .sql file, all you have to do is click on the Choose File button, find your database file (which may or may not still be in your default download folder), select it, and then click Go at the bottom.

Once you’ve done that, phpMyAdmin will take care of all the rest. It will create and populate the necessary tables. If you look at the left side of the main phpMyAdmin page, you should see your tables listed there. My database had only two tables, named Test and User Table respectively:

At this point, my database is up and running, manageable via phpMyAdmin in the browser (as well as through other means, such as af tunnel, which will be covered in a later tutorial), and ready to be used in conjunction with my PHP apps running on AppFog (as well as Node, Python, Ruby, Java, Scala, Clojure, and other apps).

If you experience any troubles with migration, reach out to our support team and they’ll get you squared away as soon as possible. We know that this is can sometimes be a tricky process, and we’re happy to help any way we can!

Tune in for another database migration tutorial coming very soon which will cover command line migration options, database tunneling on AppFog, and other important elements of running PHP apps on our polyglot, multi-infra platform.

Please not that I will not be covering data migration in this post. I will be covering that in just a few days. This tutorial will show you how to migrate only your application code to AppFog.

We know that a lot of PHP Fog users have checked out AppFog, and that some of you have even migrated apps to AppFog. But a lot of you haven’t had the chance yet.

We also know some current PHP Fog users might have certain concerns regarding PHP Fog-to-AppFog migration. Isn’t AppFog a lot different? Isn’t the deployment and management process a completely different animal?

We understand these concerns 100% and are here to assure you: there is actually a lot of overlap in how the two platforms work, and migrating between them can in most cases be accomplished quickly once you know some of the key differences.

For the sake of this demonstration, I’ll be migrating a super-duper simple PHP app (the code is on GitHub). As you can tell, it probably won’t be nominated for a Webby this year (!). It does, however, have just enough dynamic PHP-based functionality to allow us to ascertain whether or not our migration has worked.

So let’s go through the steps one by one.

Signing up for AppFog

First things first: score yourself a free AppFog account at console.appfog.com. It’s the same thing we’ve all done a million times: e-mail, password, and then e-mail verification. Once you have your account set up, you’ll get what everyone gets: the most generous free tier in the entire world of PaaS, with 2 GB of RAM, 10 service instances, a 50 GB data transfer limit, free custom domains, free access to AppFog support, and much more.

Installing the AppFog command line tool (CLI)

Now, you need to install Ruby and RubyGems. Following the instructions in these links should get you going quickly. If you’re on Mac OS X or on many Linux distributions, Ruby and RubyGems will already be installed. In a *nix environment, check if Ruby is installed by running ruby -v and if RubyGems is installed by running gem -v. If the response is blank or something like command not found, then you’ll need to go through the install process appropriate to your OS.

Once you’ve got Ruby running, you will need to install the af Ruby gem with a simple install command:

gem install af

This will enable you to use the AppFog command line tool to manage PHP app deployment. If you’re unfamiliar with the command line, don’t worry: using the CLI tool is dead simple, and even advanced users tend to use only a few commands, like af push, af update, and a few others.

Migrating an already existing PHP Fog app using the AppFog CLI

So let’s assume that you have an already existing PHP Fog app housed in the directory ~/desktop/my-php-app. Deploying that app on AppFog requires running just a few commands and responding to some prompts.

First, navigate to the root directory of your PHP app. I’m running Mac OS X and storing my app on the desktop, so my navigation will look like this:

cd ~/desktop/my-php-app

I’m already signed up for AppFog, so I’m going to run af login to get logged in to AppFog. I’ll then be prompted for my username and password. If I get Sucessfully logged in as a response, then I’m all set.

AppFog is now ready to accept my application code. All I have to do at this point is run the af push command, and AppFog will do the rest for me via a series of prompts.

Here is a basic rundown of that series of prompts:

• The name of the application. As in the console-based example above, I’m going to choose af-plus-php-equals-win for the name, which will produce the URL af-plus-php-equals-win.ap01.aws.af.cm. AppFog supports custom domain names, but this will be the app’s URL to begin with. For now, it can be whatever you want it to be, provided that it isn’t being used already. So go nuts.
• The type of app. The af gem will automatically detect that you’re deploying a PHP app, so just say “yes” when you get this prompt: Detected a PHP Application, is this correct? [Yn]. If it doesn’t automatically detect a PHP app, then it will prompt you which runtime your app is using, and you may select PHP from the list by number.
• Select an infrastructure. If you’ve gotten this far, the AppFog server will want to know on which infrastructure you want to deploy. Select one of the currently available options by number and hit Enter. At the moment, there are five options available: AWS US East, AWS EU West, AWS Asia SE, Rackspace AZ 1, and HP AZ 2. A PHP app that runs on any of those infras will run on all of them. The choice is 100% up to you. And there will be more infras on the way soon.
• URL for the app. If you’ve selected an available app name/URL, it will prompt you with this: Application Deployed URL [php-app.aws.af.cm]:. Simply select yes by typing “y” and hitting enter.
• Allocate memory. You’ll be prompted to input your memory reservation. You’ll have the choice of 128 MB, 256 MB, 512 MB, 1 GB, or 2 GB. Manually type in the amount that would like to use and hit enter. 128 MB will appear in brackets because it’s the default. This will all depend on the size of your app. PHP apps tend to not be very memory-hungry, so select 128 MB to begin with and go from there.
• Allocate instances. If you’re not planning on getting crazy amounts of traffic directly out of the gate, then I’d recommend going with just one instance. This can always be changed later if you need to scale up.

Once you answer all of these prompts, it should upload your app, push it, stage it, and then start it. Just like that!!

What I like is that the CLI will automatically create a manifest.yml file in the main directory. This file is a basic repository for the input that you enter concerning the number of instances you want to run, how much memory you would like to use, etc. Other sites that I’ve used for app deployment require you to produce your own YAML file. In most cases, this isn’t terribly difficult, but if you make a small error in syntax, that will mean that the deployment process is dead in the water until that’s cleared up. But having this done automatically means having one fewer thing that can go wrong.

Don’t have an existing PHP app yet? Try creating a new one in the AppFog console

Just like PHP Fog, AppFog enables you to create jumpstart apps in our console. The currently available jumpstarts include custom PHP, Drupal, and WordPress apps. There will be more PHP jumpstarts on the way soon, but please note that PHP apps from any PHP framework can currently be deployed to AppFog, including CakePHP, Facebook, ThinkUp, Laravel, and many others. Simply choose a custom PHP jumpstart in the console and update your application code after the jumpstart app has been deployed.

I won’t go into a full walkthrough of the AppFog console here, but it’s very intuitive and there are a number of resources already available for introducing you to the full breadth of the console’s functionality. Check out this video for a nice introduction, and this section of our docs for a brief introduction to choosing jumpstarts in the AppFog console.

PHP app up and ready to go on AppFog? Here’s how to manage it

Once you have a PHP app running on AppFog, you’ll need to update it from the command line. Fortunately, you only need to run a single command from your app’s root directory to do so:

af update <app-name>

You’ll remember from before that I named my custom PHP app af-plus-php-equals-win, and so I simply run this command from my project’s directory (~/desktop/my-php-app) and AppFog will take care of the rest for me.

If you chose to create your PHP app in the console, the af update command essentially takes the “Hello World’ PHP app that resulted and replaces it with your own custom app. Remember that this is the way to do things if your PHP app was created in a framework outside of Drupal or WordPress (such as CakePHP or Facebook).

Lots more functionality where that came from

Naturally, there’s a lot more that you can do in both the console and the command line. This tutorial was simply meant to get your apps up and going on AppFog. For a more exhaustive introduction to the AppFog CLI tool, check out the documentation page for it or simply run af help in the command line for a list of all of the af gem-based commands that are available. I’ll also be giving a thorough rundown in a later tutorial.

In both the console and on the CLI, you’ll be able to bind and provision services (MySQL, just like with PHP Fog, except also a lot more, like MongoDB, PostgresQL, RabbitMQ, and Redis, all of which can now be used with PHP apps!), manage domain names, and a whole lot more.

That’s it for now. Like I said, more tutorials in the coming days for PHP Fog users switching to AppFog, in particular concerning data migration and more advanced features like provisioning and binding services, which is somewhat trickier than basic code migration. If you have any trouble, please reach out to support.appfog.com and they’ll get you all squared away.

In the meantime, happy migration!

It’s no secret that mobile development is hot and heating up.

It’s also no secret that we here at AppFog are huge PHP fans. In the past few months, we’ve given several spirited defenses of PHP, doing our part to fight against an ocean of FUD and misinformation.

We simply think that it’s no accident whatsoever that so much of the web is powered by PHP. It’s easy to use for beginning developers and it’s also immensely powerful for those that want to build far more ambitious things. To give just two examples, most people outside the PHP universe are shocked to find out that PHP now supports anonymous functions and that tools like the libevent-based Kargo exist for performing non-blocking I/O in PHP.

In this article, John Koetsier from VentureBeat has come along and given us yet another reason to love PHP and to fight back against its critics: PHP is about to make a big splash into the world of mobile development.

The problem? We don’t yet know exactly what that big splash is going to consist of. What we do know, however, is that Andi Gutmans, co-founder of Zend Technologies, is prepared to make a big announcement later this month at ZendCon in Santa Clara, CA about client-side app-enabling tools for mobile.

PHP has been a major server-side powerhouse for as long as most of today’s web devs can remember. It will certainly be something of a late-comer on the client-side scene in mobile development, where languages like Objective-C, Java, and of course JavaScript currently rule the roost.

But I, for one, am really looking forward to Zend’s announcements. We could see announcements about a small set of tools and libraries that provide a gentle push into client-side mobile development. That would be encouraging. Or we could see a big and bold push, a qualitative shift in client-side development akin to the emergence of jQuery in the JavaScript space in 2006. That would be mind-blowing.

PHP already has an incredibly bright future, but a big push into the client-side mobile space would undeniably make that future even brighter. It would spawn all kinds of development and innovation from within the PHP community and it would draw upon the already enormous mindshare of the hundreds of thousands–if not millions–of developers within that community.

ZendCon will be held from October 22-25. That means NOW. If you share a deep interest in the future trajectory of PHP, I strongly suggest tuning in.

Over the past month the team at AppFog has been working on migrating all of our users to a new, more robust and stable shared database service. This migration did not happen fast enough. As a consequence, one of our shared database servers became unstable Monday leaving many apps unavailable. We cannot apologize enough for this and are working to ensure it never happens again.

The Details

Beginning at 11:34am CST on Oct 8th we began to see unresponsiveness from the affected shared database server. We were getting a very large number of stacked connections and once this happened the database server became completely unresponsive and we were forced to restart it.

Upon restart, the database server came back up after 30 minutes and was stable again for approximately two hours. Unfortunately, connections stacked up as before and the DB again became unresponsive. Once again, we had to restart. This second restart went past the thirty minute mark, at which point we began the process of spinning up a new database server instance and restoring from a snapshot. Unfortunately, both of these processes took the better part of eight hours within Amazon’s environment. As of 10:19pm CST on Oct 8 this original server was back online.

There are no excuses for this outage. We know that you count upon us to be reliable, stable and performant and we let you down.

How We Intend To Fix It

Here is what we are doing to make it right: Starting immediately, we are greatly accelerating our migration of users off Amazon RDS, this week. In addition, all users who were affected by the outage will receive an account credit automatically.

Please accept our apologies for this outage. We will do better for you.

If you have any questions or concerns, please don’t hesitate to contact us.

The problem

Last week, from roughly 2pm PST on Monday until 5 am PST on Tuesday, many PHP Fog users experienced significant disruptions in Git operations, mostly involving permission denials and closed connections. The result: many users had trouble deploying new apps and managing current apps.

Critical files which manage authorization to our Git infrastructure became corrupt due to a bug in recently pushed optimization code.

Looking forward

In order to prevent this scenario from occurring again, we’re implementing some tooling that allows us to more easily verify the integrity of these files, as well as a number of other components of our infrastructure. Additionally, we are instituting a policy of having all optimizations reviewed by a number of peers before implementing them.

We selected Git to be an essential element of using PHP Fog because it’s a wonderful and powerful tool. When our Git service has setbacks of the kind we saw this week, we understand the impact it can have on your development and deployment.

We apologize and give thanks to those who contacted us about the problem and to all of you for your patience and understanding.

by Luc Perkins

I want to talk a little about a very promising project called “PHP: The Right Way.” But first, I’d like to give a brief rundown of why the project is of such interest to me.

First brushes with PHP

A few months back, I decided that I was going to learn PHP. Why? In all honesty, because a good friend of mine was designing a game in PHP–and had a fantastic idea for the game, which we’ll presumably finish one of these days–and I wanted to make a contribution. As simple as that. But I was reticent to tackle PHP because even as a beginning programmer I had already caught wind of the almost toxic levels of negativity surrounding the language.

The reality that I discovered wasn’t at all what I expected. Sure, there was plenty of spaghetti code out there (there’s also plenty of spaghetti code in C++, Java, take your pick…), but there were also a variety of frameworks and communities devoted to using PHP to all kinds of productive ends. I was also surprised at just how much of the internet runs on PHP. I guess that something like a third of the internet up and decided to quietly not mind the haters.

Hacker News explosion

About a month ago, I took it upon myself to summarize some of my impressions of the world of PHP in a piece titled “PHP: the quiet powerhouse.” In it, I made the simple and (I thought) not very audacious argument that PHP is extremely well suited for lots and lots of projects, as evinced by internet heavy hitters like Facebook and WordPress. I didn’t offer any glowing, effusive praise for the language or declare it to be the end-all be-all of web dev languages. I merely said that it’s still a great way to do lots of things and worthy of consideration in plenty of contexts.

But in spite of my relatively mild claims, I caught lots of flak here on the AppFog blog and in the post’s associated Hacker News thread. Fortunately, I also got a lot of very supportive comments from others who share my feelings about the language (thanks, folks!). And somewhere along the way, the post skyrocketed to #4 on the day on Hacker News. Given the article’s not-exactly-incendiary tone–it even had “quiet” in the title (!)–this surprised no one more than it surprised me.

The future of PHP

Surprisingly enough, I actually learned a great deal from this whole exchange, both about PHP itself and about the programming community in general. I got a much better sense of PHP’s very real (and sometimes very imagined) limitations. I picked up the juicy factoid that PHP began as a Perl library. I also gathered some valuable criticisms of PHP. The one that struck me as particularly salient involves not the language per se but rather the community and set of practices around it. It is this that the PHP: The Right Way project seeks to address.

And I learned just how much passion and vitriol comes pre-packaged with these debates. This turned out to be the real surprise. I was called ignorant and was asked if I was “even trying to make a valid point” (those being the safe-for-work comments). I’m thick skinned, so I was able to brush off the playground-style name-calling and to step back and marvel as the conversation unfolded into dozens upon dozens of comments, counter-comments, history lessons, call-outs, shout-outs, you name it.

Shedding some best-practices light on PHP

A while after making my first foray into the incendiary PHP debate, I came across the website for the PHP: The Right Way project, and the whole thrust of the project struck a deep chord with me. It’s an effort to (a) inform people about the real state of PHP, against a variety of channels of out-of-date information; and (b) to shine some potentially uncomfortable light on widespread but sub-optimal practices.

The introductory paragraph comes across almost like a manifesto:

There’s a lot of outdated information on the Web that leads PHP users astray, propagating bad practices and bad code. This must stop. PHP: The Right Way is an easy-to-read, quick reference for PHP best practices, accepted coding standards, and links to authoritative tutorials around the Web.

The project is currently housed on GitHub and is indeed accepting pull requests (as well as translations into other languages). Josh Lockhart, the creator of the Slim framework, spearheaded the project with the help of Phil Sturgeon, Kris Jordan, and a slew of other contributors.

I was legitimately surprised by all of the following:

• PHP supports anonymous functions (since version 5.3).
• PHP actually has a command line server, which enables you to run PHP programs in development without using Apache or another server.
• Composer has been turned into a not-shabby-at-all package manager.
• PDO is a library that enables you to connect to multiple database types–relational, NoSQL, etc.–through the same API while avoiding direct injection vulnerabilities.

The PHP world has come out and surprised me once again. Most surprising for me was the plethora of command line tools that are now available. I honestly had no idea just how much the experience of PHP development can be like developing in other languages. If you’re used to developing using the text editor-command line-browser trifecta (as I am), then you’ll be more at home than ever in the world of PHP.

But to be clear, the main purpose of PHP: The Right Way isn’t just to be informative about where PHP is now and what has changed. It’s also about preventing all-too-prevalent errors. The site boldly refers to direct SQL injection, for example, as “terrible code.” References to “good” and “correct” code abound. For the authors, “good enough” isn’t good enough. Misconceptions have to be corrected and bad habits have to be phased out. At stake is the safety and viability of the vast realms of the internet that run on PHP.

Overcoming inertia

The PHP: The Right Way project is the best attempt that I have yet seen to put the world of PHP on a better path. As many commenters on my original post noted, one of the “problems” with PHP–although it’s only a problem from a certain perspective–is that it poses so few barriers to entry for novice users.

There’s no way to put this delicately, but PHP is a language that makes beginners feel empowered (and rightfully so!) to write up their own PHP tutorials, blog posts, and documentation. This kind of democratic ethos is a wonderful thing–after all, it’s the same ethos that undergirds the open source community in its entirety–but this democratization has sometimes come at the expense of best practices, not to mention security (the aforementioned SQL injection problem being the most oft-cited).

At the end of the day, it strikes me as unfair not only to judge languages whole cloth, but also to judge the communities surrounding them whole cloth. There is no one PHP “community,” just as you’d be hard pressed to point to a single JavaScript or Python or whatever community. Within the world of PHP, there are indeed well-intentioned but sometimes under-informed people spreading information and tips that are in need of correction.

But there are also people under the PHP umbrella who are seasoned veterans in the language and operate at an incredibly high level of sophistication. Often, they are in a far better position to judge the merits and demerits of the language–and to exert a benevolent influence on the PHP ecosystem. That strikes me as the core of the PHP: The Right Way’s mission.

I think it’s clear how best to respond to the group’s provocation: if you’re looking to make bold claims about what PHP necessarily is and isn’t, don’t make those claims on the basis of tutorials or blog posts written by PHP beginners. Ask people who are seasoned veterans in the language and in its corresponding best practices. They’re the ones who fully understand PHP’s breadth and power.

And if you already find yourself under the umbrella of the PHP ecosystem, there is a different provocation being sent in your direction: join the conversation, be more aware of your own coding practices, and make a contribution.

PHP Fog customers chose PHP Fog, they did not choose the datacenter vendor. We chose the datacenter vendor, which means that it is our responsibility to ensure your apps don’t go down and restore them quickly when they do.

Over the weekend, around ⅓ of PHP Fog apps unfortunately had some service disruptions for some apps due to our over-reliance on a single datacenter at Amazon Web Services. We spent the weekend fielding our customers’ concerns, investigating what went wrong, replacing virtual machines, and making sure that our customers’ apps were up and running as soon as AWS came back up.

End users rarely know that AWS is down, and why should they? An end user experiences Netflix as being down when they can’t stream their favorite TV shows. They’re annoyed that they can’t share photos of their recent night out on Instagram. They’re worried that their pins on Pinterest will disappear. And they wonder why their projects on PHP Fog are inaccessible.

It’s a fact of life that data centers can go down for a variety of reasons (natural disasters like this weekend, or sometimes human error too). Four high profile fails in that one region in the last sixteen months, with two outages in the last week.

We are very happy that Amazon has chosen to share a great report on this outage. We all need far more transparency in the Cloud on this issue and moving forward, cloud providers including PHP Fog need more: proactive communication around issues, bi-directional discussions, more detailed information, and far more clarity and openness around architecture and data center design.

All cloud providers share responsibility for the problem in the end, but since PHP Fog is the service you signed up for, it is up to us to communicate directly with you. It’s pretty clear that we are overly dependent on a single infrastructure provider. That’s simply not acceptable.

We are continuing to move as quickly as possible to make our services and products as flexible as possible so our customers have the freedom to not only easily choose infrastructures, but to also easily change infrastructure providers to meet the needs of your businesses.

For those of you that experienced issues via PHP Fog this weekend, thank you for being patient and working with us over the weekend while the immediate issue got resolved. It wasn’t just a long weekend for us, it was a long weekend for many of our customers too. Thank you so much for your understanding and your support.