Using a reverse proxy to integrate WordPress into Rails

Filed under technical • Tagged: Technical, Ruby, Rails, Wordpress

Sometimes you need to get two separate applications to play nicely together under the same domain.

If one of these applications is especially greedy with regards to the routes/URLs it wants to control, then it can become a tricky project. Using subdomains can often help, as the subdomain can explicitly address the other application. However, if you need content from both applications under the same domain, and you don’t have access to or the desire to fumble with the routing (e.g. you use Heroku) then a different approach might be required.

A reverse proxy sounds complicated but it’s a very simple idea: a browser requests something from your server (Server 1). When the request arrives, instead of serving the resource directly, the Server 1 makes a second request to Server 2. Once Server 1 recieves the data from Server 2, it then returns it to the browser. From the perspective of the browser, this second request is invisible: it looks as though the content was living on Server 1 all along.

This approach works well for websites which run on Ruby on Rails, but want to use a third-party hosted Wordpress instance to serve and manage their blog. A subdomain is probably off the cards because of the SEO benefits of having the blog under the apex domain. We want the blog to live

Most recently, I tried using rails-reverse-proxy to solve this problem. It looked simple enough, but I got bogged down with endless OpenSSL::SSL::SSLError - SSL_connect returned=1 errno=0 state=error: sslv3 alert handshake failure errors in development and production. However, when I made the requests manually via cURL or the openssl command line, there was no issue. I started modifying the gem code to debug headers, cipher suites and parameters and then stopped… it shouldn’t be this hard!

So I added to some routes to catch WordPress page requests. Fortunately, these can all be nested under one folder (e.g. /blog), making routing much simpler.

Here are the new routes in routes.rb:

  # Intercept requests to WordPress pages
  match 'blog' => 'wordpress#index', via: [:get, :post, :put, :patch, :delete]
  match 'blog/*path' => 'wordpress#index', via: [:get, :post, :put, :patch, :delete]

And here is the controller to handle the requests:

# This action will catch any requests to blog/* and reverse proxy them.
# Essentially, it fetches the WordPress page HTML from the Wordpress instance, 
# and serves the resulting HTML as if it was coming from this server.
class WordpressController < ApplicationController
  WP_URL = ''.freeze
  COMPANY_URL = ''.freeze

  def index
    if params['path'].present?
      request_url = "https://#{WP_URL}/blog/#{params['path']}/" # Trailing slash required by WP
      request_url = "https://#{WP_URL}/blog/"

    # Make the request to the Wordpress blog
    blog_html = Net::HTTP.get(URI(request_url))
    render html: rewrite_links(blog_html)

  # Update all page links to our official blog URL so that users don't
  # end up back on the original Wordpress URL
  def rewrite_links(html)
    parsed_html = html.gsub("#{WP_URL}/blog", "#{COMPANY_URL}/blog")



—Dan Bartlett
3 Mar 2021

Pssst! want some dedicated support in your goals?

When I'm not writing, I work 1-on-1 with people as a coach. If you want the space and accountability to make real, lasting change in life, work or waking up, book in a free discovery call and I'll explain how I can help 💪

hello substack

All my new writings are published on Substack. I cover anything from awakening to burnout; meditation to the meaning crisis. Please drop your email below to subscribe: