There's always a lag behind new releases of PHP and releases of packages for operating systems such as Ubuntu. This lag time means that you could be kept from upgrading to the latest and greatest PHP for a year or more, unless you use an outside repository like Dotdeb. [...] Instead, I roll my own version of PHP. It's simple and easy to do, and something that any developer can do. Here's my instructions for doing so on a fresh Ubuntu installation.

He gives a reason or two why you might want to "roll your own" installation and helps you get the environment prepared via some "aptitude" install commands for supporting software. Commands are included for installing needed dependencies, configuring/building PHP and updating Apache to use this new install. He finishes it up with a few smaller things to do like making the php.ini and enabling the Zend opcode caching extension.

Apache ZooKeeper is the coolest technology I recently came across. I found it when I was doing a research about Solr Cloud features. [...] Running multiple application as one logical program is nothing new. In fact creating such a software was one of my first jobs many years ago. This type of architecture is confusing and very tricky to work with. Apache ZooKeeper tries to provide a generic set of tools to manage such a software.

He shows you how to get the PHP extension for Zookepper (along with needed libraries) compiled and installed in your server setup. He includes a sample class that shows you how to connect to the Zookepper server and add a "watcher" your PHP script will respond to when changes happen. The post also has a "Watcher" class example, showing how to use Zookeeper as part of a distributed application. There's some links at the bottom of the post that can also help you get more details on Zookeeper and the PHP interface.

This year in tech (like almost every other year) has been filled with buzzwords. Many of them this year, however, are based around big data processing and web content: NoSQL, Hadoop, BigTable - the list goes on. With all the fuss around these new technologies, one might be tempted into thinking that these are the technologies of the future, and that from now on our servers and websites will be built upon, leaving technologies like LAMP in the dust.

They talk about some of the things the LAMP stack doesn't do well like difficulties with scalability on both the web server and database side. There's also mention of the things that it does do well, like getting things up and running quickly and with a solid structure.

That being the case, the LAMP stack is still going very strong, and it's definitely still extremely viable in small and medium-sized deployments; there are no signs of it waning in that regard, and I'd expect it to be a standard deployment for many companies and organizations for quite some time to come.

eveloping in PHP on Windows? Yep me too! Unfortunatly in opposite to developing on Linux, sending e-mail from PHP on Windows requires some more setup than just a bit of sendmail configuration. In this post I explain how to setup an Apache James Server and use it for e-mailing from PHP, all from and to your localhost.

He walks you through the download and installation and includes the changes you'll need to make to get it up and running correctly. He helps you test it's working correctly and how to get PHP set up and pointing to it for mail delivery. Finally, he has a line of PHP (using mail) to test the install and send a sample message.

Commonly known as .htaccess, AllowOverride is a neat little feature that allows you to tweak the server's behavior without modifying the configuration file or restarting the server. [...] Beyond the obvious security problems of allowing configuration modifications in a public document root there is also a performance impact. What happens with AllowOverride is that Apache will do an open() call on each parent directory from the requested file onward.

He includes the output from a strace call in the post - first showing the function calls with it set to "none" then the same request with the setting on "all". More "open" calls are being made in the second run, increasing the execution time by a decent amount.

Creating a staging environment is specific to your production environment. There is no magic solution that works in every situation. But most cases follow a similar pattern, and I'll cover all the key points as we go along. It's fair to assume that most people deploy their apps with some kind of versioning tool (like GIT). [...] Besides GIT, you have to think about the languages, software, and "special" features your production servers offer.

All of the commands and configuration files you'll need to make the automatic setup work are included in the article. It's based on a Debian (Squeeze) base image and uses packages to install the needed software. They also install other PHP extensions like mycrypt, GD, curl, APC and database support (MySQL, SQLite and Postgres). They help you get Apache set up to serve the application and work with git and its hooks to push the code and run Composer.

With the recent passage of PSR-3, a standard for a common interface for logging libraries, it seems appropriate to discuss the implementation with my favorite logging library. log4php is an open source Apache project that is a very versatile logging framework. Through log4php's configuration files, logging has a variety of output locations, so it's possible to send specific log levels to different output locations.

He includes the Composer requirements for the interface and shares the code for a wrapper class that implements the Logger interface and defines methods for each of the logging levels (alert, notice, debug, etc). Also in the post is an example XML configuration for log4php and how to load it into your class instance.

I was originally going to write a blog post about why NginX with FastCGI was faster than Apache with mod_php. I had heard a while ago that NginX running PHP via FastCGI was faster than Apache with mod_php and have heard people swear up and down that it was true. I did a quick test on it a while back and found some corresponding evidence. Today I wanted to examine it more in depth and see if I could get some good numbers on why this was the case. The problem was that I couldn't.

He uses a "hello world" script as a baseline to do some testing and the ab to run the numbers. His results show a pretty significant difference between the two setups and an "strace" on Apache showed a clear "winner" as to why it's slower (reading the .htaccess file). Once he turned this off, though, Apache jumped up and started performing better than Nginx.

This all makes sense. mod_php has PHP embedded in Apache and so it should be faster. If you're running only PHP on a web server then Apache still seems to be your best bet for performance. And if you are seeing a significant performance difference then you should check if AllowOverride is turned on. If it is, try moving that into httpd.conf and try again.

Dear PHP Community, we need to have a talk about the insufferable state of your software stacks. It was recently brought to my attention that there is software out there, software we use every day!, that is NOT written in PHP. This is completely unacceptable! We are PHPeople! We're not "Web" Developers, we are the web. And we sure as hell are not some fancy "Software Developer", you can ask anyone on the internet! Seriously: If it's not PHP how will we ever be able to extend and adapt it to our needs! We are slaves of our tools!

He mentions several tools that, yes, while not written in PHP are very useful to just about any developer out there (including git, Puppet and Apache). But, more seriously:

PHP is a language that enables absolute beginners to start creating on the web using FTP and notepad! It let's us realize and validate our ideas blazingly fast and allows us to adapt our successful ideas to beautifully scale with our requirements providing and relying on solid, battle-proof tools.

This howto guide explains you'll how to install Apache Server with latest MySQL 5.5.27 and PHP 5.4.7 versions with php required following modules on RHEL 6.3/6.2/6.1/6.0/5.8/5.6, CentOS 6.3/6.2/6.1/6.0/5.8/5.6 and Fedora 12,13,14,15,16,17 systems using Remi repository via Yum tool.

Thankfully, package management has made things a lot simpler than they used to be. Most of the time you're only a few commands away from a working installation (if all you need are the generic setups). They explain what each piece of the installation is and how to set up the custom "Remi" yum repository to get the latest versions of the software - Including PHP 5.4. They show how to stop and start each of the servers (MySQL, Apache) and a few screenshots of what the output of your phpinfo page should look like.