Is it common to have a 'Settings' content model?

When building sites using Rails, I often used the I18n feature to store short strings and settings. For example, while a blog might keep its Posts in a database table, I might use I18n in a view template e.g.

# locales/en.yml
  site_title: "My awesome blog."
  latest_post: "My newest post—"
  copyright: "Copyright 2018 Jane Doe."

# index.html.erb
<% post = Post.first %>
<h1><%= t :site_title %></h1>
<h2><%= t :latest_post %> <%= post.tile %></h2>
<div><%= post.body %></div>
<footer><%= t :copyright %></footer>

What’s the best way to do this with Contentful?

Is there a better solution than having a Settings content model with two fields key and value? e.g.

# index.html.erb
<% post =[1] %>
<h1><%= ( { |_, s| s.key = 'site_title' }).first[1].value %></h1>
<h2><%= ( { |_, s| s.key = 'latest_post' }).first[1].value %> <%= @post.tile %></h2>
<div><%= post.body %></div>
<footer><%= ( { |_, s| s.key = 'copyright' }).first[1].value %></footer>

So in the above, there would be 3 entries for the content model Settings.

Another option might be to have just one entry for the content model Settings but hold everything in one JSON field. It feels “odd” to have a model with just one entry, though.

Thoughts/advice/suggestions greatly appreciated!

Hi @m_contentful,

In order for you to implement locales, this should be a fairly straightforward process, similar to what you already are using. Basically, you can programmatically request localized content with something on the lines of
client.entries(locale: 'de-DE') for any given language in your space.

Regarding your second question, could you explain what exactly you’re trying to achieve with these two values? Indeed, doing what you described is certainly not a good implementation ( holding everything in one JSON field) and, instead, you’d be better off creating separate entries, which would provide a much cleaner, more efficient and identifiable approach.

Depending on the specifics of your use case, it may also be a good idea to create links among these items through the referencing field of a parent entry.

Let me know if that makes sense.

A settings content type certainly could be used to achieve this but it doesn’t have much semantic meaning so it’d be hard for editors to know what it’s purpose is.

I think a better approach would be to have a Site Settings content type which has all the settings needed for a particular instance of a site you are running. For example a title and copyright. The latest post setting is probably better handled programatically (e.g., query Contentful for all posts, ordered by publish date and limited to a single entry) but if it was an editorial decision to select which posts show on the home page, for example, then maybe that could be in there. With this approach you could easily use Contentful to power several different sites (i.e., multiple entries of the Site Settings content type) in which case you might have a domain field as well.

And to follow up what Gabriel said, the fields of the site setting content type could be localized so you could support multiple languages.

1 Like

Hey Gabriel and Charlie

Let me try to do a better job explaining my question with a real example. I’m wondering where to put strings that don’t naturally sit in a content model.

If I was building Hacker News, I would likely build Post, User and Comment models. All good.

When it came to making my view template, though, I’d need some extra strings that would have been stored in en.yml if I was using Rails. I’ve highlighted some of these strings in blue for Hacker News:

  hide: "hide"
  points: "points"
  sign_in: "login"
  site_name: "Hacker News"
  submit: "submit"
  submitted_by: "by"

What would be a good way to use Contentful to manage these strings? I would have approx 100 of these strings that would be used by both a website and a mobile app.


1 Like

Hi @m_contentful, this knowledgebase article of ours might provide some inspiration:


That’s exactly what I was looking for! Thanks @matt . Glad to know my original thought of a content type with key and value fields was halfway there. :grinning:

1 Like