Editable area on landing page for site admins - ruby-on-rails

My Rails app has a landing page for visitors with welcome/contact info.
At the moment, this info/html lies in a template.
I want to make it editable for the admins of the application.
What options do I have to accomplish this? Should I create a model with a first_page attribute where I store the html submitted by the admins in a form? Or is there any other way?

You'll need some kind of content management system (CMS). There are lots of ready-made ones for Rails. see http://codecall.net/2014/02/10/best-ruby-on-rails-content-management-systems-cms/
You could just write your own, but you'll end up writing functionality around editing the pages, and then the admins will ask for the ability to upload images etc, and you'll think "gah, wish i'd just used an off the shelf CMS".

Related

Documents on a rails website

I am developing a portal of sorts in Ruby on Rails using PostgreSQL.
I require different pages (each page represents a different topic of interest) on the portal to show different documents. The admin will have the ability to upload additional documents to each page.
No where is the entire list of documents on the website required
What is the best practice to implement such a system and is there any tutorials for the same?
It sounds like you want a content management system. Alchemy CMS is a good choice for rails.
That's a multi-tenant application, and normally you do this by associating all the records with a user or an account, sometimes both. This is done with a has_many/belongs_to pair most of the time for any records that are user or account specific.
You'll also have to be specific in each controller to only access records that the person can see, so you'll need to define an access control mechanism of some kind. There's modules for this, writing your own can be tricky.

Allowing admin of rails site to edit html

I have the whole admin backend setup, but I need to add a feature were admins can either edit the HTML of the site, or if easier edit just the text around the site. The main idea is to have the admin edit the form labels through the backend. Was wondering which is the best direction to go with?
I've used Rails internationalization support for things like this in the past: static bits of text that admins, non-technical stakeholders, business people, etc want to tweak and tweak, and I want to enable them to do it quickly (and without bothering me to fix a typo they would)
For the being able to edit form labels you could/should use Rails Internationalization Support for form fields. Here's a super brief intro to this, but there are better documentations to dive into.
Rails Internationalization support allows for more than just storing keys in YAML files - there are few different ways to do it. There's also CopyCopter an open source admin website for internationalization keys.
As far as having non-technical people edit other parts of your site, internationalization could help here too: allowing folks to change whole phrases/blocks of text in your app.
For example, instead of hard coding, "Welcome to the site" in a .html.erb file you do <%= t :welcome %>. An admin can edit the welcome internationalization key and change it to something more appropriate, "Yar! We be welcoming you to the site" if you want to go pirate theme. Or Whatever.
It also gives you internationalization structure for free: makes it easy for admins to edit the English of the site, but you have all the infrastructure for making a French version of the site too - just get a translator to fill in French internationalization values.
Maybe you could realize that with following editor:
Github: https://github.com/jejacks0n/mercury
Demo: http://jejacks0n.github.io/mercury/
Railscasts: http://railscasts.com/episodes/296-mercury-editor (maybe outdated)

Is active Admin a good fit for a complex admin interface for a daily deal rails 3.2 app?

I am building a daily deal app in Rails.
I just installed activeadmin gem which is really great and easy so that I can now create and monitor users. My need for creating and managing deals is quite complex:
I need to be able with the basic text fields (name of deal, date of deals, product name...) to add on the Deal's page stuff that for me (as a Rails newbie), i would associate more with a real CMS than with active admin, that is to say, i must add pictures (through url addresses on amazon S3), embed videos, associate features on certain deals such as vote up or down, and have a sort of html5 WYSIWYG html/text editor allowing me like i'd do on a wordpress site to move/add/arrange/re-position between each others texts, videos, sliders, call to action buttons, videos and much more.
I feel activeadmin is great for basic monitoring and maybe creation of objects for simple cases but as it works so much "automagically" I fear I won't have enough control or ability to bring many features and CMS stuff into active admin that i should build the "Deals admin Interface" on my own pages and not rely on active Admin for this.
What do you think about it ? Can I put all that stuff "inside" my Active Admin pages/controllers...or should I build it "outside" active admin ?
Thanks for your help!
any answer for this question will be subjective..
formally, you can override anything (views, models, controllers) in activeadmin very easily. all this cases have minimal but enough instructions in documentation
there are some difficulties to override look&feel for example with bootstrap to receive more responsive layouts but in general case AA is administration framework designed for generic backends so this feature is not critical
according to your question to manage forms it supports formtastic so you can use any power of this gem
you can override form with generic _form.html.erb in one line with form :partial => "form"
you can use html-editors like this or this or other (like this) out of the box
BUT
this moment always insensibly comes when you begin to understand that some features can be done much better without any gem (not only activeadmin)
the real question is when will you cross this line but it is only up to you..
my advice: try to imagine most difficult issue and implement it with activeadmin. if you solve it with activeadmin - you can try to use it in future. if not => ...
one more thing: you can look at rails-admin - it is very promising and competitive to AA

Dealing with "mostly static" content in Rails

My current project has some dynamic stuff but also has quite a few of these "mostly static" pages. These are pages that need to be updated CMS style, like the "about" page or the "welcome" page, but only rarely.
My end goal is to have the site owner able to log in and edit the text of these pages. There will be multiple translations of these various pages.
What is the best way to deal with these "mostly static" pages?
My current thinking is that I will need to create a model for the organization and store the "about" blurb and other info as properties of that model. Then I can translate using globalize2. It seems goofy since there will only ever be one of these models.
Does that seem reasonable?
Anyone have a better idea?

Letting users write DB-stored CSS for custom layouts

I'm currently building a web app (atop Ruby on Rails), which will let users style their own areas (personal blog pages), and was wondering what are the best ways of accomplishing this?
I think Liquid for templating would be good, but how would you handle styling? My aim was to have a DB field associated with each blog dubbed "style" which will store a custom stylesheet, is this the best approach?
I've tried it so far with the "sanitize_css" helper method, but it just strips the "#stylebox" tags out, meaning nothing is displayed.
Any ideas?
Thanks.
Currently I'm also working on almost a similar requirement as you do. I'm also trying to create a CMS for users to add pages, style them etc..
My Approach as follows
each user will have his/her subdomain. (I use a before_filter to get the current users subdomain and load his/her website)
About styling, I prefer to have the style sheet as a physical file. Given that your method will have the more flexibility of editing the style sheet, I dont like the idea of having the stlesheet code on top of my page. Insted, I allow users to load their styleshets (Using paper clip)
So when the site loads I will get the css paths from the DB and load the stylesheet from the path.
Later I'm planning to read the file and load it to a textarea so that users can edit their stylesheets and when saving override the existing file;
For layouts i use liquid as well
cheers
sameera
I would honestly allow themable elements on your page, and then store each of those style rules as a field (or conglomerate them into one giant field) in the database. Enforce some validation to ensure that they don't use any funny business (if they're only coding for specific div's, they shouldn't need to use any curly braces.)
Then generate the CSS on the fly.
The reason? If you ever want to serve up ad's on your site, and you allow them to just upload the entirety of their CSS, they can easily turn off visibility on the ad div.
I think it's "safer" to control what they're allowed to theme; sure more advanced users will get ticked. But do you really want to be the next MySpace? ;-)
if there is too much of code then serialize the data and store it as text in db.
That would be much better i think
If your going to allow areas for users to have complete control over their CSS, then I would probably avoid the database altogether and use a structured file system approach. You could create a sub-domain or folder for each user that contains a main.css. This also allows you to scale well as features grow for your user (pictures, etc.)
With that said, as Robbie mentioned, you might want to consider limiting what styles a user can and can not control. Otherwise, you would probably find things getting out of hand quickly. For this approach, you would probably want to use the database for storing property values of the elements that can be modified.

Resources