While Heroku got its start from hosting Ruby on Rails applications, it nowadays supports many different environments in the Cedar stack. Node.js is what many use, but they also do support PHP. Dependency management is easy for Node.js applications as Heroku recognizes your package.json files and automatically installs the libraries needed via NPM.

Until now PHP developers haven't had this convenience, but as Composer is emerging as the default PHP package manager, I've now added support for it. Before the pull request gets accepted, Composer dependency handling can already be used by specifying my custom PHP buildpack when creating Heroku apps.

He shows you how to get it up and running with a sample application - creating the new git archive, creating the Heroku app with the custom backapack (and a "composer.json" file), setting up the main "index.php" file and push it all to Heroku. You can view his sample application here (a simple URL encoding form).

Managing dependencies between pieces of software, in PHP, hasn't always been a relief: we had PEAR and PECL with their workflows and problems while, in other ecosystems, the solution to this problem has been solved in better ways, like NodeJS's NPM.

He takes a first look at the tool, describing how to get it set up, create a sample configuration (describing each section inside it) and an example of the tool's output. He also briefly touches on the Packagist website/repository and links to the instructions on how to create your own.

Phix makes it extremely easy to create and maintain your own PEAR-installer compatible components for reuse in your PHP applications. Installation takes just seconds, and it's both open-source and framework-agnostic!

The OS guides help you get it installed for:

• OSX
• Fedora
• Ubuntu
• Debian
• CentOS

For more information about Phix (including helpful "getting started" details) check out the project's website.

While PHP's configuration capabilities are indeed powerful, the sheer breadth and different ways in which these configuration directives can be set are often confusing and downright intimidating to newcomers. So in this article it worth meandering from the typically intermediate-level discussion and instead offer some insight into PHP's configuration-specific infrastructure.

He starts by mentioning the phpinfo function that generates the complete list of current settings for your installation. With that in hand and an idea of what settings are out there, he starts going through some of the basics of working with ini settings - updating the php.ini, setting values via a .htaccess file and chancing them directly in the executing script.

The techniques Eli covers will always be applicable in one form or another. They should be a fundamental part of any website architect's bag of tricks.

The first article focuses more on methods for preventing and dealing with the inevitable spamming that comes with running a larger site. Eli's experience at Digg has provided him with recommendations like creating hurdles for spammers to get past and evaluating the content (services like Defensio or Akismet are useful for this).

The second article talks about something a bit harder to deal with - when users "game the system" and find the loopholes. His recommendations to combat this sort of abuse include rate limiting, pattern matching and leaving "traps" by tracking user usage.

The cronTab, or "Cron Table", is a Linux system process / daemon which facilitates the scheduling of repetitive tasks thereby easing up our day to day routine. In this tutorial, we'll create a dynamic PHP class that, using a secure connection, provides us with a means to manipulate the cronTab!

They explain the cron format (time and script to run) and how to set up a crontab management class that uses the ssh extension for PHP to communicate with the remote server. Their class includes methods for setting up jobs, writing them out to the cron file, removing existing jobs and dropping the entire cron file at once.

One of the more frequent questions I see on the mailing lists and IRC is, "How do I take over a package?". Very often people start to use a PEAR package and then at some point encounter either a bug or they miss a certain feature. The package's state however is inactive or flat unmaintained.

He recommends a few different courses of action - first asking if there's a way to help out, then stepping it up and pushing the fixes in yourself and, finally, deciding if you really do want to maintain the package (and show it by contributing).

PHP errors are just part of the language. Some internal functions throw warnings or notices and seem unavoidable. A good case is parse_url. The point of parse_url is to take apart a URL and tell me the parts. Until recently, the only way to validate a URL was a regex. You can now use filter_var with the FILTER_VALIDATE_URL filter. But, in the past, I would use parse_url to validate the URL. It worked as the function returns false if the value is not a URL. But, if you give parse_url something that is not a URL, it throws a PHP Warning error message. The result is I would use the evil @ to suppress errors from parse_url. Long story short, you get errors on PHP systems. And you don't need to ignore them.

He talks about the two-step process he's upgraded to to help monitor and handle the errors that pop up - an error handler that logs human-readable and json versions of the errors and something like Circonus to do metric tracking. He also mentions some external services recommended on twitter - HopToad and Loggly.

Gone is the need to devise strategies for important tasks such as maintaining page headers and footers, separating the bulk of a page's logic from its interface, and managing the code repeatedly used throughout the site to carry out special formatting actions. Instead, you can just embrace the framework's conventions and move on to the next battle. This article introduces you to some of the fundamental concepts behind managing layouts within your Zend Framework-driven applications.

He shows how to enable the layout management tools and how to create a sample layout to ensure it's working. You can also switch layouts, disable them and use a few of the helpers that come with the tool to make it simpler for you and make your development time faster.

At the moment, Wikipedia's list of content management systems features 137 unique CMS products. 59 of these are written in PHP. And that's only the ones that Wikipedia finds 'notable', which means these are the ones that have significant usage or large enough communities to be mentioned. [...] The sheer size of the CMS market is interesting when you consider that one of the most frequent questions we get at Ibuildings is: "What CMS do you recommend we use?"

In an experiment in his recent talk (at the IMS conference) he asked the audience which car he should purchase from his list of four. Of course, their answers were wrong because of one fact - no one asked about his requirements.

This is a definite first step to anyone looking for a CMS to fit their needs (or really any kind of software). He also mentions other criteria to consider like cost of ownership, technology required, features and functional requirements.