Simply copy and paste the following command line in your terminal to create your first Strapi project.

Get Started

The Tutorials section covers an introduction to Strapi, some advanced technical content, product updates and releases. From basic workaround to in-depth development guides. 

Tutorials

medium_Create a preview button in Strapi for Next.js-9.png

small_Create a preview button in Strapi for Next.js-9.png

thumbnail_Create a preview button in Strapi for Next.js-9.png

Create a preview button in Strapi for Next.js-9.png

The Product section covers our releases, feature reviews and more. 

Product

The Ecosystem section covers everything related to the world of Headless CMS and Strapi's place in it. 

Ecosystem

The latest Strapi-related news and major events happening for Strapi – including announcements, remote-work, organization and tips on running a start-up. 

Company

Get all the latest updates, news and events.

Subscribe to the newsletter 📣

Get all the latest Strapi updates, news and events.

Join our Newsletter

Everything you need to know about Content Modelling and the best practices. Learn how you can manage your content in your favorite headless cms.

A_Bite-sized_Guide_to_Content_Modelling_in_Strapi.png

A Bite-sized Guide to Content Modelling in Strapi

In this article you will learn the key concepts about relations and how to make the most of them in Strapi

Strapi Custom Plugin-17.jpg

Strapi Relations 101

Learn about the new community Publisher plugin, which provides users of Strapi CMS the ability to schedule the publishing and unpublishing of any content type.

New Community Plugin_ Content Moderation.png

New Community Plugin: Content Scheduling

>This article is a guest post by  [**Ukpai Ugochi**](https://twitter.com/hannydevelop). She wrote this blog post through the [Write for the Community](https://strapi.io/write-for-the-community) program.

As you imagine how intriguing your website should look, I bet you’re also thinking about managing the technical code behind it. You’re probably planning on taking some programming courses to make your website look as elegant as possible.

This is where a CMS (Content Management System) comes in. Just as the name implies, you can create, manage and modify website content without thinking much about the code.

A CMS works by either incorporating a traditional WYSIWYG editor, a decoupled CMS that separates the front end from the back end operation. Or a headless CMS that uses APIs (Application Programming Interface) to transfer data to any front end from your back end.

In this article, we will look into the best practices for Content Modelling in [Strapi](https://strapi.io/content-architecture), but first, we should understand what Strapi is and why it could be the right content management system for you.


## Why Not Strapi?

We know what a CMS is, so how does this relate to Strapi? And what does Strapi have to offer that other CMSs don’t? 

Strapi is an open-source headless content management system for Node.js-based applications. We discussed earlier headless CMS and how they allow you to integrate APIs.

With Strapi, **you can create customizable APIs**, that can be integrated into your application in the shortest time possible. With this feature, you can get your Node.js application running **in a few hours** instead of weeks/months.

Have you heard of the modern web development architecture [‘Jamstack’](https://strapi.io/blog/jamstack)? You can create your Jamstack application with Strapi as CMS for back-end functionalities.

This leads us to the question “Why not Strapi?”. There’s absolutely no reason to hesitate in using Strapi for your Node.js application. Let’s dive into the topic of today by considering the different Strapi Modelling types.

## Strapi Modelling Types

So, this is probably not the first place you’re coming across the word **modelling.** But, in this context it would only be fair to explain what Modelling has to do with Strapi. 
**Modelling** deals with the structure of your content. One can call models schemas—a visual representation of how your content is arranged in the database. 


    // Example of NoSQL database model(MongoDB)
    {
       _id: "1",
       name: "Joe Bookreader",
       age: "10 years,
       class: "High school junior"
    }

In this section, we look at the different Strapi Modelling types briefly.

**Content Type Modelling**
With Content-Type Modelling, the user creates a JSON file that represents how data will be structured in the database and a set of [lifecycle hooks](https://strapi.io/documentation/v3.x/concepts/models.html#lifecycle-hooks) in JavaScript file that determines how and when data should be called into their web application.

With the Lifecycle hook in place, content-type data structures can only be used for one API’s model. The expression below shows a simple JavaScript file for Content Modelling containing Lifecycle hooks.


    // Export module so instance can be called in application
    module.exports = {
    // initiate lifecycles
      lifecycles: {
        // Called before an entry is created
        beforeCreate(data) {},
        // Called after an entry is created
        afterCreate(result) {},
      },
    };

The corresponding JSON file for Content Modelling type looks like the expression below.


    {
      "kind": "collectionType",
      "connection": "default",
      "collectionName": "restaurants",
      "info": {
        "name": "restaurant",
        "description": ""
      },
      "options": {
        "increments": true,
        "timestamps": [
          "created_at",
          "updated_at"
        ],
        "comment": "",
        "draftAndPublish": true
      },
      "attributes": {
        "cover": {
          "collection": "file",
          "via": "related",
          "plugin": "upload",
          "required": false
        },
        "name": {
          "type": "string"
        },
        "description": {
          "type": "text"
        },

**Component Modelling**
Component Modelling involves creating models with data structures that can be used in many API’s models. With this Modelling Type, you don’t need to create a lifecycle hook, all you need is a JSON file as shown in the expression below:


    {
      "connection": "default",
      "collectionName": "",
      "info": {
        "name": "restaurant",
        "description": ""
      },
      "options": {
        "timestamps": true
      },
      "attributes": {
        "name": {
          "default": "",
          "type": "string"
        },
        "description": {
          "default": "",
          "type": "text"

You can generate a content type model with the command below in your CLI:


    // Syntax for generating a model
    strapi generate:model <name> [<attribute:type>] 
    options: [--api <name>|--plugin <name>|--draft-and-publish <boolean>]
    
    //Example of generating a model
    strapi generate:model category name:string description:text --api product

Creating a model will generate two files; a JavaScript file and a JSON file. If you want to create a component model, you must use the Content-Types Builder from the Admin Panel. This is because there’s not a CLI generator for creating component models.
Or, you can create your component manually by following the file path described previously.
If you want to generate a complete API with configurations, controller, model, and service, run the command below in your CLI


    // Syntax for generating a complete API
    strapi generate:api <name> [<attribute:type>] 
    options: [--plugin <name>]
    
    // Example of generating a complete API
    strapi generate:api address name:string description:text --plugin content-manager

Next, let’s look at how to implement Content Type Modelling in a Strapi application efficiently and best practices while using the Content Type Modelling. 

## Implementing Content Type’s Modelling, Best Practices

We have seen in other sections the different Strapi Model Types and how to create a simple model. In this section, we will dive deeper in Content Type Modelling and the best practices to efficiently implement Content Type Modelling in our Strapi application.

**Lifecycle Hooks**
We have seen that you can’t talk about Content Type Modelling without talking about Lifecycle hooks. Lifecycle hooks are the brain of any content model as they get triggered whenever Strapi queries are called. Let’s look at best practices in managing and creating custom content model’s Lifecycle hooks.

To configure Lifecycle hooks, set a Lifecycle key `lifecycles: {}` with the available lifecycle in your model’s JavaScript file **(<modelName>.js)** located at **./api/<apiName>/models/<modelName>.js.** The available Lifecycle hooks for Strapi Content Type model are *find, findOne, create, update, delete, count, search, countSearch.* The expression below shows an example of how to create a lifecycle hook coherently.


    // List of all available lifecycle hooks
    module.exports = {
    // initiate lifecycles
      lifecycles: {
        // Called before an entry is created
        beforeCreate(data) {},
        // Called after an entry is created
        afterCreate(result, data) {},
        // Called before entries are queried with find() method
        beforeFind(params, populate) {},
        // Called after entries are queried with find() method
        afterFind(results, params, populate) {},
        // Called before an entry is queried with findOne() method
        beforeFindOne(params, populate) {},
        // Called after an entry is queried with findOne() method
        afterFindOne(result, params, populate) {},
        // Called before an entry is updated
        beforeUpdate(params, data) {},
        // Called after an entry is updated
        afterUpdate(result, params, data) {},
        // Called before entries in a collection are counted
        beforeCount(params) {},
        // Called after entries in a collection are counted
        afterCount(result, params) {},
        // Called before searching strings in an entry
        beforeSearch(params, populate) {},
        // Called after searching strings in an entry
        afterSearch(result, params) {},
        // Called before entry search results are counted
        beforeCountSearch(params) {},
        // Called after entry search results are counted
        afterCountSearch(result, params) {},
        // Called before an entry is deleted
        beforeDelete(params) {},
        // Called after an entry is deleted
        afterDelete(result, params) {},
      },
    };

To change the properties of a Lifecycle hook, you can mutate its parameter and assign a fixed value to it `(data.name =` `'``fixed value``'``)`. A good practice to consider is to avoid reassigning the same parameter as it would have no effect.

You can as well customize Lifecycle hooks when building custom ORM (Object–relational mapping) specific queries. Lifecycles will not be triggered until the lifecycle function is called directly (manually) with expected parameters.


    module.exports = {
      async createCustomEntry() {
        const ORMModel = strapi.query(modelName).model;
    
        const newCustomEntry = await ORMModel.forge().save();
    
        // trigger manually
        ORMModel.lifecycles.afterCreate(newCustomEntry.toJSON());
      },
    };

**Content Type Relations**
Content Type relations allow developers create ***one-way***, ***one-to-one***, ***one-to-many***, ***many-to-many*** and ***polymorphic*** links among content types. 


![](https://paper-attachments.dropbox.com/s_228C76D40A5DEC709580DED9DFFCA3CEE0A6DADD1164CFD8E4E4032C66C1D792_1613393075550_image.png)


While a one-way relationship among Content Type is to link one entry to another entry. Although there’s a relationship between two entries, only one of the models can be queried with its linked item. A simple example is a daycare application that has a model for children in custody. The app registers only one parent that can pick the child up so, in this app the child is linked to a parent. Instead of writing each parent name by hand, one-way relationships help print the parent name wherever there’s a need for that.

Instead of linking an entry to another entry and querying only one model, you can link one entry to another entry and allow both models to be queried with one-to-one relationship. An example of one-to-one relationship usage is a school management app where each student is a member of a class. Each student has a class, and a student can be a member of only one class.

Just like one-way relationship, you can link an entry with multiple entries of another content type model with one-to-many relationship. However, in this context, one entry from a model is linked to multiple entries of another model and the entry of the other model is linked to only one entry. An example is a freelance app that has a user model and job model. With one-way relationship, you can link a user to their job(s) since a user can attend to multiple jobs at a time.

With many-to-many relationship, you can link an entry to multiple model entries. The other model entries can also be linked to multiple entries. A simple example is a movie app with directors, movie names and actors. The app has a directors model an actors model and a list of movie model. Many-to-many relationship allows you to link entries in the movie director, movie name and actor collections and save you from unnecessary repetition. 

Content type models can also perform [polymorphic relationships](https://strapi.io/documentation/v3.x/concepts/models.html#relations). This model relationship type is used for models that can be associated with different model types. With this relationship style, you can link different types of models to a model. Let’s look at the image model, you could want to attach this model to the user, vendor models etc. With polymorphic relationship, a vendor entry can relate to the same image as a user entry since a vendor can still be a user.

**Model Structure**
Let’s look at the structure of a Strapi content type model, what the info key means and the name/value pairs that make up the model information. We would also look at the model option key and how to effectively use it.

The info key gives information about the model. For instance, the model name and description. The name key holds the value of the model’s name, this should be filled appropriately. While the description key could be left empty, it could also be filled with a short description of the model.


    {
      "info": {
        "name": "<modelName>",
        "description": "" /**"description": "<short description about model>"**/
      }
    }

As a good practice, you need to set some model connection settings appropriately for content models function properly. The *kind*,*connection*,*collectionName*,*globalId*, and *attributes* are model settings that can be applied on a Strapi content type model.


    {
    // For connection type of single type
      "kind": "collectionType",
    
    // Connection name as defined in ./config/database.js
      "connection": "<collection>",
    
    /*Collection name where data will be stored, can be changed anytime but data maybe lost in no process since there's no automatic migration.*/
      "collectionName": "<collectionName>",
    
    // This will be adopted as the filename if filename is not configured manually
      "globalId": "<globalId>",
    
    // Object to define the structure of your model
      "attributes": {
          name: {
             type: String
             ....
          }
       }
    }

The model option in the model JSON file can contain the following key/value pairs, to add more properties to the model that are not part of the connection settings.


    {
      "options": {
        // This will add timestamps to each data entry
        "timestamps": true,
        // This will allow some attributes to be treated as private
        "privateAttributes": ["id", "created_at"],
        /* This key takes a boolean to determine if API response should be populated by creator fields*/
        "populateCreatorFields": true
      }
    }

**Attribute Validations**
In Strapi’s content type model, you can perform some attribute validations to limit, compare or manage data types that go into the collection or table. To apply basic validations to SQL databases, you’ll need to use native SQL constraints.
The expression below shows some basic attribute validation that can be performed with MongoDB database connection.


    // This is a simple content type model (JSON File) with attribute validations
    {
      "kind": "collectionType",
      "connection": "default",
      "collectionName": "partyhouse",
      "info": {
        "name": "partyhouse",
        "description": ""
      },
      "options": {
        "increments": true,
        "timestamps": [
          "created_at",
          "updated_at"
        ],
    /*Attributes containing basic validations for model property*/
        "opening_hours": {
        "type": "json"
    /*The value of this key is an integer, it validates the field, to make sure it's not below the min number*/
        "min": 1,
    /*The value of this key is an integer, it validates the field, to make sure it's not above the max number*/
        "max": 12
    /*This is a boolean, states if an attribute is required or not. If required, the field must be filled*/ 
        "required": true,
    /*This is used to hide sensitive data from server response.*/
        "private": true,
    /*This is used to define a unique index */
        "unique": true,
    /*If you set this attribute to false, the property cannot be configured by the Content Type Builder plugin*/
        "configurable": true,
    /*If you set this to false, the property will populate within REST responses*/
        "autoPopulate": true,
        },
    }
## I Always Choose Content Type’s Model System

In this article, we looked at what Strapi is and what it promises. We have explored the different Strapi Model Types, and the best practices to consider while implementing Content Type’s model. 

Most people like myself choose the Content Type Model system over the Component Model System since it comes with model options in the JavaScript file. In contrast to component type model system, [content type models](https://strapi.io/documentation/v3.x/concepts/models.html#where-are-the-models-defined) can be used everywhere in the project, they don’t necessarily need to be in a subfolder. I strongly advise you to use content type builder to generate models, if it’s your first time using Strapi.

It is possible to change Content Type Model default settings, but changing a model’s `globalId` is totally a bad idea, come off it. Since content modeling deals with lifecycle hooks, it will be beneficial to [understand lifecycle parameters](https://strapi.io/documentation/v3.x/concepts/models.html#lifecycle-hooks) and how they work. 



### Intro

<img src="/uploads/Untitled_2_8f818a6762.png" width="560" height="430">

Relationships are complicated. That's true in real life. And that's truer when managing content.

How many times weren't you sure how to connect 2 pieces of content? To then realize too late that it wasn't probably the best choice.

This post will give you key insights to make better decisions for your content modeling in Strapi.

### Relations in Strapi

![product.png](/uploads/product_c97aa9fdea.png)

In Strapi, relations are a convenient way to connect different entities with each other. For reference, an entity is an instance of a content-type. So "My first post" is an entity of the Post collection type.

> 💡 An **entity** is an instance of a content-type.

You can connect content types using the relations field in the Content-Type Builder.

With flexibility in mind, Strapi offers an extensive set of options to build the best relationships for your content. However, this freedom comes with a price: a bit of confusion and doubts about what you should do.

### Key Concepts

To better understand how relations work let's get first familiar with a few scary (read 'technical') words:

#### Cardinality

![cardinality.png](/uploads/cardinality_c856aeb5ac.png)

Another way to look at it is by asking yourself: "How many entities do you need to connect together?"

Strapi allows you all the possible combinations you can think of. Here they are with examples to illustrate them:

**One-to-one**

Example: a person has a unique id card.

**One-to-many**

Example: a post has several authors.

**Many-to-many**

Example: A student can follow many courses. And a course is followed by many students.

#### Directionality

![directionality.png](/uploads/directionality_238d46d39f.png)

Think of it as the flow of data: "Is it going one-way or both?"

You may be wondering why do we need to make a distinction. Both ways seem better right? In theory, yes. In practice, bidirectional relationships come with a significant performance cost for the database and hence the user experience. So you have to see where they make sense.

**Unidirectional**

If you need to map thousands of cities for a country, the workload would be huge to retrieve all the cities when you are viewing a country's details. In this case, you usually just need to connect a new city to an existing country. 

**Bidirectional**

A better use case for this type of directionality is being able to link a post to an author and vice versa. Since you probably won't have thousands of entities for each content-type. If you end up in this situation, first of all, good for you! You have some prolific writers 🙂 But joke aside you might need to rethink your relations if you start to see some performances decrease.

#### Association Types

![association-type.png](/uploads/association_type_02470cf43d.png)

This concept refers directly to the collection types you are using. Do you allow more than one to be connected?

#### Single

This is the simplest case, you just want to connect 2 content-types, such as Authors to Posts.

#### Polymorphic

This type is more complicated to handle on the database side. This is why it's usually hard to pull off in a CMS.

A nice way to illustrate this one is to use images as the collection type you want to connect to multiple content-types, such as authors, posts, and more.

You are officially a pro in relations. You know understand all the subtitles dealing with relations and you can now pick the best configurations knowing all the tradeoffs to take into account.

Feel ready to dig deeper into the topic? Give a read to [our documentation](https://docs.strapi.io/developer-docs/latest/getting-started/introduction.html) to see how you can apply your new learnings in Strapi today.

Good luck!

Status update: in (a) relationship(s)


## About this plugin

The Publisher plugin provides users of Strapi CMS the ability to schedule the publishing and unpublishing of any content type. I have also created a few other Strapi plugins that you might find useful:

*  [Transformer](https://market.strapi.io/plugins/strapi-plugin-transformer) - A plugin for Strapi Headless CMS that provides the ability to transform the API request or response. 
*  [Slugify](https://market.strapi.io/plugins/strapi-plugin-slugify) - A plugin for Strapi Headless CMS that provides the ability to auto slugify a field for any content type.
* [Website builder](https://market.strapi.io/plugins/strapi-plugin-website-builder) - A plugin for Strapi Headless CMS that provides the ability to trigger website builds manually, periodically or through model events. 
* [Notes](https://market.strapi.io/plugins/strapi-plugin-notes) - A plugin for Strapi Headless CMS that provides the ability to add notes to entity records. 

## Why did you build it? 

When the [Strapi marketplace](https://market.strapi.io/) was released I was interested in contributing useful plugins that would target a large audience of Strapi CMS users. While in the [Strapi Discord](https://discord.com/invite/strapi), quite a few users mentioned their interest in some sort of scheduled published content implementation for their own Strapi instances. This was my first indication that a plugin covering this use case would be useful.  I then noticed in the [v3 docs](https://strapi.io/blog/everything-you-need-to-know-about-strapi-v3) that there was a guide for setting up auto publishing on a cron and that was the decider. The next day I started working on the first draft of the Publisher plugin.

## How does it work under the hood?

Once the plugin is enabled, a Publisher section is added to all applicable content type records (i.e. any content type with draftAndPublish enabled). The section contains the option to add a publish or unpublish date for that record.

![image1.png](/uploads/image1_fc2ce9f364.png)

Once added, an action record for that change will be tracked by the plugin internally. Every minute the plugin will check if any publish/unpublish dates for content type records have passed. If a date has passed, the plugin will then trigger the publication state change for the relevant records.

```
strapi.cron.add({
 "*/1 * * * *": async ({ strapi }) => {
   // fetch all actions that have passed
   const records = await getPluginService(strapi, "actionService").find({
     filters: {
       executeAt: {
         $lte: new Date(),
       },
     },
   });

   // process action records
   for (const record of records) {
     getPluginService(strapi, "publicationService").toggle(
       record,
       record.mode
     );
   }
 },
});
```

## What’s on the roadmap?

I am constantly looking for new features to add to the plugin to make it more useful for users. Any and all suggestions are always welcome, at this point the next feature planned is the following:

A list view to see all published/unpublished and scheduled content - This will provide editors and authors a good overview of the state of their content.

## How can others contribute to this plugin?

All contributions and ideas are welcome. The easiest way to do so is via github or discord. Github Discussion has been enabled on the repo for anyone with questions or ideas. 

NPM package URL

[https://www.npmjs.com/package/strapi-plugin-publisher](https://www.npmjs.com/package/strapi-plugin-publisher)

Repository URL

[https://github.com/ComfortablyCoding/strapi-plugin-publisher](https://github.com/ComfortablyCoding/strapi-plugin-publisher)

Marketplace URL

[https://market.strapi.io/plugins/strapi-plugin-publisher](https://market.strapi.io/plugins/strapi-plugin-publisher)
