Drupal 8 User Guide: 2.5. Planning your Content Structure

By | August 13, 2019

Planning Your Content Structure
with Joe Shindelar This tutorial demonstrates how to plan the content structure
for your website. By the end of this tutorial, you should have a rough draft
of a plan for the content structure of the site, including which type and subtype of entity to use for which content, and which pages will contain
listings of content. Before you get started with this tutorial,
you want to make sure you’re familiar with the concepts
of entities and fields and how they relate to the fact
that each page on your site that someone might interact
with is actually composed of numerous different
pieces of modular content. And finally, this tutorial
will follow along with the Farmers Market scenario being used
throughout the user guide. Start by brainstorming about the content your site needs
to contain, which could include content
that visitors would be looking for as well as content that you
want to show to visitors. Here’s an example from
the Farmers Market guiding scenario for this
set of tutorials. Throughout these tutorials, we’ll be building a
Farmers Market website, following the scenario presented here. Take a moment to read it
if you haven’t already. It’ll help when planning the
content structure of the site. As we start planning, for each identified piece of content, decide which content entity type would be the best fit. In doing this, you’ll need to consider where and how the content
will be used and edited on the site. For example, in the
Farmers Market site scenario, you might want to display the
hours and location of the Farmers Market on
the side bar of every page. For that content, a single
custom block makes sense. As another example,
you might decide that pages displaying information
about each vendor should be content items
managed by the core Node module because you want vendors to be
able to edit their own listings. The core Node module
permission system lets you do this easily. These decisions do not necessarily always have only one right answer. For instance, you can decide that
vendor pages should be user profiles instead of
content items. But if you did that,
the content would be tied to a specific user account and it would not be as easy to later change the ownership
of a vendor page to a different user account. Within each content entity
type you identified, decide what division into
subtypes would make sense. For example, in the
Farmers Market site, you could probably decide that under the content item
entity type, there should be 1 content
type for basic pages, like the homepage and an About page, 1 for vendor pages and
1 for recipe pages. For each entity subtype
you decided on, decide what fields are needed. For instance the vendor
content type might need fields for the
vendor name, web page URL, image, and
description. Next, decide on what content
listings are needed, which could be entire pages, or smaller areas on the page. For each listing, you’ll need
to determine what entity items should be listed and then you’ll need to decide
in what order and with what filtering options
they should be displayed. For example, you might want to
give the site visitors the option to search by keyword to filter the list down
to a subset or to sort the list. You’ll also need to decide
what information from the entity items
should be shown, which might result in adding
to the list of fields you determined in the previous step. The Farmers Market site
for example, needs to have a recipes
listing page that lists content items of
the type recipe, with the ability to filter
by ingredients. So that means that the recipe
content type needs an ingredients field. For each identified field on each entity subtype, identify what type of data
it should contain, such as plain text, formatted text, a date, an image, file, etc., and how many values should be allowed. Most fields are single valued. But for example, a recipe
should allow for multiple values in its
ingredients field. Consider which fields would be best as references to
taxonomy term entities, fields whose values should be chosen from a list of allowed values. Those with allowed values that
are expected to change and grow over time are good candidates. An example is the ingredients field
for the Recipe content type. Consider which fields
should be references to other content on the site. As an example of that, since vendors will be
submitting recipes, a field will be needed on the
Recipe content type that references the vendor
content item for the vendor who submitted
the recipe. Combine all of your brainstorming about different type of contents lists and how you would like the data on
your site to be structured into a document that you can
refer back to later while building your site. In this tutorial we went through some examples of the types of
things you’ll want to keep in mind when creating a plan for
the structure of your site’s data, including things like
what kind of content do you want to collect and display, how does that content relate to
other content on your site, what form fields do you want to
present to a user who is adding or editing a piece
of content, and things like that. As well as how will that
content be used in lists throughout your site. As you learn more about
how Drupal functions, make sure you come back
to your original document and reconsider your previous
decisions and make updates as necessary.

Leave a Reply

Your email address will not be published. Required fields are marked *