www.daork.net

I’m working on ways to migrate from our PHP based site using Mambo, SMF, Gallery, and some calendar thing, to using Rails code written entirely in-house.

The approach we’re taking is to write rails code to replace parts of the PHP code. IE. write a new calendar app, then a new gallery app, then a new CMS, then a new forum.
We want to put these stages live as we write them.
We also want to have to touch the current PHP code as much as possible. It brings us nightmares.

Now, I realise this is not terribly optimal, but, it allows us to be pragmatic and re-think stuff as we go a bit, based on user acceptance. Big cutovers are bad for sites such as ours, as bugs tend to show up in their hundreds, and users move on as they lose familiarity (user loyalty is important for us to survive). The decision to do this has come after about 18 months of long hard thinking.

Anyway, there’s a couple of interesting problems that come up;
- Order of events
- Sessions between Rails and PHP
- Calling PHP from Rails and vice-versa

So, I’m going to have a ramble about how we hope to deal with them.

Order of events

At first, we’ll have a PHP site, with Rails bits sprinkled in it. IE. The PHP will call the Rails app somehow.
Then, we’ll move to having a Rails app, which calls the odd PHP bit (the most important and difficult of these will be the forum software, SMF).
Then, we’ll ditch the PHP all-together and live happily ever after.

Calling PHP from Rails, and vice-versa

The options here that I can think of are;
- Use FastCGI
- Use HTTP requests to the Apache server
- Use HTTP requests to a mongrel backend server (for PHP calling Rails)
- Use standard CGI

Obviously standard CGI is out for performance reasons, and it’s a pretty busy site.
FastCGI is (to me) the most technically superior, but it requires implementing FastCGI clients in both PHP and Ruby. Sure, FastCGI /servers/ exist for both of these, but not clients. I’m not much of a C coder, and I suspect doing this in some other language would be slow.
So, I think we’re going to have to settle with combining two options:
- When Rails needs to call PHP, talk to the Apache server.
- When PHP needs to call Rails, talk to a mongrel server.

In both cases, there’ll have to be a bit of jiggery-pokery to make sure original client IP addresses are sent (by adding X-Forwarded-For headers, most likely), and session and request headers are passed in full.

Session sharing

Looks like the best way to do this, is to implement a session store for Rails that can simply access the PHP sessions from disk and the DB. Such code might already exist, I’m not sure. I’ll have a dig around for some.