You don't have to provide every detail for each extension, but it will be helpful for you to understand all the details of your extension configuration.
Currently, the extension name is only for display purposes in the backend. The extension path plays a much bigger role:
Singular and plural versions of the path will be generated and used in different places throughout the project.
An extension path will be used to generate the URL slug for corresponding object listing and object details pages on the project website.
It's possible to change an extension's name and path anytime. However, if you've already published your site, you'll need to set 301 redirects to ensure that existing external links to pages in this extension will keep working. Please check our document on url redirection management to see how to redirect from old urls to new ones.
Extensions fields aren't website elements. They're simply fields where data is stored for each collection item, which you’ll be able to reference in your designs.
There are many different field types to choose from when structuring your extension. Each field translates into different kinds of content that you incorporate into the logic and design for your project.
You can add a new field, edit an existing field, or even remove a field altogether. In each field, you can modify the label and help text. Customizing the help text can make it clear to Collaborators what each field is intended for.
Note Renaming or deleting your fields may cause the existing mapping to stop working, if you are in doubt, please contact our support team so we can assist you in making these changes.
The reference field is a field that you can add to any of your extensions to link it to another extension. For example, each blog post may have an author. If you edit an author’s information down the road, it will automatically update on the blog post because of the connection that’s created via this reference field.
Notes For better performance, avoid having too many references (relationships) in your extension and deeply nested relationship.
In many cases, you don't want the system to automatically generate frontend pages for certain extensions. For example, if you have an article extension that contains many sections inside the article, you may not want to generate a separate page for each section. In such cases, you can mark these extensions as private.
