Blog
A blog is one of the most commonly implemented patterns for web apps.
See the blog pattern in action by clicking on the link below:
Demo Blog pattern (opens in a new tab)
You can create this pattern in Prepr automatically when you create a model. Choose the Blog pattern template and the models and components listed below will be created for you.
Introduction
This guide takes you through the modeling process for a blog pattern with suggested models and components and their relationships. A basic blog pattern consists of 2 types of pages:
1. A summary of articles.
In the example below, we see that each article has a category to group similar articles, intro text, an image and at least one author. There is also a link to each article.
2. A specific article.
In the example below, we see the article content, author information and recommended articles. The recommended articles can easily be implemented in Prepr using the standard Recommendation feature. Check out the Recommendations docs for more details.
Using these sample web pages as a basis for our modeling, imagine that we also want search engines to find our articles easily.
Let's look at the Article model in more detail.
The Article model
In our schema, we've decided to create an Article model. The Article model is our starting point where we make a lot of our modeling decisions.
See an example Article model below:
Within the Article model we define the following fields:
| Field name | Field type | Description |
|---|---|---|
| Title | Text | The title of an article visible on the web app. Required. This title can be used to query the article through the API. |
| Slug | Slug | Part of the URL that is used to link to this article. Required. The slug is also useful as an internal field for API queries on this article. We set it to the Title of the article. |
| Categories | Content reference | A reference to the Category model. The category field allows the article to be grouped which can be used in the web app in different ways, for example, to filter articles by a category. |
| Author(s) | Content reference | Used to reference the Person model which has content about the article authors. |
| Content | Dynamic content | This field is the main body of the article and we define it to allow the content editor to include the following elements: - Heading2 and Heading3 - Paragraph: Allow bold, italic, and ordered list styles as well as links within the article. - Assets: For images and captions. |
| SEO | Component | An embedded SEO component. This component has fields for finding this article through search engines. |
Note that we also define a section (collapsed by default) to group the SEO fields.
See a complete list of all other available Prepr field types.
Let's look at some fields in more detail.
Categories
We set up a Categories field in the Article model. This field is a Content reference to a separate Category model. This makes the category content reusable in the web app. For example, different articles can have the same categories.
See an example Category model below.
The Category model is defined as follows.
| Field name | Field type | Description |
|---|---|---|
| Title | Text | The title of a category visible on the web app. Required. This title can be used to query the category through the API. |
| Slug | Slug | Part of the URL that is used to link to this category. Required. The slug is also useful as an internal field for API queries on this category. We set it to the Title of the category. |
| Icon | Assets | An icon that represents the category. In Prepr, you can add an icon SVG file by enabling the File option on your Assets field. |
| SEO | Component | An embedded SEO component. This component has fields for finding this category through search engines. We re-use the SEO component defined in the article model. |
Author(s)
We set up an Author(s) field in the Article model. This field is a Content reference to a separate Person model. Person is set up as a model to avoid duplication of person content. The idea is that there could be content for persons with other functions and not only for article authors. For example, imagine that employees are shown in an About us page. The general Person model caters for this use case too and makes your schema more flexible and robust.
Within the Person model we define the following fields:
| Field name | Field type | Description |
|---|---|---|
| Full name | Text | The name of a person. Required. |
| Profile pic | Assets | An asset field that allows a photo of the person to be attached. |
| Bio | Text | A text area for profile information about a person. |
SEO
We set up an SEO field in the Article model. This field is an embedded Component. SEO is set up as a component because its field structure is used in multiple models, namely, the Article, Category and Page models.
Within the SEO component we define the following fields:
| Field name | Field type | Description |
|---|---|---|
| Meta title | Text | The title tag. Required. This title is the criterion for search engines to find an item such as an article or category. It is also the the title that appears when an item is shared on social media. |
| Meta description | Text | A brief description about a particular content item, for example, this description can be included in a summary view of an article in your front-end. This is also the description that visible when an item is shared on social media. |
| Social media image | Assets | This image is used when displaying a link to this item, for example, the Open Graph image that you see when sharing links within social media. |
Other use cases
In conclusion, this is just one example of how you can model a blog pattern for your web app. Feel free to reuse this structure and amend it to your needs.
You could also consider including the following use cases in your schema.
- Add the author's social media info. You could set up social media info as a component and embed it in the Person model.
- Add role information to the Person model. If you need to show some employee information in your front-end, it's a good idea to allow their roles to be stored for this purpose.
Want to learn more?
Check out the following guides:
Was this article helpful?
We’d love to learn from your feedback