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?
Related
I have an app running on rails 5.1, I need the admin of the site to be able to edit static elements such as Backgrounds, Texts and Colors.
For example titles and images on pages such as home, about us, help and more..
I was thinking of creating a Page Model with multiple images, texts, and strings that wouldn't have a way for any user to add new records, only to edit existing ones. Then render each individually on their respective places, for example rendering the home page title as (on home/index.erb):
<%= Page.find(id: 0).texts[0] %>
But this seems overly complicated, specially in terms of maintainability and integration with gems such as active-admin. Is there a better practice?
ActiveAdmin can be used for this, but I think you really want a CMS, see https://www.ruby-toolbox.com/categories/content_management_systems
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".
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)
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.
My site, Rap Genius, explains rap lyrics. I want to create a new site, Rock Genius, that explains rock lyrics – otherwise it'll be the same (same layout, same DB schema; like Serverfault is to Stackoverflow)
What's the best way to do this?
Approach 1: Fork the code
Fork the Rap Genius code, change the relevant parts (e.g., "Rap" -> "Rock"), create a new database and go to town.
Pros: Can get it working quickly
Cons: It'll be somewhat painful to add a feature to both applications. Also it'll be impossible to give Rap Genius access to Rock Genius' data at the DB level
Approach 2: Keep it a single application
Whenever a request comes into my application, check the domain. If it's rapgenius.com, set the SITE_NAME constant to "rapgenius". Create a genre field on user-facing entities (songs, blog posts, etc) and update my queries to use the correct genre based on the SITE_NAME
Create a layer of abstraction above user-facing strings to that I can write <%= welcome_message %> instead of Welcome to Rap Genius! and have welcome_message() take SITE_NAME into account
Pros: Lots of flexibility
Cons: Lots of work!
Thoughts?
The second approach sounds better to me.
You've already highlighted the main pros and cons - it will definitely be more work, but will be much friendlier to maintain. Is there any chance of a third, fourth, fifth site? If so, there's no question that this is the right way to go.
You'll likely also be able to share user accounts, reputation, and any other kind of community based functionality more easily.
It might be worth looking at Rails i18n stuff for 'translating' static text, based on the domain name. That way you could avoid writing helper methods for every string you want to display.
Then you should be able to 'franchise' the site really easily - add translations of static strings, a handle for the new domain, and maybe some site specific images or CSS and you're done!