Tag: php

Last-ditch Solution to Non-Working PHP-FPM + Apache Configuration

I had a surreal experience yesterday. I was following online tutorials about setting up Apache + PHP-FPM (for example, this ServerFault question: http://serverfault.com/questions/326919/how-to-set-the-httpd-conf-when-using-php-fpm-with-php5-3-8-and-apache2). I’ll let you read that rather than re-hash it.

My goal here is only to share quickly how I actually got this working.

Alright, so you know the part where it says to add the directives:

AddHandler php5-fcgi .php
Action php5-fcgi /fcgi-bin/php5.external

This didn’t work for me no matter what I did. No errors were produced, so I knew that it simply wasn’t executing the Action directive for whatever reason. In checking the Apache 2.2 documentation for Action, I noticed that a MIME type could be given in lieu of an action-type (the php5-fcgi thing). Having exhausted all other options, and knowing that the PHP file was being sent to the browser unprocessed with the MIME type application/x-httpd-php, I decided to add:

Action application/x-httpd-php /fcgi-bin/php5.external

to my configuration. And, much to my shock, it actually worked!

So, if you find yourself as frustrated with setting up Apache + PHP-FPM as I was, I hope this tip may ease your suffering.

Quest for a Flexible Development Environment

Update 2! I blogged a follow-up to this on my developer blog: http://kkdev.tumblr.com/post/26751052566/pros-and-cons-of-home-office-development-servers

Update! Track my planning and thought process in the public Quest for a Flexible Development Environment Evernote notebook!

(If you don’t have a lot of time, skip to Phase 5.)

This blog post is actually a big question. It’s hard to express this question in 140 characters, so I blogged instead of tweeting. Here goes:

How can I set up a development environment that can transition between being Internet-accessible and usable offline in an hour or less?

Let me expand on this by telling a bit about my past development environments.

Phase 1 – Local, Windows

Some time ago, I was developing with WampServer (similar to XAMPP) on Windows. This was OK in the beginning, especially before specializing in Drupal. Over time, however, and maybe somewhat due to starting to use Windows Vista, I noticed that performance was much slower than a Linux environment of similar configuration. This led to…

Phase 2 – Local, Linux via VirtualBox (Host: Windows)

Realizing that Linux (and for the curious, “Linux” nearly always means Ubuntu 8.04 or 10.04 in this post) was faster, I decided to set up a virtual machine (VM) in VirtualBox to use for development. With bridged networking, this posed no real issues. There were no real drawbacks other than it consuming some host system resources, but that was obvious. I was used to using VMs because I used them regularly at work. This approach was a step up from running locally only on Windows, and I actually used it for quite some time. I used it when I was traveling in Norway in late 2010, and it was great! I could work while on buses, while on ferries, etc. without worrying about having Internet access. I had VirtualBox’s host networking set up so that I could have network communication between the host and guest and still test my sites on the VM from Windows, the workflow I was used to. In fact, I would probably still be using this approach today, if the system (a laptop) I was on hadn’t started inexplicably using high amounts of CPU constantly, bringing the VM to a halt. This is to say, the VM performance was subject to the limitations of the host…if the host had hardware or host OS issues, it would limit my ability to develop in the guest VM.

During one bout of these issues, I tried another setup as a workaround…

Phase 3 – Pseudo-remote (physical machine in same location), Linux via NX Client for Windows

The irony of my workaround is that it became my standard. I think I started using this approach around mid- or late-2010 (probably around August). It allowed me to work as long as I had an Internet connection, and, since it was running on a physical machine, performance was arguably a bit better than a VM. I say arguable since it’s an old machine with 1 GB of RAM and a 2.4 GHz Pentium 4 processor. But hey…that’s Linux’s strong suit, right? I’d put in eAccelerator, and things would be fine for a development environment. The machine was on my network, so no issues there, and I could put it on a Hamachi VPN network to have the feel of it being local even when I’m remote. In fact, at the time of writing, the machine actually runs this site! I use DNS Made Easy‘s Dynamic DNS to keep the IP address up to date. I say “at the time of writing” since I plan to move it to a separate box eventually, especially since I expect its popularity to gradually rise as I network more…so it’s obviously a better idea. Going back to my setup, another nice thing about it (and those of you who saw Oliver Seldman and I’s Why Hooks? presentation at LA Drupal expereinced this) was that I could fall back to PuTTY and Vim if NX Client for Windows couldn’t connect. Perhaps somewhat ironically, that very fact of being a Vim user sort of saved me when I had to temporarily implement…

Phase 4 – Fully remote (VPS server), Linux via PuTTY

What drove me to this? After many years of service, my development machine’s hard drive started to go. I realized this when trying to check out a critical repository via Bazaar (of which I fortunately had a CrashPlan backup that I later recovered). Drive tests confirmed it. I was at a loss; I definitely needed to keep working. Thinking about my options and knowing I could develop in a shell, I chose and rented a low-cost VPS and moved over the projects I was working on at the moment, switched DNS to point there, etc. Worked reasonably well, and I used that setup for a week or two. Not as ideal because of the lower amount of resources, but definitely worked in a pinch. It also got me thinking about how I could ensure I could develop near-continuously (within working hours, obviously :)) without these sorts of infrastructure issues (which themselves take time to resolve)! Let me tell you about my current phase, and then I’ll summarize what I’ve said and eagerly await your responses, whether they are as blog comments or directed at @wizonesolutions on Twiter.

Phase 5 – Phase 3 + Phase 4 + repository server

Phase 5 finds me back at Phase 3 for my main setup. I got a new hard drive for the server and installed Lubuntu on it fresh (which was a good move – it’s lighter and faster when remoting in). I had my /etc configuration backed up, so I’ve been restoring my Apache sites incrementally. Much of my other configuration was already saved on my repository server. What’s a repository server? It’s a place for Bazaar and Git repositories (as well as Subversion, Mercurial, and CVS ones – it’s just that I don’t have any of those). This allows me to have some redundancy in repository location; when that server goes down, the important ones will already be checked out elsewhere, and the not-so-important ones will have been backed up in an older snapshot of the repository server and be able to be restored unless that snapshot is lost (which I plan to guard against by backing up the server to CrashPlan, Amazon S3, or the VPS host’s backup service – undecided as yet). I realized I needed more redundancy after the Phase 3 -> Phase 4 issue. I’ve had decent backups in place, at least, for quite some time…that definitely helped, and I recommend everyone reading this makes sure they do too. You’ll hug yourself when you need to restore from them. I once lost original wedding photos to a replaced hard drive when I sent in a laptop for repair. I’ve also lost some photos backed up on an iPod. You can bet I wasn’t going to have a repeat of that. I even back up my external hard drives now (they contain some older files not on my main ones)…the key being to have nothing in only one place – but if I do, to prefer the cloud over a physical location.

The Future – Phase 6 – Hybrid setup? Synchronization? Puppet? Chef? Database replication?

This phase has a lot of questions, but the goal is to be able to switch between online (requires Internet or local network connection) and offline (virtual machine, no Internet required). Additionally, the offline setup needs to be configurable on a laptop, since I’d be using that setup primarily when traveling on modes of transport with slow or non-existent Internet. My preferred work environment would still be the one requiring Internet, since that would make it accessible from anywhere I could use SSH, provide a separation of concerns (not having one machine do everything), etc. While offline, I would accept that I would not have repository access – that’s alright, since with Git and Bazaar, I can commit offline, and then push my changes later. This works even with bound branches in Bazaar, with the caveat that I have to unbind them first and rebind them later, potentially encountering conflicts. I could live with this (or simply have mirror branches that remain bound and working branches where I actually make the commits. I would then push the commits to the mirror branches when online; I’ve used this setup before with great success). The main offline requirement would be to be able to develop and test sites on the LAMP stack. Access to manuals and documentation for these while offline would be a bonus but isn’t required.

Synopsis of approaches I’ve tried

Phase 1 – Local, Windows:
Supports offline work: Yes
Acceptable performance: So-so
Sustainable: No
Similar to deployment environment: Probably not
Data safety: Same as rest of system

Phase 2 – Local, Linux on Virtualbox on Windows:
Supports offline work: Yes; host networking required for network communication; can be set up while offline
Acceptable performance: Yes, but dependent on host system
Sustainable: Yes, but VM data should be backed up
Similar to deployment environment: Yes
Data safety: If VM hard drive file is lost, it’s all gone if not backed up externally. Only easily accessible while VM is running, although I have read about ways to mount the drive while it’s off. Also, VM data file will take a couple days to back up online, depending on residental Internet’s upload speed

Phase 3 – Pseudo-remote (physical machine in same location), Linux via NX Client for Windows
Supports offline work: No
Acceptable performance: Yes
Sustainable: Yes
Similar to deployment environment: Yes
Data safety: Essentially yes; only normal concerns taken for any system apply

Phase 4 – Fully remote (VPS server), Linux via PuTTY
Supports offline work: No
Acceptable performance: Yes
Sustainable: Yes
Similar to deployment environment: Yes
Data safety: Yes, but less so than a physical system due to lack of access to the hardware (e.g., the host may not be willing to recover the data from a failed node drive, etc.) – so remote backup is critically important, although if it’s primarily a dev machine, code repositories may mitigate this risk if they are suitably backed up themselves

Phase 5 – Phase 3 + Phase 4 + repository server
Supports offline work: No
Acceptable performance: Yes
Sustainable: Yes
Similar to deployment environment: Yes
Data safety: Depends on which environment is active. See Phase 3/Phase 4
Another point of consideration is that if either machine crashes and becomes inaccessible prior to migrating the work environment for active projects, only code pushed to the code repository can be retrieved immediately.

My wish list for Phase 6
Supports offline work: Yes
Acceptable performance: Yes
Sustainable: Yes
Similar to deployment environment: Yes
Data safety: Same as Phase 3, at least
Time to switch between online/offline: <= 1 hr
Bonus features: Automated synchronization, automated switching,  access to manuals/documentation for PHP/Apache/Drupal

With your help, I hope to get to phase 6. I’ll try to keep this post updated as my strategy develops. Thank you in advance!

P.S. This post is kind of hard to grok. Please leave suggestions for how I can make it easier to read. I want people to actually read it and comment. If they can’t, they won’t bother. Thanks!

Drupal in 2020

This post is the expansion of a tongue-in-cheek IRC conversation I had the other day. I thought it’d be fun to blog about it because, while it’s mostly just humorous, it actually does cover some of the issues Web Developers encounter while developing in Drupal (or in many other platforms). So, walk with me if you will, into the year 2020 and how your Drupal project might unfold then…

*space-agey whooshing sound*

Vim Tips – Increase/decrease number under cursor

Dear coders,

You know how often I write new blog entries…like once every 3 nevers (and when I’m plugging the release of something I’ve developed, which happens about once every 3 nevers).

And yet, something I found today inspired me to tell the world about it. It may be something you have wanted to do on occasion. Yes, it is, as the title implies, the mere act of increasing or decreasing the number under the cursor in Vim.

How can this monumental task be accomplished? Why, it’s quite easy: <C-a> (increase) and <C-x> (decrease). The C means you hold down ctrl while you type the letter.

Perhaps a use case like mine will help you comprehend the sheer awesomeness of this in things like macros.

Basically, I started with a bunch of SQL ALTER statements. But for demonstration purposes, let’s…I don’t know, add increasing numbers to an array. Fifty times. The language here is PHP, by the way, but it doesn’t matter.

The old way:
// Add numbers to an array
$i = array();
$i[] = 1;
$i[] = 2;
$i[] = 3;

OK, now suspending your disbelief for a second and ignoring all the thoughts of, “Why doesn’t he just use a for loop?” think about how you would normally tackle something like this. Would it be…
yy – copy line
p – paste
/$i – find the next occurrence of $i
(once found) l (move right) (till you reach the number)
cw (change word)
(type new number)
c[ or ESC (escape insert mode)

Whoa! Imagine doing that 50 times.

However, now we know about <C-a> and <C-x>. So let’s make a macro! In this example, to save space, I’m going to separate the commands with “–” – so don’t type that.

Go to the first line of the whole thing, $i[] = 1. We know that we need to do this 49 more times. So we type:

qa — yy — p — f; — h —<C-a> — q

You can look up macros and these commands on your own. But basically, this starts a new macro in register a, where you record the keystrokes to copy the line, paste it on to a new one, jump the cursor to the semicolon, move it left by 1, and then increase the number. Once you’ve got this macro going, if you start with the $i[] = 1 line, you only need type 49@a (replace a with the register you used) and voilà – you’ll have the rest of your code written for you!

Now go and increase some numbers today! Preferably on better code than in the example here.

I’m an official Drupal contributor now – how did you become one?

Today I got my CVS account for Drupal.org. It’s really funny how it happened. I was planning to apply for one anyway in the near future because I’m working on releasing a complementary Drupal module for the Meetup API I developed. However, I actually just wound up patching the Fill PDF module with some extra functionality (as part of client work) and was asked if I could just commit the change myself. I couldn’t refuse something as cool as that, so I applied for a CVS account, and it was approved.

I’ll be committing that change soon, so if you are looking to fill in PDF forms with data from nodes and such, check out Fill PDF.

Now accidentally co-maintained by WizOne Solutions!

Furthermore, I intend to commit it with Git.

Do you have any fun stories of how you got your CVS account? Do share.

Just released – PHP Meetup API Client Alpha Version

It’s a bit late for me to write much on this, so I’ll write another post later on, but in short: http://github.com/wizonesolutions/meetup_api

Pull it down and contribute back if you want to see this grow 🙂 The README.txt that comes with it explains a bit about how it works.

But it doesn’t stop here. Next on the list is its companion Drupal module, of course! And maybe some other stuff as well, but that’s what I have planned so far.