Ruby on Rails Integration With Wordpress
This seems to be working for me (I'm loading from Wordpress as secondary database, hence the establish_connection()
calls and overriding table_name
. This should get most of the way there, giving you access to the Wordpress data as ActiveRecord objects. I haven't yet written the wrapper around Posts (WPPost
) to make them a bit more user friendly from an API perspective, but this should work well for Rails-based display of Wordpress data.
class Term < ActiveRecord::Base establish_connection "wordpress-#{Rails.env}" self.table_name = "wp_terms" has_one :term_taxonomyendclass TermTaxonomy < ActiveRecord::Base establish_connection "wordpress-#{Rails.env}" self.table_name = "wp_term_taxonomy" belongs_to :term has_many :term_relationshipendclass TermRelationship < ActiveRecord::Base establish_connection "wordpress-#{Rails.env}" self.table_name = "wp_term_relationships" belongs_to :post, :foreign_key => "object_id" belongs_to :term_taxonomy has_one :term, :through => :term_taxonomyendclass Post < ActiveRecord::Base establish_connection "wordpress-#{Rails.env}" self.table_name = "wp_posts" has_many :term, :through => :term_relationship has_many :term_relationship, :foreign_key => "object_id" has_one :postmeta # we only care about published posts for notifications default_scope where("post_type = 'post' and post_status = 'publish'")endclass Postmeta < ActiveRecord::Base establish_connection "wordpress-#{Rails.env}" self.table_name = "wp_postmeta" belongs_to :postend
I then wrap up the category in a simple ruby object that makes accessing the data easy:
class WPCategory attr_accessor :id attr_accessor :name attr_accessor :description attr_accessor :term def self.categories() categories = Term.all() categories = categories.select{|term| term.term_taxonomy.taxonomy == "category"} return categories.map{|term| WPCategory.new(term)} end def self.category(id=nil) if id term = Term.find(id) if term.term_taxonomy.taxonomy == "category" return WPCategory.new(term) end end return nil end def initialize(term) @id = term.term_id @name = term.name @description = term.term_taxonomy.description @term = term end def to_s return "Wordpress Category: '#{@name}' (id=#{@id})" endend
Here's my database.yml (make sure that your db user has read-only access to the wordpress db to avoid any ActiveRecord mishaps):
test: adapter: mysql2 encoding: utf8 database: test-rails pool: 5 username: test password: XXXXXX socket: /var/lib/mysql/mysql.sockwordpress-test: adapter: mysql2 encoding: utf8 database: test-wordpress pool: 5 username: test password: XXXXXXX socket: /var/lib/mysql/mysql.sockwordpress-development: adapter: mysql2 encoding: utf8 database: wordpress pool: 5 username: dev password: XXXXXX socket: /var/lib/mysql/mysql.sockdevelopment: adapter: mysql2 encoding: utf8 database: dev pool: 5 username: dev password: XXXXXX socket: /var/lib/mysql/mysql.sock
The Museum of Modern Art had a WordPress JSON API plugin built for this exact purpose: https://github.com/dphiffer/wp-json-api
This allowed them to build a RoR-based front-end layer while maintaining a WordPress-driven back-end layer.
The older answers are not relevant anymore. WordPress now provides a Rest API which can be accessed here:https://developer.wordpress.org/rest-api/
1) You will probably want to integrate all routing (by taking the "slug" from the articles) in your rails app to serve the articles correctly and present them with a nice "show" view.
2) If you want to store data in the rails system (e.g. for routing and to increase speed) you could create a database table called wp_articles, simply read the full article list or update relevant articles, then present them similar to your normal code.
I've looked at the non-maintained MOMA gem (not required anymore, not maintained), checked the above answer with direct database access (huge effort, slower, outdated) and read about a slighlty complex direct javascript based solution here (http://marydickson.com/how-to-use-the-wordpress-rest-api-in-rails/), but I think that simply copying the relevant info into your system and then presenting them with the normal MVC process is the easiest way.
Disadvantages: Some additional WP-Plugins provide more database fields and other information and its not clear whether you can always access those via the API. So you might have slightly limited functionality.