Rails / Mixing PHP and Rails
From WhyNotWiki
http://weblog.terrellrussell.com/2008/01/running-php-within-rails/.
P.S. And now for all the phrases that I couldn’t find anywhere when I was looking for how to make all this magic happen - maybe someone else will find this stuff here: PHP within Rails, PHP inside Rails, [...] PHP/Rails integration, PHP integration with Rails
http://www.google.com/search?q=mixing+php+files+rails+%28development+OR+webrick%29
http://rc3.org/2008/01/04/whats-the-ceiling-for-rails/.
The third factor that will limit the growth of Rails is that it’s difficult to get multiple Rails applications to play well together, or to get Rails to play well where multiple applications live on the same host. Many Web sites are an amalgamation of applications, perhaps running on different platforms. You may have some static content, a calendar application written in PHP, a blog powered by Movable Type or WordPress, and a PHP contact form. It’s easy to add another PHP application to the mix in its own directory, or even add a Java WAR file to the mix. Unfortunately, Rails really wants to control the virtual host it’s running on. Taking an existing Web site and putting a Rails app in /blog isn’t the easiest thing to do. It’s really a shame, because Ruby on Rails is the perfect framework for whipping up a job board, or a schedule of upcoming training events, or a customer support knowledge base.
If someone came to me today and said they’re trying to pick the technology platform for a new Web startup, I’d tell them to choose a modern framework built on a dynamic language. Django and Rails fit the bill, among others. But those types of projects are a small slice of the Web development work that’s being done these days. And it’s going to be tough for Rails to continue making inroads into the larger ecosystem, for reasons both technical and practical. The next big boost in Ruby on Rails growth will come when point #3 above is addressed and Rails deployment moves to the next level of simplicity.
Regarding #3, Camping? http://code.whytheluckystiff.net/camping/wiki/SmallAppsManyMounts
Less feature-rich, but composable.
For #3, I too am surprised that some fix for this has been slow to come along. I’ve had luck setting up Rails apps in Mongrel behind Apache’s mod_proxy_balancer (though admittedly I have no Rails apps that have scaling challenges).
It seems it should be possible to create an Apache module (says the guy who’s never written one) that allows you–from httpd.conf or .htaccess to give shared users some control–to point a URL path at a physical path containing a Rails app and have it manage your Mongrels for you.
Now if only I could justify spending my time on such a thing.
http://blog.jcoglan.com/2007/08/28/mixing-other-languages-into-your-rails-app-for-local-development/.
LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_http_module modules/mod_proxy_http.so ProxyRequests Off <Proxy *> Order allow,deny Allow from all </Proxy> <Directory "C:/webserver/Rails/yourproject/public"> Options Indexes FollowSymLinks AllowOverride none Order allow,deny Allow from all </Directory> ProxyPass /php ! ProxyPass / http://127.0.0.1:3000/ ProxyPassReverse / http://127.0.0.1:3000/The Directory sets some rules for your app’s public directory - edit these to your liking. The final three lines tell Apache not to proxy requests to the php directory, but to proxy all other requests to the address of your Rails development server. So, hitting http://yourproject.local (after restarting your Apache and Mongrel/WEBrick servers) will bring up your Rails app. All should function as normal, except that any request to http://yourproject.local/php/* will go to the directory containing your PHP scripts - C:/webserver/Apache2.2/htdocs/yourproject/php.
Note that this will affect all local domains your have set up, not just yourproject.local. [...]
http://macdiggs.com/index.php/2007/06/29/using-php-inside-rails-structure-on-apache/.
Now, say, you decide to put a PHP-based mailform inside your Rails project, accessible by myserver.com/mailform/mailform.php path.
...
RewriteCond %{REQUEST_URI} ^/mailform.*$ RewriteRule ^(.*)$ $1 [L]By doing this, you basically instruct Apache to not pass requests to urls starting with
/mailform, to Rails. So requests will be processed by default server rules, not by Rails.
http://weblog.terrellrussell.com/2008/01/running-php-within-rails/.
1) Edit the Apache configuration file for your virtualhost. This tells Apache not to push any requests that start with /forum or /wiki to the Rails app (here, a mongrel cluster) - and to just handle them by itself (via the PHP processor).
RewriteEngine On # send all /forum traffic to php RewriteCond %{REQUEST_URI} ^/forum.* RewriteRule .* - [L] # send all /wiki traffic to php RewriteCond %{REQUEST_URI} ^/wiki.* RewriteRule .* - [L] # Redirect all non-static requests to cluster ...2) Add/Edit the .htaccess file in both the forum and the wiki directories. This tells any requests that were sent the way of either the forum or the wiki to halt the rewriting engine and just process the requests themselves.
RewriteEngine Off
Using PHP with Ruby on Rails under Lighttp (http://darwinweb.net/articles/35-using_php_with_ruby_on_rails_under_lighttpd).
...
You need to compile a CGI/FastCGI copy of PHP for use with Lighttpd. The built-in PHP is an Apache module and will not work with Lighttpd (as far as I know).
...
Do you know if it’s possible to use .php files OUTSIDE of the public directory? I need to use a php upload handler script, and ideally, I’d route to it via dispatch.fcgi. Unfortunately, rails keeps looking for a .rhtml file. Is there a rails config that will allow it to ‘see’ php files in app/views/controller_name/ ? Any thoughts? Thanks
Rails would have to be capable of invoking PHP as a CGI with the environment intact. I wouldn’t even know where to begin to tackle this, but ultimately I don’t think it makes sense. A view is invoked by a controller, so you would have a Ruby controller calling a PHP view. Where would the instance variables go? What would the PHP environment look like? It would just cause confusion.
The best solution to your problem is to put your PHP files in public and just use redirects as necessary to move between Rails and PHP. [...]
[edit] Composability
(move out to "Web frameworks / Composability"?)
Small Apps, Many Mounts (http://code.whytheluckystiff.net/camping/wiki/SmallAppsManyMounts).
Rather than building huge Camping apps, the idea here is to write small apps which can each be mounted at directories on your web server. One restriction: these apps will share a database. However, this allows applications to access each other's tables and simplifies setup and configuration.
The
campingtool starts a web server which mounts apps in this fashion. If you want to mount all the examples, runcamping examples/**/*.rb.You'll end up with:
1. http://localhost:3301/blog, the blogging sample app.
2. http://localhost:3301/tepee, the wiki sample app.
3. http://localhost:3301/charts, the charting sample app.
Cool!
