Using WordPress + Jekyll for the static pages in a Rails project - ruby-on-rails

I have a website that has product pages(dynamic) and corporate pages(fairly static). Both are coded in Rails. This means the marketing team has to involve the dev team to make any changes to the static pages. To address this issue, I am thinking about migrating the static pages to a CMS.
I am considering following approaches:
WordPress + Jekyll
Marketing team maintains the static pages at a private Wordpress site (eg: foo.wordpress.com).
When the marketing team is ready to deploy the change, a command line tool converts the WP pages to static pages using Jekyll and commits the changes to a git repository.
The changes to the git repository are uploaded to the Amazon S3 bucket associated with the raills application asset.
Marketing team is already familiar with WP and it is quite easy to find a good WP theming resource.
Rails based CMS : Locomotive/Radiant
The CMS resides within the rails app.
Has anybody done this type of deployment. In your opinion which approach is better of the two and why?

I prefer having the CMS integrated in with the Rails app. This way you only have one layout and set of stylesheets to maintain.
Finding a Rails based CMS that makes it easy to integrate into your own application and works the way you want it to might be a bit more challenging. Most of the ones I've seen, the CMS is the application and you have to use its hooks to customize things.
With that said, it isn't that hard to build a simple CMS to use within your own application. Wordpress uses tinymce as the wysiwyg, which isn't that hard to get working in a Rails app. Also, take a look at Refinery, as it may fit your needs just fine.

Related

Connecting Front End and Backend - Rails and Vue

I am a little confused on this.
If in Rails, with erb files we can build pages layout, 1) in what situations would we use webpacker to add vue.
What i understand so far is a Vue application would at times make a request to the server lets say to populate data. 2) Would that be the only use or are they other uses cases?
Also 3) is it best to generate a vue or angular app as a standalone (like vue create app so vue is in a front end folder and rails in a backend folder) or to use webpacker in rails
I'll try and answer your three questions at once, hope that's ok!
There are three common ways you can integrate Vue.js (or any JavaScript) library into a Rails application:
You can load it through sprockets, which is the built-in Rails asset packaging library. You would do this if your application is mostly going to be statically rendered and NOT a SPA (Single Paged Application). Sprockets is very tightly integrated with Rails, allowing you to refer to assets in your Rails templates and code. However, Sprockets is quite far behind Webpack in terms of the actual bundling/packaging, optimizations, and ease of use for any complex JS project. So you would only want to do this if you're adding a tiny amount of interactivity to a mostly static website.
You can load it through Webpacker. The idea of Webpacker is to give you a really easy way to start building a SPA with a rails backend. So you receive all the benefits of Webpack but don't need to tweek many configurations (at the start), or set up a separate web server, or worry about CORS. It's great for starting a new project/prototyping in or progressively integrating Vue.js into a larger static website. The downside is that Webpacker uses webpacker.yml for its default configuration which adds unnecessary confusion when you will eventually need to have more complex configs.
Finally you can load it through a separate web server ("standalone"), and in the long run, this will give you the greatest degree of freedom through less Webpacker middleware and access to the most updated webpack version. It also offers you the ability to scale, secure, and do fancy stuff like Server Side Rendering. The downside is this does require the most upfront setup and long-term maintenance time. AFAIK this is the most common way companies serve SPAs.

Ruby on Rails with Github Pages

I am attempting to host a project using Github pages. As I understand it, Ruby on Rails cannot be run on GH-Pages, with the exception of using Jekyll. My project is not a blog, and therefor Jekyll seems like overkill. Is there any other way to deploy to GH-Pages? Is there another way to generate a static site from my Ruby on Rails app that would allow for easier deployment?
Thanks for any and all input.
I'm afraid not. Rails is a dynamic system, meaning that the pages are generated from templates combined with data. GH-pages only servers static HTML, so even if you put static content into Rails, you would not be able to run the scripts that serve it.
Use Jekyll or Middleman to make a static site. If you really need Rails, use Heroku's free plan.
You could use actionpack-page_caching to generate page-level caches in the public folder of your Rails application, then add those generated pages to your GitHub Pages repository.
However, this entirely defeats the purpose of using something like Rails. Why don't you just create static pages directly and upload those to your GitHub Pages repo?

What is the easiest way to integrate static pages into Rails project

I have a landing page that was passed to me by a designer, the Structure is like this
|_startup
|_common-files
|_css
|_fonts
|_icons
|_img
|_js
|_less
|_flat-ui
|_bootstrap
|_css
|_fonts
|_js
|_fonts
|_icons
|_img
|_js
|_less
|_ui-kit
|_static
|_css
|_less
index.html
I didn't type the whole structure, but the idea is, it's quite a bit of directory, and it might be tough to separate it into javascript, css, image assets, and fonts(I am not sure where fonts go). My thoughts are, should I just have a subdomain and put this about page? I do want to integrate the page into my rails project. My question is, is there an easy way to integrate an independent page into my rails project?
From the book Learn Ruby on Rails:
A Rails application can deliver static web pages just like an ordinary
web server. The pages are delivered fast and no Ruby code is required.
The Rails application server looks for any pages in the public folder
by default.
So you can drop the directory into your application public/ folder.

Separating Angularjs and Rails apps as standalone components

I wanted to try out Angularjs. However, I have been trouble deciding on where I should located my angular app.
I am using Rails framework for the backend. I have seen tutorials where the entire angular app lives under the assets/javascript folder.
I was wondering if instead of living within the assets/javascript folder, I could make it live outside my rails directory entirely. That way, I can potentially separate my backend and front end entirely. (Is this recommended?).
I believe the asset pipeline also precompiles a lot of the assets. If I were to separate out the angularjs asset, would I need to precompile the assets somehow?
Thanks
I've been working through a similar set of questions. There are some good tools that allow you to integrate AngularJS directly into your rails asset pipeline, and they to me look good if you want just a little bit of Angular.
However, if you want a full Angular front-end, aka a single page web app, I think you'll eventually be limited by compatibility and some of the tooling. I feel like the Rails gems won't quite keep up with Angular, and so you'll be into version conflicts. I've also seen more and more tooling for Angular as a standalone, and I very much like the ng-boilerplate project template. I also like much of the testing tooling such as karma, and I haven't really sorted out a way to integrate karma with rails.
For that reason, I eventually decided that I'd keep the two separate. Initially, I did that through creating a rails application and a separate angular application (separate directories). I used ng-boilerplate as the framework for the angular end. I wrote a tutorial on that. This eventually got a bit frustrating, and I wrote some more thoughts on it, the main annoyance was that I had two git repositories and it was annoying to keep them in synch. It's also sort of annoying working with an IDE across two directories. I've ended up shifting to rails and angular being in the same folder, and they seem to play nice, as each uses different directories within that project.
In this current structure, I'm using the grunt setup that came with ng-boilerplate to minify all the code, package it and also run karma unit testing. I haven't yet nailed the end-to-end testing, but it's on my list. I've found this to be a relatively productive work environment. My chosen structure for my pages, controllers and karma test cases has some repeated code (I'm choosing not to factor it out to maintain readability). I'm planning to extend the rails scaffold generator to create the javascript framework for me - so when I create a persons rails scaffold, it will also create a persons angularjs scaffold for me. I'll update here if and when I do that work.
EDIT: I've completed the scaffolding work as well, which allows rails to automatically generate the angularJS elements when you generate the rails models/controllers etc. The blog post is here: http://technpol.wordpress.com/2013/09/24/rails-generator-to-generate-angular-views/
You could use a grunt based workflow:
How to manage AngularJS workflow with lots of script files
http://newtriks.com/2013/06/11/automating-angularjs-with-yeoman-grunt-and-bower/
If you start with a decoupled frontend, use mocks at first so you can stay within angular and not lose focus switching between backend and frontend logic. An advantage of building a single page application is that you can develop it independently of the backend api. See (http://docs.angularjs.org/api/ngMockE2E.$httpBackend) for information about mocking http responses.
We have been using AngularJS with our Rails application, in a way where we have been using Rails ERB templates, but switch over to using ng directive as and when required.
For this above setup we have used bower/bower-rails gem, which lets us use bower to manage the angular packages and their dependencies. We commit this into our repo, in the javascripts directory, and is taken care of by the Rails asset pipeline.
This setup has worked well for us considering we have above 50-50 % split of our views between the ERB templates and Angularjs.
More about this setup in the links below:
http://angular-rails.com/bootstrap.html
http://pete-hamilton.co.uk/2013/07/13/angularjs-and-rails-with-bower/
http://start.jcolemorrison.com/setting-up-an-angularjs-and-rails-4-1-project/
There are many advantages of separating out your api service (rails in this case) and your frontend components. As we do for ios/android apps, angular client can live on its own as a separate entity. It will be a static website that can be deployed on s3 or any static website host. It just needs to communicate with your api service. You could setup CORS to make it possible.
Some advantages of this workflow
You could use rails-api, which is a subset of rails application. If you are just going to use rails to build apis, it doesnt make sense to have all functionality that a complete rails app provides. Its lightweight, faster and inclined more towards building API first arch than a MVC arch.
You could use yeoman angular-generator to generate an angular app and make the most of grunt & bower to manage build (concat,uglify,cdnify etc) and dependencies (angular modules).
Deployments will become flexible. You won't need to depend on one to push the other.
If you ever plan to change your backend stack (eg rails to play/revel), you would not need to worry about your client components.
By splitting the development of the frontend and the Rails backend you could distribute the work over two development teams and keep the application as a whole very extensible.
There is also one downside to this approach.
By having the applications in two separate repositories, you can’t easily have a full integration test. So you will have to test the apps separately. You could mock your apis to test angular app.
We have been using this approach and would recommend others the same.
Less dependency & more productivity.

Locomotive CMS with Rails - location for liquid templates

I'm new to both Ruby on Rails and Locomotive CMS, but I'm just starting to create my first site with them.
I've got the engine running in a full Rails app (I'm going to need to deploy it on our own server later on). But it's just spitting out the 'Template' content defined through the admin interface, without any other template/content around it.
I can 'fix' it by shoving the html for the whole page in through this input field. But that's not right, surely? The Getting Started guide talks of putting the templates in the filesystem, at something like: Pages/index/first page. "All pages are inherited from index". I have an index.liquid under views/pages but it's not picking that up... (I've tried a couple of other locations too).
I'm sure this is a dumb question, but please could someone tell me where to put my template in the file system? Or how to point Locomotive to pick it up from the right place?
(I did get the file system liquid template working by defining it through the Rails way, with a route, a controller and adding a liquid template initializer I found here. But then it's missing the variables that should come from the CMS content).
I'm loading the site using bundle exec unicorn_rails. And I'm using Rails v3.2.13, Ruby v1.9.3 and Locomotive_cms v2.2.2.
Thanks!
I'm Didier from LocomotiveCMS.
LocomotiveCMS is a little bit different from the other CMS, in a sense, we offer a tool named Wagon to manage your site locally without having to install mongodb, rails and some other components.
Another huge benefit is that you can write your templates in HAML and your CSS in SASS/ SCSS or Less (we embedded Compass as well) and with our preferred texts editor (editing a whole site in a browser is a nightmare).
That's a nice eco-system in order to be super efficient when it comes to develop a LocomotiveCMS site.
Once you're done with your local work, you can deploy your site to a remote LocomotiveCMS engine in a similar way you push your application to Heroku. Actually, pushing a site will create the back-office for the final end user.
I suggest you to read that page.
http://doc.locomotivecms.com/guides/get-started/requirements
and this one too
http://www.locomotivecms.com/tour
Our message is still not clear on our official website but believe me, we are working to make it better.
Hope it will help you !
Didier

Resources