Blog pattern

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

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.

article overview

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.

detailed article

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:

article-model

Within the Article model we define the following fields:

Field name
Field type
Description
TitleTextThe title of an article visible on the web app. Required. This title can be used to query the article through the API.
SlugSlugPart 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.
CategoriesContent referenceA 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 referenceUsed to reference the Person model which has content about the article authors.
ContentDynamic contentThis 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.
SEOComponentAn 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.

category-model

The Category model is defined as follows.

Field name
Field type
Description
TitleTextThe title of a category visible on the web app. Required. This title can be used to query the category through the API.
SlugSlugPart 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.
IconAssetsAn icon that represents the category. In Prepr, you can add an icon SVG file by enabling the File option on your Assets field.
SEOComponentAn 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.

person-model

Within the Person model we define the following fields:

Field name
Field type
Description
Full nameTextThe name of a person. Required.
Profile picAssetsAn asset field that allows a photo of the person to be attached.
BioTextA 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.

SEO-component

Within the SEO component we define the following fields:

Field name
Field type
Description
Meta titleTextThe 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 descriptionTextA 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 imageAssetsThis 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: