My goal is to embed a full Ruby on Rails app in a Wordpress site. Ideally, the staff should be able to edit the non-Rails parts of the site just like any Wordpress site, including content, theme, menus, etc. When the user clicks a link to a certain page, it should show the Rails content within the Wordpress template—headers, menus, sidebars, etc.—all of which should look the same as the rest of the site. I'd much prefer to do the presentation of the Rails content within Rails, where I can use Slim, CoffeeScript, SASS, and all of the other built in presentational magic, rather than setting Rails up as just a JSON server and having to muck around with PHP to retrieve and format the data.
I've tried a few techniques so far, but each has its downsides:
First, I tried embedding the Rails app in an iframe, but iframes are clunky, and I couldn't get it to expand or contract to the height of the content.
Second, I tried creating a special Wordpress template file that loads the Rails content using PHP's file_get_contents function. That worked okay, but required a lot of jankiness to get URLs to transfer over, including having to add a question mark into the URL for a certain subpage to get Wordpress to ignore it and pass it through. It's also a little slow because it's loading content from two different dynamic systems. And I never could figure out how to get cookies to pass through to Rails, which is essential for this app.
My third solution was to create a blank page on Wordpress (not linked to anywhere) and write a method in Rails that pulls that page, creates a layout file, and then uses that as the layout for the content. So the whole page is actually being served by Rails, but to the user it looks just like Wordpress, and because Wordpress doesn't use relative URLs in links, they all work just fine. The trouble there is that changes to the Wordpress template (including menus, template files, theme options) don't take effect on the Rails pages until that method is run. I set up a cron job to run it every 15 minutes, but that's not ideal, and something tells me there must be a better way.
This seems like something that would be pretty common, but I haven't been able to find any solutions online. Has anyone else made this work?
Related
My goal is to create a Rails based site that uses AJAX to fetch different sections. The site should never completely refresh. I'm using Rails 3.2.8.
There's a lot of conflicting articles online about how to actually implement this. It seems to me that simply fetching pages.json and using javascript would accomplish my goal, but is that the "rails" way?
Every page that is users will see is static. I'll be using Rails as an admin to CRUD them, but that's it, and that portion doesn't need to be AJAX.
Take a look at backbone.js. For an ajax heavy site, that's exactly what you need to help organize your code and keep your front end consistent with your database. Also, check out this excellent railscast on implementing backbone in a rails project.
I noticed that you said static site. Well, if the site is completely static, why bother with something like rails? I would suggest just coding it in html and javascript because rails is intended to be used for dynamic, database driven sites.
I would like create web app like shopify.com.
User can pickup subdomain(or domain), theme and have own store.
How can I do this?
Create main application, deploy it automatically like new standalone version and update it via git?
I'm using Rails 3.
Thanks for your advice.
Based on replies:
When I choose to use only one application (without multiple instances) and give user his subdomain, it will looks like their own website. But everything will be in one database (It's good idea?). And how can I have multiple themes in Rails app?
Take a look at LocomotiveCMS, specifically the routing system. Locomotive actually hosts multiple sites inside a single rails application. It does this by inspecting the request URL when it comes in and setting the current_site variable with the site which is set up to handle the domain. Then the current_site is actually just an object which contains all the pages, contents, settings, etc. for the specific site being served up.
So to answer your question, I think a good solution is to give your rails app the ability to serve up multiple sites based on the domain. It's not that hard, and it seems less fragile to me than trying to automatically deploy new instances of an app.
So far I have understood, you want to let your users have their own subdomain, different theme but the functionality would be same right. Users just need to have a feel of something of their own.
Well definitely, you need to have a single application that supports multiple subdomains.
A quick googling gave me [ http://37signals.com/svn/posts/1512-how-to-do-basecamp-style-subdomains-in-rails ]. May be you can get some insights from here.
For example if your service is http://www.myfi.com, a brief idea can be:
When a customer is registering, you should let him choose his subdomain. And the newly created account will be associated with this subdomain with a url. Say, http://customer1.myfi.com.
You should register for domain *.myfi.com so that anyone in the world hit with anysubdomain.myfi.com, it comes in your application.
Then from the url part, you should identify the subdomain (customer1) that is being used, and need to set that in session.
Now when someone will try to login, you must verify the account in the context of that subdomain's account.
In fact, all following actions need to be handled in the context of the subdomain's account.
Just tried the gather a glimpse of the implementation here. If you have confusion about something specific, share that also.
Edit:
Whenever you are thinking about multiple theme, you must have simple design which is completely driven by css and js. The app/view files should contain only content and HTML nodes with class names or ids.
Generally a UI designer can put more helpful ideas about how to make such theming mechanism. But all I can feel is, based on the chosen theme by customer, you have to load different css and js.
Actually the strategies can be indefinitely sophisticated and scalable, but its always wise to start with something easy. Then ideas will automatically evolve into better ones.
I'm working on an Ruby on Rails exercise listing application (https://rbzexercise.herokuapp.com) and I'm trying to integrate it with a Wordpress site (http://www.rubberbanditz.com). Is there an easy way to do the integration? As you can see, both are pretty established, so I'd really prefer not to have to rewrite either. Right now i'm using a work around that involves an iframe within the page http://rubberbanditz.com/exercise-library/, but we don't get any of the "google juice" from it.
Update:
Based on the comments, I've started looking into integrating the app to exercise.rubberbanditz.com, but following the directions at https://devcenter.heroku.com/articles/custom-domains doesn't seem to be doing the job. when going to exercise.rubberbanditz.com i just automatically get forwarded to the main page. Does anyone have any experience with setting a rails app to a subdomain, and can you point me to a good tutorial?
Thanks for any help!
Jason
Your iframe method is fine, but might lead to seo problems, since all of your links are trapped in the iframe.
Another option would be to take your WordPress theme and rebuild it in your /app/views/layouts/application.html.erb template. Once that's done, make a subdomain (maybe app.rubberbanditz.com or workouts.rubberbanditz.com) and setup your heroku app to use the new subdomain.
Google should view the two subdomains as the same website, especially if you're sharing common navigation elements, and both sites link to each other frequently.
The biggest downside is that now you'll have to update your design in two different places, which can be a huge pain in the ass.
I've used this approach before, running-php-inside-a-rails-app, for running php inside a rails application. Not sure if anything extra will be required for wordpress since I was just rendering a single page.
I'm just learning about SproutCore now, seems great. But I can't find a good answer on deployment options.
I'm starting small. Just implementing a single page of a complex site with SproutCore. Right now, that page is dynamically generated and served from my django based server. I serve all of my static files (.js, .css, images, etc) off of a CDN.
The page represents one customer.
So, on that dynamic page, it knows:
What customer we should be looking at, the ID, name, etc.
Where my media should be loaded from (absolute HTTP path)
How do I get a SproutCore based app to deploy and run in an environment like this?
I imagine I can upload the built sproutcore app to my CDN. Then in my html page, somehow reference it. But how does that SproutCore app know what server to request backend data from (I'd rather not hard code it)? It can't be installed in the root of the CDN, so how does it know how to load things relative to itself? I could tell it an absolute URL to load from at run time. With some pain, I could even tell it an absolute URL to load from at build time.
No answers on this one, here's what I did...
Ended up moving to Ember.js (aka SproutCore 2). That follows a completely normal "add .js to a page and serve it normally" model and doesn't have any interesting deployment worries, so it's a no-brainer.
I want to make a CMS where I can edit the view and css files online in my browser.
How can it be done? Does everything have to be in a database?
Generally Stack Overflow is not for research, it's for problem solving. That said…
No, your editable assets do not have to be in a database for this to work.
But you want them to be anyways; allowing write access to the files in your application isn't the best approach.
The rendering chain of Rails 3 allows you to sub in your own view parser and add a path to the built in view-finding that you can trick into loading from a database relatively easily.
Having your end users write in something like Liquid templates will save you a lot of work and allow this to happen with relative ease. They won't have access to unsafe Ruby methods, and you won't have to go through all the work of sandboxing them in Ruby.
CSS has fewer security implications, so you can fairly easily store raw CSS in the database and allow your users to edit it to their liking and then serve it up with a request to a stylesheets/:user_id/style.css request (with some heavy caching, like with Varnish, to save your application from being murdered).
Hopefully that'll get you started out in the right direction. If you decide to hook into the rendering stack in Rails I strongly suggest you pickup a copy of Crafting Rails Applications — one of the handful of example applications it walks you through does just that at a fairly granular level.