Watch videos with subtitles in your language, upload your videos, create your own subtitles! Click here to learn more on "how to Dotsub"

Planning Your Content Structure

0 (0 Likes / 0 Dislikes)
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.

Video Details

Duration: 5 minutes and 2 seconds
Country: United States
Language: English
License: All rights reserved
Genre: None
Views: 0
Posted by: drupalizeme on Nov 1, 2017

Planning Your Content Structure

Caption and Translate

    Sign In/Register for Dotsub to translate this video.