Ruby on Rails

Depends on what you mean by "PHP-driven" - if it's doing its own URL rewriting (Wordpress's clean URLs, for instance) you're probably best served putting the Rails stuff on a subdomain or in a subdirectory.

On the other hand, if it's a plain PHP site where URLs just end in .php everywhere, you can do some mod_rewrite magic (tune the paths as appropriate):

  RewriteCond /home/web/public_html/%{REQUEST_URI} -f

  RewriteRule ^(.*) /home/web/public_html/$1 [QSA,L]

  RewriteCond /home/web/public_html/%{REQUEST_URI}/index.php -f

  RewriteRule ^(.*) /home/web/public_html/$1/index.php [QSA,L]

Then point your DocumentRoot to the public dir in your Rails app, as Passenger's instructions indicate, and add this:

  <Directory /home/web/public_html>

    PassengerEngine off

   </Directory>

to the Apache config as well, to avoid confusing Passenger with stuff in PHP-land. The result will be that any incoming URL which matches either an actual PHP file, or a directory with an index.php file will be handled by PHP, while everything else goes to the Rails app.

One other thing - for additional integration, you may want to access the PHP session from the Rails app. (Going the other way is NOT recommended, as you'd need to be able to un-Marshal Ruby objects in PHP) To do this, you'll need a gem like php-serialize (https://github.com/jqr/php-serialize) and you'll need to find where your particular PHP installation stores session data - sometimes this is in /tmp, sometimes elsewhere. The files are typically named after the session token (found in "cookies['PHPSESSID']" in your controllers). PHP does some locking to avoid multiple writers messing the whole thing up, but I've only ever needed to *read* from the PHP session, so I'm not sure exactly how that works.

Hope this helps!

--Matt Jones