One of the great things available on a variety of blogging/article writing platforms is a WYSIWYG, what you see is what you get, editor that allows you to format your text exactly as you’d like it to display easily. Right now, this blog does not have a WYSIWYG input and all the formatting (what little there is right now) is done by using markdown and the kramdown gem to process it. It does work, but it’s not ideal, and being able to use a WYSIWYG while maintaining certain things (like formatting of code examples) would be great and perhaps overcome some of the built-in limitations of using markdown I haven’t worked around yet (like writing code examples in HTML isn’t really easy at this point), but I can’t just throw a gem into my application without properly vetting it, so that’s what this will be about.

Getting Something to Work With - Quickly

In his book practicing rails, author Justin Weiss presented an idea I have found useful in the past. Basically, you build a tinyapp , something simple and basic you can experiment on, try new things on, basically do whatever you want without worrying about messing up your focused projects. For something like testing these gems, a tinyapp is ideal.

Generally, I build my applications up steadily, with testing, writing only the code that I need. Sure it takes longer, but it also makes sure the application does what I want it to and hopefully has little extraneous code. This means that I build the models, controllers, views, attributes, and anything else, on my own with little input from rails. Rails does have a built-in ability, scaffolfds, to create a lot of the basic functionality (the CRUD) for any database table you want to use, but in my opinion it’s not only a ‘short cut’ but it does create a lot of extra code you might not want. However, in a situation like this, where I just need something to work on, scaffolding saves me time. Building my tiny app takes two commands. First, create the application; rails create wysiwyg (because I’m testing WYSIWYG gems), and after moving into the wysiwyg folder entering rails g scaffold Article title:string body:test. Using scaffold tells rails, basically this: I don’t want to write any of the basic CRUD functionality on my own, so could you use your built-in code to create the model, controller, views and all associated code for basic CRUD functionality of articles in this application? You can? Thanks rails, that’s awesome of you. So after you process the migration created by the scaffold (I don’t know why it doesn’t also do that automatically but it’s ok), this application has all the functionality and layouts I need to do some experimenting with the WYSIWYG gems. It’s not something I would normally do, but in a situation like this, it’s not about building the application cleanly or properly, it’s about getting the application to a state, quickly, where I can focus on the true purpose.

Testing the Gems - Froala

The first WYSIWYG gem I had even seen a detailed introduction to was the Froala gem over at Ruby Thursday. Though it requires some work getting set up, it does seem like it has a robust functionality. (If you watched the video you’ll see that is also covers the sanitize gem, which might be useful in the future but I’m going to stay focused on the wysiwyg for now)

Even though this app isn’t necessarily anything that will grow beyond being tested for the wysiwyg gems, I am going to put it under version control so that I can log the steps taken and go back to earlier steps if necessary. So, after I set up the local git repository, now I can move on to installing the Froala gem into this application.

To get started with the gem I head to the wysiwyg-rails gem page to get started installing it into my little tiny app, but first, I just thought of something I wanted to do that I hadn’t done yet.

Not to my surprise, following the instructions, either from the Ruby Thursday or the github runs into an error when running on Rails 5. The gem did install font-awesome-sass, but gem "wysiwyg-rails" is (as of today, February 18th, 2017) downloading an older version that requires font-awesome-rails. Investigation of the gem code at the repository shows the change has been made to the offending file (engine rb) but it hasn’t propagated out to the gem version yet. This is solvable as you can download a gem directly from the repository using gem "wysiwyg-rails", git: "". That cleared up the error I was having with the CSS loading and I could move onto dealing with the javascript.

That was the only issue. Following the remaining steps in the Ruby Thursday tutorial, I was able to duplicate what the tutorial did and use the editor. However, upon further review I found that of all the available plugins I could easily find, I saw none that could handle code examples like I currently do with coderay and kramdown. It’s possible that there is something more complicated, or a work around I could build, but the goal of this is to find something that saves me the time without having to create anything new, so it’s on to the next one.


In the past, when randomly looking for WYSIWYG editors with no directly play, I often saw mention of TinyMCE as an option that seemed to work for a lot of people. So that’s the next gem I would be testing.

The instructions on the github repository ran into no errors this time, so after following the steps (slightly more involved as they are) for getting the TinyMCE editor set up in a Rails application, I quickly saw that the editor was up and running and could do everything I had accomplished above with Froala, and as it turns out, it has one distinct advantage. Like Froala, TinyMCE also has a variety of plugins, but one really, immediately caught my eye. TinyMCE has a plugin named code sample, and it turns out it is a syntax highlighter exactly like I was looking for, and thanks to the magic of converting something to a Rails gem, getting access to the functionality is as simple as changing the tinymce.yml file to include codesample in both the plugins and toolbars. That quick change and, voila, I could enter code snippets, in a variety of languages (perhaps more than coderay even) and have them display properly within my editor. However, saving them led to the code not being properly displayed on the page where an article would be viewed, but that was to be expected. The documentation for code sample points out that a javascript library called prism.js was used to display the on other pages, so that had to be dealt with.

I was a bit concerned regarding using the prism.js library as I have never installed a JS library into rails. I have no doubt it’s doable, but I wasn’t 100% sure how I was going to do it, but fortunately, I didn’t have to. It seems that a kind, enterprising github user had created a ruby gem that made it easy to access the prism library in rails. Not only that, it seems to be currently maintained and only started about 7 months ago, so thank goodness I wasn’t looking earlier.

Following the simple easy to follow instructions on the prism gem homepage, it was installed, and just like it should be, the code sample that showed up in my editor also showed up in my show page as well.

A deeper look at the available plugins and it seemed to me that TinyMCE would be the solution, for now, to all the things I would need my WYSIWYG to do. For instance there is a way to import your own custom CSS as well directly into the editor so that will come in handy as well.

We Have a Winner, For Now

Though I planned to look at more WYSIWYG gems, it seems that, for now, I have a winner. Using the TinyMCE combined with prism allows me to replicate what I am doing now with my kramdown / coderay combination in a cleaner, and more ‘user friendly’ fashion. Sure there will still be kinks to work out in regards to security, implementing and testing, not to mention that once I do implement it, all my previously written articles will have no formatting, and that will take some time to work with (and I just thought of a quick functionality that I could add that would notify the user if they were reading an article before the WYSIWYG was installed), but in the long run, if this works, it saves me time, and formatting issues, when writing articles, which I need since sometimes these things go on for a while.

So, be on the look out, cause that’s a major change for this blog that is going to save me a lot of time.