Author

That's a common question we get from people who join OSTraining for the first time. They want to know about the skills they will need, and what kind of classes they should take.

In this guide, I'll give you an overview to help you get started with Drupal development.

The Skills You Need

Clients are often surprised when we recommend that new Drupal developers sit through our beginner and site-building training.

Unfortuantely, it is very common to find Drupal websites that were built by talented developers who had no Drupal knowledge. A good understanding of Drupal's user interface and key concepts is absolutely critical. Being a good developer is not enough.

Here are the skills that will be useful for you as a new Drupal developer. An in-depth knowledge of Drupal is at least as important as any other skill:

Learn Drupal 8 Theming

Unlike Drupal 7, the latest version of Drupal relies on the Twig template engine. Get started by watching the How to Use Twig class.

You also see how to make user accounts more interesting. You do this by allowing users to add more information about them.

Drupal Roles and Permissions Explained

Drupal users are defined by their role. Roles are defined by the permissions you assign the role. Drupal has three default roles:

Anonymous: Visitors to your site who are not logged into your site.

Authenticated: Anyone who has an account on your site and logs in is authenticated. The Authenticated role also serves as the minimum set of permissions that is given to all logged in users. Drupal sets some default permissions but you can change them.

Administrator: Users assigned the administrator role can do everything on the site.

You might be thinking that this is enough for your site, but just in case you have bigger plans, let's take a look at how you fine tune access to your account via three examples.

Creating an Article Writer

Start with the example of an Article writer. Such a person will be a role to which you can assign users. If users are in this role, all they can do is write articles. There are four steps to make sure a user account is set up correctly:

Add a role.

Set the role permissions.

Create a user.

Test the user to make sure it has the correct permissions.

Following are those four steps.

Click "People" on the admin menu bar and then on the "Roles" tab.

Click "Add role".

Type Article writer for the new role name.

Click "Save".

Now that the Article writer role has been created, you need to decide what user in that role can and can’t do.

Click the Permissions tab to see the permissions available:

On the left side of the list, you can see the modules that have permissions settings. The modules are ordered alphabetically. Across the top of the list, you see the four roles that you have set up.

The permissions for the three default roles are already set. You can also see that some permissions for the Article writer role are already set. This is because those permissions have been giving to the Authenticated User role. By default, if you grant permission to the Authenticated role, all subsequent roles (except for anonymous) inherit said permission. That is why the check marks for comments are grayed out and can't be deselected.

Your article writer is going to need more permissions than those granted by default to the Authenticated role, so let's get started.

Scroll down until you find the header Node. Remember that Node is Drupal’s geeky word for content.

At the top of the Node area, you see some admin-type permissions, as shown below:

Scroll a little further to find the Article permission set. To keep things simple in this example, check all of the Article permission boxes:

Create new content

Delete any content

Delete own content

Delete revisions

Edit any content

Edit own content

Revert revisions

View revisions

To ensure the Article writer can "Add Content", check the permissions box for "Use the administration toolbar".

Click "Save permissions" at the bottom of the page.

Now let's set up an actual user account for an Article writer.

Click the "List" tab at the top of the screen.

Click the "Add user" button.

As you can see by the absence of the red asterisk, an email address is not required. However, the email is necessary for the user to receive messages, such as password reset. If you have an email address, other than the one you used when creating your first account, enter it now, so that you can see the emails users will receive. Otherwise, leave it blank.

Username: articlewriter

Password: articlewriter

Roles: Check the "Article writer" box.

If you included an email address, check the box to "Notify user of new account".

Click "Create new account".

The fourth and final step is crucial. Permissions are a vital part of your site’s security, and if you don’t test your permissions, you could easily allow some users to do things that can compromise your site.

Following is a basic method for testing. You can use the following steps:

Open a browser where you are not already logged in.

Log in by going to http://[your_web_address]/user/login.

Observe that the menu bar to which you have grown accustomed is lacking in options. That is good. First test passed.

Click "Shortcuts" and then "Add content".

The "Create Article" form appears immediately, with no other content types available. Test passed again!

There are limitations to this testing. Because you created the account and the password, you were able to log in as that person and test.

However, on a real site, it is neither feasible nor safe to know what your users’ passwords are. Instead, you can use a module called Masquerade to easily test any user account. Here’s how it works:

Go to your homepage and you'll find the Masquerade block and its search box.

Type in the name of the user you want to test and click "Switch".

The Masquerade block disappears and an "Unmasquerade" link appears in the black menu bar at the top of the screen. Don’t worry: by default, this link appears only for administrators.

You can now browse the site and see exactly what an Article writer can see. Simply click the Unmasquerade link, and you’ll be back at the administrator account.

Creating a Moderator

Now see one more example of user permissions. Let's set up a role called Moderator. People in this role can moderate comments and forum posts. These people help to make sure that your site is a pleasant and spam-free destination.

Go to "People", "Roles", and then "Add new role".

Type Moderator for the Role name.

Next, we'll set up the permissions:

Click the "Permissions" tab and scroll down until you find the Comment module.

Check the "Administer comments and comment settings" box in the Moderator column.

Scroll down until you find the Forum module and check the "Administer forums" box in the Moderator column. This allows the Moderator to rearrange the forum boards if needed.

To ensure the Moderator can add content, check the permissions box for "Use the administration toolbar".

Check the "View user information box" in the Moderator column. This can help the Moderator when advising the site administrator if an account needs to be blocked.

Click "Save permissions" at the bottom of the screen.

Now we can move on to the create the Moderator account:

Click the "List" tab at the top of the screen and click "Add user".

If you have yet another extra email account, enter it, otherwise, leave the email blank.

Username: moderator.

Password: moderator. You can set this to something more difficult if you want. Drupal warns you that this is a weak password.

Roles: Check the "Moderator" box.

Click "Create new account".

Now it's time to test the account:

Visit the front page of your site.

Use the Masquerade module to see the site as moderator.

Click "Forum" on the Main menu.

Access any forum topic, and you can edit or delete the topic.

If there is a comment on a topic, you can moderate it using the "Edit" and "Delete" links.

Click any user’s account name. The easiest account to find will probably be your main administrator account.

You'll see the user profile. In the next part of the chapter, we're going to make this look more interesting!

If you think the user needs moderating, click the "Edit" tab. You change the user status from "Active" to "Blocked". Please do not try this with your own administrator account!

You can grant your Moderator role permission to administer users (see the User section on the Permissions page). Note that this is a very powerful permission. If granted, any user with Moderator role can access any other user's account and change its settings. Grant with caution.

That post focused on Drupal 7, and some things have changed in Drupal 8.

Here's an updated explanation of how to set up dropdown menus for a Drupal 8 site.

Step #1. Choose a theme with dropdowns

Before you can use a dropdown menu, choose your theme carefully.

Many themes don't have dropdown menus built-in. That includes Drupal's core themes, such as Bartik. Unless you want to make major code changes, it is best to choose a theme that already have dropdowns available. To find out whether a theme does have dropdowns, read the theme's description and documentation on Drupal.org.

There are two main reasons for reusing fields. First, reusing fields can save you time over defining new fields. Second, reusing fields also allow you to display, filter, group, and sort content together by field across content types. For example, the contributed Views module allows you to create lists and tables of content. So if you use the same field on multiple content types, you can create a View containing all of those content types together displaying that field, sorted by that field, and/or filtered by that field. There is one main reason to not reuse a field: different permissions. For example, you may need different user roles to have different levels of access to a field, depending on the content type to which it has been added. This can be difficult if you reuse a field.

Advantage: re-using fields can make your simpler

Yes, there can be a speed boost, but the time-savings are very small. A more compelling advantage is that re-using fields can sometimes make site administration simpler. Web Initiative sum this up nicely:

Reuse of fields can also reduce the system’s complexity. Instead of creating and maintaining 10 different fields, Drupal admins maintain only two fields and their documentation. Database administrators only need to improve performance of two extra tables. KISS is always a good principle.

It definitely would be easier to apply permissions, setting and design elements to one re-used field rather than 10 unique fields.

Advantage: some content works well with re-used fields

reusing fields also allows you to display, filter, group, and sort content together by field across content types. For example, the contributed Views module allows you to create lists and tables of content. So if you use the same field on multiple content types, you can create a View containing all of those content types together displaying that field, sorted by that field, and/or filtered by that field.

One comment writer on the Drupal.org documentation makes the same point about Views. They point out that Views can combe content in sophisticated ways. So, if you have multiple different content types, with different date fields, then Views can combine them into a single view. However, they also point out that Views isn't so sophisticated with sorting. So, if you have multiple different content types, with different date fields, then Views will struggle to sort the content on all those different date fields.

Disadvantage: Re-used fields are inflexible

at first it's a good idea, but give it a few weeks, reqs change, you end up creating separate ones anyway

To a large degree, if you choose re-used fields, you are limiting the changes you can easily make to your data later.

Disadvantage: Re-used fields make data harder to export or migrate

Re-using fields could become an issue when you need to export your data or when you need to migrate to a new version of Drupal or another platform.

Each Drupal field has it's own database table, as shown below. Extracting that data can be tough. The Features module (the most common way to export Drupal data) struggled for a long time with shared fields, although current versions can handle them more effectively.

This advice is similar to our thoughts on using multi-sites. Whenever you start to build dependencies between codebases or database tables, you add complexity to your site.

A real problem however is the number of fields you have. Because currently in Drupal 7, the complete field configuration of all fields, no matter if they're loaded or not, is fetched from the cache on every single request. I've seen sites with 250+ fields, where loading and unserializing the field configuration takes 13MB+ memory."

So, re-using fields could possibly give small performance improvements by letting us have a lower total number of fields.

However, those small improvements may lost elsewhere. This from Web Initiative again:

[fields] extra complexity to a Drupal system. When creating a new field, the field’s definition is added to the field class table and the field’s configuration is added to the field instance table; meanwhile, a new table is added to the Drupal database to store the field data. Database tables add complexity to the system. In addition, queries of nodes will incur JOINexpressions of tables to field data. Multiple JOINs will impact database performance since MySQL responds poorly to queries with multiple JOINs of tables if not properly configured.

Summary

Sorry that we don't have an easy answer to this question. This is a question where you will benefit from reading around the issue and understanding the pros and cons. If you're doing a real site build, it will be worth constructing the site in a test environment to learn more about how these pros and cons impact your site's needs.

About the author

Steve is the founder of OSTraining. Originally from the UK, he now lives in Sarasota in the USA. Steve's work straddles the line between teaching and web development.

Let me give credit where credit is due. The Drupal community have transformed the way it works in 2018.

In years gone by, Drupal was not a very well-organized project. Everything was done in a stereotypically "open source" way with loose roadmaps and vague planning. The apex of this was the development of Drupal 8 which dragged on for over 5 years.

About 18 months ago, I wrote a post "When is Drupal 7 End-of-Life?" Unfortunately, no-one knew the answer. The deeper I looked, the more messy and confusing Drupal's plans became. The release cycles for Drupal 7, 8 and 9 were all vague and undefined.

Drupal 7 will be end-of-life when Drupal 9 releases in 2020, but there will be commercial support options for at least another year.

Drupal 8 will be end-of-life by November 2021.

Drupal 9 will be released in 2020, and it will be an easy upgrade.

Dries has a post called "Drupal 7, 8 and 9" which explains these timelines in detail. He includes this image which sums up Drupal's plans:

I've been criticial of Drupal's previously haphazard project management, but they're doing a superb job in 2018. There are real roadmaps, clear plans, and logical explanations. Kudos to the Drupal team.

About the author

Steve is the founder of OSTraining. Originally from the UK, he now lives in Sarasota in the USA. Steve's work straddles the line between teaching and web development.

Drupal 8.6 is not ready yet and is scheduled for release on September 5.

However, we already know what features will be in the final version. A Release Candidate is now available and at this point, the core is frozen and no new features will be added.

So, now is a great time to dive in and discover what new features we'll see. Some of these features are outstanding!

New Feature #1. Demo Data

For the very first time, you can install Drupal and get a whole demo site to explore. If you install Drupal using your browser, you'll see a new option: "Demo: Umami Food Magazine".

After you complete your Drupal installation, your site will be populated with dummy content for a food magazine.

There are about 20 sample content items in the Umami demo. Many of them are in a sample content type called "Recipe". It looks like the demo data was chosen to give a good overview of mutiple different field types.

There also a couple of landing pages, created with sample Views. All-in-all the demo data is short and sweet but it does look much better than a plain Drupal install.

New Feature #2. Media Library

Finally we're getting somewhere with media in Drupal! For many years, Drupal has shipped with almost no media handling. This was the most commonly requested feature whenever we did Drupal training.

Since the release of Drupal 8.4 in late 2017, Drupal has had some new media handling features. But, they were still very limited. With Drupal 8.6, we take a big step forward. There is now a "Media Library" module in the core. It is in the "Experimental" stage, so you'll need to enable the module:

To use the new library, create a field using the "Media" type. It will show as an "Entity reference".

When you go to create content using this field type, you can click "Browse media" or "Add media".

You'll be able to search through all the images uploaded to your site and choose the file you need. This is a huge - and long overdue - step forward for Drupal. This Media library is created using Views, so you can customize this screen however you wish.

New Feature #3: YouTube and Vimeo Embeds

In addition to the new media library, Drupal 8.6 also has improved support for remote embeds.

Create a field using the "Media" type and select the "Remote video" option.

Go to Content > Media > Add media.

Click "Remote video".

Enter a YouTube or Vimeo URL.

Cick "Save".

Now when you go to create content with a video field, you can click "Browse media":

You can choose the video that you added earlier:

The idea is that you save your content and see the URL automatically turned into a video on the front of your site. However, in my testing, I wasn't able to successfully select videos and click "Select media". Perhaps the bugs will be squeezed out before the final release.

However, in addition to the bugs, the workflow for this embedding is still clunky. You have to add the video before you create content which is a significant hurdle for content creators.

New Feature #4. Layouts

Drupal's layout builder features continue to get better, although the two key modules are still experimental: Field Layout and Layout Builder. Enable both of those modules if you want to test the layout options.

You can enable the layout features for each content type individually.

Go to Structure > Content types.

Edit a content type and click "Manage display".

Check "Use Layout Builder.

Check "Allow each content item to have its layout customized."

Click the "Manage layout" button.

You'll now be taken to the front of your site, where you control the layout for this content type.

Click "Add Section" and you'll be able to choose from "One column", "Two column" and other options.

In this image below, I've chose a new "Two column" layout. Slightly confusingly, you will now see "Add Block" although you can actually add much more than just a block.

When you click "Add Block" you'll be able to choose from almost all the data on your site. You can add fields, user data, forms, views and much, much more. Don't be confused by the term "Add block". This option allows you add almost any site feature to your new layout.

One of the most interesting things about this layout option applies to much more than just content types. You can use these layouts for media, contact forms, taxonomy, users, and more. I'm in the camp that feels that WordPress' Gutenberg editor is half-baked and not that useful. In contrast, the Drupal team seem to done an outstanding job with this new layout builder.

New Feature #5. Workspaces

The Workspaces feature allows you to preview your entire page before publishing it. Workspaces is still in the experimental stage, so you will need to actively enable it.

Two things to note about this feature:

It's not yet compatible with Drupal 8's content moderation features. You do need to remove some key moderation features before enabling Workspaces.

Don't confuse "Workspaces" and "Workflows". Workflows is a different feature, related to content moderation.

Let's see how to use Workspaces.

After enabling Workspaces, go to a URL on the front of your site. You'll see a green "Live" button in the top-right corner.

Click the green "Live" link.

Click the "Stage" link on the left-side of the black banner.

Now you can activate the "Stage" workspace. Be careful because the "Cancel" button is where you'd expect the "Confirm" button to be.

Make changes to your content on this page. Any changes will not be publicly visible, even if you save them.

Click the orange "Stage" button.

Click "Deploy content" button and you can make your changes live on your site.

I did find some bugs with this Workspaces feature, and the UI is a little clunky. You can see some mistakes in the image above. But overall, this is another excellent new feature in Drupal 8.

Bonus

Drupal 8's migration modules are now stable! It's way too late of course. Drupal 8 launched three years ago and only now do we have a stable migration. It seems fair to guess that this significantly slowed adoption of Drupal 8. The one exception is new "Migrate Drupal Multilingual" module which is still experimental.

Over the last few months we've worked with more and more Drupal 8 sites. Those projects all had one thing in common ... they used the Paragraphs module.

Paragraphs is a very popular module for handling content in Drupal 8. Paragraphs works in a similar way to content fields, but also provides a wide range of options for the design, layout and grouping of your content.

Instead of putting all their content in one WYSIWYG body field, end-users can choose on-the-fly between pre-defined Paragraph Types independent from one another. Paragraph Types can be anything from a simple text block or image to a complex and configurable slideshow.

Often as web developers, we create sites that are meant to be used day-to-day by mostly non-technical users.

One pain point of this for many people—developers and clients alike—is the process of trying to implement a method of content creation that non-technical users can easily understand but that also provides all the options they need to create content in the ways that they want. For example, clients might understand how to add a pull quote into a content body, but it might not end up centered or formatted quite correctly. They may also want to do something more complex such as include an ancillary box of information inside an article, in which case they might not even know where to begin.

The Paragraphs module can make processes like these much more manageable for non-technical users while also giving developers the ability to control the formatting and appearance of such specially formatted elements at the theme level.

In practice, Paragraphs allows us to insert elements much like content fields, but instead of adding these around the body of any given piece of content, they are effectually inserted throughout the body.

For this demonstration, we’ll imagine we are creating a website called “Life Advice for Free,” which offers informational content in the form of articles. You can follow along on any other development website if you wish, making minor adjustments as necessary.

Installing the Drupal Paragraphs Module

Once you have downloaded these two modules and placed them in your /modules directory, install them for your site.

Basic Configuration of the Paragraphs Module

Paragraphs works by allowing us to create what are called “Paragraphs types” that in our case will collectively replace the Body field of any given content type with which we want to use these Paragraphs types.

In order to begin taking advantage of Paragraphs, you must first create at least one Paragraphs type, and then you have to add that Paragraphs type to a content type. This process can seem confusing at first, but it is easy to become familiar with once you set up one or two Paragraphs types.

In our demonstration, we’ll replace the Body field of the default Article content type with a handful of Paragraphs types.

Important: If you are testing this on a site that already has content of type Article, do not delete the Article content type’s Body field as we are about to do in this demonstration. If you do, you will lose the body of all Articles on your website. If you are working on a site in which the Article content type has already been used, you should create a new content type on which to test out the Paragraphs module.

On our "Life Advice for Free" site, we will begin configuring Paragraphs by editing the Article content type.

Go to Structure > Content types.

Click the “Manage fields” button in the Article row.

You will now be on the “Manage fields” page for the Article content type. On this page, click the dropdown arrow next to the “Edit” button on the Body row, and click Delete.

Confirm deletion on the next page.

Now we will create our first Paragraphs type.

Navigate to Structure > Paragraphs types.

Click “Add paragraphs type.”

On the next page, we need to provide a label for this paragraphs type. For our demonstration, we’ll call this one “Body text,” since we are going to use it as the body of our content.

Click “Save and manage fields.”

On this “Manage fields” page, click “Add field.”

In the following “Add a new field” dropdown list, scroll down, and under “Text,” select “Text (formatted, long, with summary)”. This is similar to the default Body field that the Article content type often uses—a long-form text area with a WYSIWYG editor.

On the following “Add field” page, we’ll label this particular field “Body text” as well.

Click “Save and continue.”

Next we are taken to this field’s “Field settings” tab. For any of these fields, we may specify an allowed number of values. It can be useful to allow more than 1 value for some fields—particularly those that accept individual discreet pieces of information, such as dates, image files, or short-form text fields for information such as names—but for long-form text areas, it is often unnecessary to provide additional values since paragraphs can simply be placed one after the other in a single text area.

Leave the default settings at “Limited” and 1.

Click “Save field settings.”

On the following “Body text settings for Body text” page, we can keep all of the defaults. Notice that users will still have all of the formatting options that they normally would with the text area’s WYSIWYG editor. We are not taking anything away from them. What we’ll be doing instead is giving them an additional, improved method of adding certain types of elements to their content. Click “Save settings.”

On the next page, click the “Manage display” tab. Currently this Paragraphs type has only one field—the Body text field. We don’t want a label to appear along with the text from this field, so select “Hidden” under the Label column for this field. Format should stay as Default. Click “Save.”

Once you’ve completed this configuration, look at your breadcrumbs and click “Paragraphs types.” You’ll see that now we have a Paragraphs type called “Body text,” with one single field: a long text field also called “Body text.” Now we need to add this Paragraphs type to the Article content type in order for that content type to be able to use it.

To make this Paragraphs type available to the Article content type, navigate to Structure > Content types. Click “Manage fields” for the Article content type. Then click “Add field.” To use our new Paragraphs type with this field, open the “Select a field type” dropdown list and select “Paragraph” under “Reference revisions.” After selecting “Paragraph,” provide the label “Body” because this is what we are using as the body of our content. Click “Save and continue.” On the next page, “Type of item to reference” should be set to “Paragraph,” and “Allowed number of values should be “Unlimited.” By selecting “Unlimited,” we can insert this special field provided by our configured Paragraphs types as many times as we want. This will become helpful when we begin inserting other things besides text into the body of the content. Click “Save field settings.”

On the following “Body text settings for Article” page, we need to make our previously created Paragraphs type available to this field. To do this, check the box next to “Body text” under “Type,” near the bottom of the page. This is how we make that particular Paragraphs type available in this field. As we add more Paragraphs types to our site, we can come back and make those available to this field as well.

Click “Save settings,” and the site should take you back to the “Manage fields” page for the content type.

Now we’ve finished replacing the previous (default) Body field with our new Body field, which utilizes Paragraphs, and specifically the “Body text” Paragraphs type that we created. Now we’ll configure a few more settings so that it appears the way we want.

To start, we’ll click the “Manage form display” tab so that we can place the new Body field in a prominent location on the content creation page for Articles.

On this page, scroll down to find our new Body field, and drag it near the top of the list, just below Title.

Click “Save.”

Now click the “Manage display” tab so we can make sure the field shows up in the proper place for site visitors. Again you’ll find Body at the bottom. Drag this near the top, just below Image. We’ll treat that image field as a large sort of introductory or lead-in image for our Articles and not part of the content itself. Click “Save.”

At this point, we have completed the setup for our Article content type using this new Paragraphs field. Now it’s time to create some content to test it out.

Go to your site’s Content page, and click “Add content.

Click "Article".

You can enter any title for your article. For this example, let’s call our article “How to Make 100 Friends.”

Now, down to the Body field, you may have noticed that it looks slightly different, though it still uses the same long-form field with a WYSIWYG editor just like before. The difference now is that we have an encompassing Body field that currently contains one Body text field. Just below the Body text field, you should see an “Add Body text” button, which allows us to add multiple fields. At this point, that would be unnecessary because the long text field currently in use is perfectly suited for inputting long, multi-paragraph text, so we wouldn’t need to add an additional field when we could just add more text in the same field. Later, though, we’ll see that it becomes very useful to be able to add additional Paragraphs fields when you have implemented multiple Paragraphs types on your site. For now, just enter a paragraph or two of text into your Body text field.

Save your article and view the page as any visitor would see it.

At this point, the new Body using Paragraphs looks no different from an article using the default Body field. With Paragraphs in place, though, we will soon be able to allow our content creators to add additional elements to the content without having to know how to style it properly.

CSS for the Paragraphs Module

A big part of what makes Paragraphs so useful is that we can write CSS for specific in-content elements so that content creators don’t have to try manually styling as many of these elements themselves using the WYSIWYG editor or inline CSS. This means we’ll be customizing our site’s theme to make these elements appear exactly as we want.

In many real-world cases, you’ll likely be working with a custom theme or subtheme of your own, in which case you may edit it freely. For this tutorial, we are going to create a quick and easy subtheme of the default Bartik theme so that we can follow best practices and add our own CSS without editing the Bartik them itself. (We avoid editing Bartik—or any other core or contributed theme—directly because if we do so and then later apply a released update to that theme, our own modifications will be lost.) If you are unfamiliar with creating subthemes, that’s ok. We are not digging into the process extensively but instead are creating a direct copy of the theme, to which we will then apply some slight alterations. This is an easy process.

To create a subtheme, you first need to access the server on which your site is hosted, and navigate to your site’s root directory. Once there, open the “themes” directory. This is where all custom and contributed themes and subthemes are placed. In this “themes” directory, create a new folder called “custombartik,” and navigate into this new directory.

Now we need to add a couple files to this new directory. The first will be the theme’s info file. Open up whatever code editing software you use for web development. These info files require several pieces of information: the name of the project (the name of our theme), the type of project (“theme” in this case), the machine name of the base theme if this is a subtheme (as ours is), a short description, and the major version of Drupal (7.x, 8.x, etc.) for which the theme is built. We will enter this information in the following form (type everything exactly as you see it):

Make sure the base theme name “bartik” remains un-capitalized—it is the case-sensitive machine-readable name that we need. With this information entered, save the file as “custombartik.info.yml”. It is important that you save it with exactly the same name as the folder you created followed by “.info.yml”.

Now we need to create our theme’s libraries file, where we will tell Drupal where to find the theme’s CSS and what version of the theme this is (more information can be provided, but this is all we need for our purposes). Open a new file. In this file, pay close attention to the indentations here. Each indentation should be a two-space tab. Enter the following information exactly as it appears:

global-css:
version: 0.1
css:
theme:
css/style.css: {}

Save this file as “custombartik.libraries.yml”. This file essentially tells the website that this is version 0.1 of the theme (we could have given this any version number) and that there will be a stylesheet located inside our theme directory (“custombartik”) at css/style.css.

Now we need to go back to our info file to tell Drupal to use the information under the “global-css” container to find our stylesheet. Open your custombartik.info.yml file, add a blank line under your “core: 8.x” line, and then add the following line of information, again keeping the indentation exactly as it appears below:

At this point, we are ready to add these two files to our theme. Upload or copy your custombartik.info.yml and custombartik.libraries.yml files into your custombartik folder.

Now add a folder called “css” inside your custombartik folder. Go ahead and create a blank file called “style.css” and upload it to this directory. This will be our stylesheet.

Before we create our stylesheet, however, navigate to your website’s “Appearance” page. Scroll to the bottom of the page, and under the “Uninstalled theme” section, you should see your Custom Bartik theme. If you do not see it, make sure that your custombartik folder and all of its files are present in the themes folder of your site’s file system.

Click “Install and set as default” under your custom theme so that your site will begin using your theme. Once this is done, navigate to your homepage, and it should look almost exactly like Drupal’s default Bartik theme, with the exception that you will probably see a broken image icon in place of the Drupal logo. The theme looks just like Bartik because what we have created is a subtheme of Bartik with no customization yet in place. If your site does not look like Bartik, and especially if it looks like plain HTML with no CSS styling, go back to your two .yml files and make sure they look exactly as printed above.

Finally, to fix the broken logo image, we’ll copy the logo straight from Bartik into our subtheme. This is ok because we aren’t actually changing anything in Bartik. Navigate to your site’s root directory, and go to core/themes/bartik. In here, you’ll see a file called “logo.svg”. Copy this file into your subtheme (the “custombartik” directory). On your website, navigate to Configuration > Performance, and click “Clear all caches.” Now the logo should appear on your site.

Multiple Paragaphs Fields

Now that we have a subtheme that we can safely edit, we can begin setting styling rules for the elements of our content controlled by Paragraphs. Before we do so, we should create a new Paragraphs type that requires special styling rules. We’ll follow our example of having a field that inserts a centered image in the midst of an article.

Navigate to Structure > Paragraphs types, and click “Add paragraphs type.” We’ll set the label for this one as “Centered image.” Click “Save and manage fields.” On the next page, click “Add field,” and select “Image” under “Add a new field.” We’ll label this field “Centered image” as well. Click “Save and continue.” On the next page, we can retain all default values, so click “Save field settings.” Then, on the “Centered image settings for Centered image” page, we’ll add a few simple restrictions. Set the Maximum image resolution to 650x450 and the minimum resolution to 50x50. Set the maximum upload size to 1 MB, and click “Save settings.” (These specific settings are not necessary for the Paragraphs type to work properly; we are including them simply to mimic a real-world scenario.)

Now click on the “Manage display” tab, set the Centered image label as “Hidden,” and click “Save.”

At this point, we need to add this Paragraphs type to the Paragraphs field we have in our Article content type. Go to Structure > Content types, and click “Manage fields” next to “Article.” You may be tempted to click “Add field” here for our new “Centered image” Paragraphs type, but remember, this is going to be intermingled with our custom Body field. So, instead, we will add Centered image to the Body field we created. Click “Edit” next to “Body,” and scroll to the bottom of the page. Here you’ll see “Centered image” available beneath our “Body text” Paragraphs type. Check the box next to “Centered image” to make it available to this field, and save your settings.

Now we’ll add an image using this field. Navigate to your Content page, and edit your “How to Make 100 Friends” article. Let’s imagine we want to add a centered image somewhere in the middle of our article. Beneath the Body text field, you’ll again see the “Add Body text” button to add another Body text field within this Body field. However, if you click the dropdown arrow next to this button, you’ll see that “Centered image” is now also available. Click this button, and choose some image file to upload here. Then provide some alternative text, since that is required.

Now we’ve added the image to our content, but currently it is placed below all of the text. This is where we will make use of an additional Body text field. Click “Add Body text.” Now we have, top to bottom, a field of body text, a centered image, and another field of Body text. Note that, though you shouldn’t need to do so at this point, you can freely move these around via the drag-and-drop arrows on the top left of the individual Paragraphs fields. To have the centered image appear sandwiched between article text, simply go to the first Body text field, select whatever text you would like to appear after the image, and cut that text from the field. Then scroll down and paste that cut text into the second Body text field (after your image). Now click “Save.”

When you view your article now, it will still not look quite correct. Since we have not yet added any styling rules to our theme, the image is likely to be floated left (as it is by default), rather than centered. However, it should appear after the text of the first Body text field and before the text of the second Body text field. Now we have an article on which we can test some custom styling rules.

Controlling Paragraphs Types with CSS

We’ll go to our custom subtheme now to begin styling the output of the Paragraphs fields we’ve created. For now, we’ll target the “Centered image” field specifically, rather than the encompassing Paragraphs field from the content type. We’re doing this because we will want this field to be centered anytime, regardless of where it is. Thus, by setting rules directly for “Centered image,” we avoid setting unnecessary multiple rules for multiple contexts.

We do need to target the “node” class, however, because there will be, by default, some styling for this field targeted under the “node” class. Thus, we have to override those rules.

Open your “custombartik” subtheme’s stylesheet at custombartik/css/style.css. The file should still be empty, but now we will begin adding rules to it. We’ll keep things simple for now. Add the following lines of code to your stylesheet:

With the first set of rules, we are simply centering the image horizontally within its field class and making sure no text or anything else floats next to it. The second set of rules is not strictly necessary, but is some common code to make sure images don’t end up larger than they should be in relation to the content area.

Once you’ve added this to your style.css file, save your changes (from here forward, any reference to saving changes in your subtheme also assumes uploading or otherwise copying the files to your server if you are not editing directly on the server on which your test site is located). Then on your site, navigate to Configuration > Performance, and click “Clear all caches” to load the theme changes on your site. Navigate back to the article on which you added the image to be centered (or refresh the page if you already have it open). The image placed through the “Centered image” Paragraphs type should now be centered with no text floated to either side of it. There may be further styling we’d like to add, but for the purpose of this tutorial, we’ve done what we want to do at this time—make sure that the output of this field is strictly controlled by CSS so that users adding content do not have to style anything themselves using the WYSIWYG editor or other inline styling methods.

Multi-field Paragraphs Types

We can also create Paragraphs types that themselves consist of multiple fields. For example, instead of a “Centered image” type, we can create a “Centered image with caption” type, which would consist of an image upload field and an accompanying text field for any single element of that type. This, too, helps us remove the burden of layout from those adding content to the site so that we can control content display at the theme level.

Let’s create this “Centered image with caption” type to practice the process of creating a multi-field Paragraphs type.

As you might expect, this process is going to be similar to that of creating a single-field type. To create this new Paragraphs type, navigate to Structure > Paragraphs types, and click “Add paragraphs type.” Label this type “Centered image with caption,” and click “Save and manage fields.” Then click “Add field.”

Since our previously created “Centered image” field is exactly what we want for the image portion of our new Paragraphs type, instead of creating a new field, we can reuse the previous one. So, do not select anything under “Add a new field” on the “Add field” page. Instead, under “Re-use an existing field,” select “Image: field_centered_image” (or “Image:” followed by whatever machine name your centered image field was given). Keep the “Centered image” label, and click “Save and continue.” We do need to once again configure out settings for the image’s size bounds on the next page. Let’s once again enter a maximum image resolution of 650x450 pixels, and a minimum of 50x50 pixels. Set the maximum upload size to 1 MB. Click “Save settings.”

Now we’ll add another field. Keep in mind we are still inside the settings for our new Paragraphs type, so once we add this second field, “Centered image with caption” will be one type with two fields. Click “Add field,” and add a new field of type “Text (plain)”. Label this field “Caption,” and click “Save and continue.” Some longer captions might need to exceed the default 255-character limit, so change the maximum length for this field to 500. Keep the allowed number of values at “Limited” and 1, and save the settings. The following caption settings defaults are all fine, so save the settings on that page as well.

Now our new Paragraphs type has all of the fields it needs, so click the “Manage display” tab so that we can remove the field labels, which are unnecessary in this case. Select “Hidden” under the “Label” column for both fields, and click “Save.” If the two fields were out of order, we would rearrange them so that the caption field comes after the image field, but since we added the caption field last, it should already be positioned after the image field, just as we want it to be.

Now we’ll add the new type to our Article content type. Navigate to Structure > Content types, and click “Manage fields” for Article. As was the case when we added our first “Centered image” Paragraphs type to the content type, we will add this new Paragraphs type within our custom Body field rather than adding a new field altogether.

So, on the “Manage fields” page for Article, click “Edit” for Body. Scroll to the bottom of the page, and check the box next to “Centered image with caption” to make that type available within this Body field. Click “Save settings.” Now this new Paragraphs type will be available for those who are adding Articles to the site.

Let’s go ahead and create a new article using this field, and then we’ll add our styling to control its display. Navigate to the Content page, click “Add content,” and click “Article.” Let’s call this article “Learning to Play an Instrument May Improve Your Life.” Click “Add Body text” to begin adding some text to the article. Enter a paragraph or two of text into this field. Then, below the Body text field, click the dropdown arrow next to “Add Body text,” and select the newly available “Add Centered image with caption” option. Notice that we are now presented with two fields for data input, as we should expect—the “Centered image” and “Caption” fields that belong to this Paragraphs type. Upload any image into the image field and provide some alternative text. Then type, “The Les Paul is one of the most legendary guitars in rock and roll.”

Now we’ll add some of the rest of the article’s text after the image and caption. Beneath the image and caption Paragraphs type, click “Add Body text” once again. Add another paragraph or two of text. Finally, click “Save and publish.”

Currently, the display of our “Centered image and caption” should be half correct. Since we reused the previous “Centered image” field, the image itself should already be centered just as it was for the previous field that consisted solely of an image to be centered. The caption text, of course, does not have any CSS rules yet, so it will appear left-aligned and look just liken the text of the rest of the article. So, we need to add some rules to our theme to style this caption text.

This time, when writing our CSS, we will target the entire “Centered image with caption” Paragraphs type and then drill down to the caption field within that class, rather than targeting the caption text independent of its container, as we previously did with the centered image. We’ll take this approach because we might want to reuse this caption text field elsewhere, and it is likely that in some cases we will want it styled differently (such as being aligned left or right rather than centered) from how it is in this particular Paragraphs type.

We’ll center our caption text because its corresponding image is centered, and to provide a visual differentiation between this text and the text of the article, we’ll make it bold (italics would also provide that effect). Add the following lines of code to your stylesheet, and save your changes:

Then, to see our changes on the site, navigate to Configuration > Performance, and clear all caches. Go back and refresh the recently created article, and you should see the new styling rules in effect. The caption text should now be bold and centered below the image.

We can of course apply some styling to this Paragraphs type as a whole. One reason to do this would be to separate the image/caption element from the surrounding text and to make it visually clear that it should be viewed as a single unit. Add the following code to your stylesheet, and save your changes:

Now clear your site’s cache once again, and refresh the article page. The image and caption should look mostly the same; however, now the entire image/caption unit is surrounded by a gray border and has small margins around the top and bottom. We could do more to improve the aesthetics here (and the border is likely not necessary), but this demonstrates our ability to provide styling for individual components of Paragraphs types as well as Paragraphs types as a whole.

Now if a non-technical user is adding content to the site and wants to include a large, centered image with a caption, all they have to do is select this Paragraphs field while editing the article, upload an image, and enter the text into the caption field. The formatting will be automatically applied.

Using Entire Nodes in the Paragraphs Module

At this point, we’ve seen some examples of the basic uses of Paragraphs. Now we’ll tackle a slightly more advanced example: using Paragraphs to place an entire node inside the body of a piece of content. One use case for this would be to place a related but standalone piece of supplementary information inside one of your articles (similar to something like a “Did You Know?” section that you might see accompanying a magazine article).

For our example, we’ll imagine we want to have the option to add what we’ll call “Info boxes” to our articles, and we’ll do so by placing a short piece of content entitled “A Short History of the Harp” within our previously created article about learning to play an instrument.

First, we need to create a content type for these “info boxes.” Navigate to Structure > Content types, and click “Add content type.” We’ll give this content type the name “Info box.” For the description, write “Short pieces of information used to supplement articles.” Click the “Display settings” tab, and uncheck “Display author and date information” because we don’t want author and date information showing up within our Info box content. All of the rest of the default settings on this page should be fine. Click “Save and manage fields.”

On the “Manage fields” page, we already have a basic long-form “Body” field, and this is all we want for this content type, since all pieces of content of this type should be short and simple. No changes are therefore necessary here. Click “Add field.”

Now that our content type has been created, we need to create the Paragraphs type that will reference it. Navigate to Structure > Paragraphs types, and click “Add paragraphs type.” Give this type the label “Info box.” On the “Manage fields” page, click “Add field,” and beneath “Add a new field,” select “Content,” found under the “Reference” header. For the label, write “Info box,” and save. All defaults are fine on the next page, so click “Save field settings” there.

On the next settings page, scroll down until you see the “Reference type” settings. Since we want to use this Paragraphs type to reference and display Info box nodes, check the box next to “Info box” beneath the “Content types” header. You can leave “Sort by” set to “None” because the field will autofill based on what we type and is not a list of all content of this type. Click “Save settings.”

Back on the “Manage fields” page, click the “Manage display” tab. As we’ve been doing so far, we’ll remove the label, so select “Hidden” under the label column for the Info box field. Then, because we want to display the entire Info box node whenever we choose to include an Info box in one of our articles, we need to select “Rendered entity” in the column labeled “Format.” Click “Save.”

It’s time to make this Paragraphs type available to our Article content type. Navigate to Structure > Content types, and click the “Manage fields” button for the Article content type. As we’ve been doing, click “Edit” for the Body field. Scroll down and check the box next to “Info box” under the “Paragraph types” header. Save your settings.

With the structure side of this implementation complete, we’ll now create some content to test it out. We’ll start by adding our site’s first “Info box.” Navigate to the “Content” page, and click “Add content.” Choose Info box. For the title, enter “A Short History of the Harp.” Enter two or three paragraphs of text into the Body field, and click “Save and publish.”

At this point we will divert briefly from Paragraphs. Currently the home page of our site lists all of our articles and info boxes, but we don’t want the latter to appear on the homepage; we want them only placed within other articles. So, let’s quickly edit the view for our homepage to exclude these pieces of content. You can either click the “Edit view” icon (which is displayed as a pencil icon) on the top right corner of the view area of the homepage, or navigate to Structure > Views, and edit the “Frontpage” view.

On the view’s settings page, next to the “Filter criteria” header, click “Add.” Select “Content type,” and then click “Apply (all displays).” For the filter criterion, select “Is not one of” under “Operator,” and under “Content types,” check “Info box.” Then click “Apply (all displays).” This, as you probably know, will exclude all content of type “Info box” from the Frontpage view. Back at the view’s settings page, click “Save.” Now when you view the homepage of your site, you will no longer see the “A Short History of the Harp” info box.

Now we’ll add our Info box to the “Learning to Play an Instrument” article. Scroll down to the bottom of the Body Paragraphs field (the larger field encompassing all individual Paragraphs fields), click the dropdown arrow next to “Add Body text,” and select “Add Info box.” You can type in any piece of the title of your “A Short History of the Harp” Info box node into the autofill field, and that Info box should then be displayed as an option. Select it to include that Info box in the body of this article.

With the Info box now included in our Body, we need to place it where we want it. Drag and place it after the first Body text field and before the Centered image field. With this new organization, we should probably have some text between the Info box and the Centered image. To simulate doing this in a real-world scenario, we’ll cut some of our current text and paste it into a new Body text field, as opposed to arbitrarily adding text to the article.

So that we have a field to paste our new text in, go ahead and click the “Add Body text” button beneath all of the Paragraphs fields. Then scroll to the first Body text field and select and cut one or two paragraphs of text from the field (making sure to leave at least some text in the field), and paste the cut text into the newly created (currently empty) Body text field. Once this is done, drag the new Body text field, and place it after the Info box field and before the Centered image field.

Click “Save and keep published,” and upon viewing the article, you’ll see that the referenced Info box node is displayed in its entirety within the larger article. (If all you see is the title of the Info box node, that means you forgot to select “Rendered entity” in the Format column Paragraph type’s “Manage Display” page.) As it currently is, the lack of styling on the referenced Info box is likely to be confusing to most viewers. We won’t go through the task of applying additional CSS to these Info box references because we already now how to do that, but it is important to note that, in practice, these references should be styled to appear significantly different from the containing article. It should be made extremely clear—through the use of some combination of background color, borders, text size, and font family—that the information contained in the Info box is not part of containing article and is simply supplementary information.

Using Field Layout with Paragraphs Types

Just as the Field Layout module can be used to control the layout of nodes, it can also be used to control the layout of individual Paragraphs types. In some cases, this can be a viable alternative to controlling the layout via CSS, depending on the situation and on the developer’s (your) preference.

Important: As of this writing, Field Layout is an experimental module. As such, any implementation of Field Layout should be considered a risk. If you do decide to use the module during its experimental phase, it should be tested extremely thoroughly on a development site before being used on a production site. Otherwise, play it safe by considering this information useful for future situations after the module has graduated into non-experimental core.

Because Field Layout is a core module, it does not need to be downloaded. So, begin by navigating to your site’s Extend page, selecting the Field Layout and Layout Discovery (a dependency) modules, and clicking “Install.” Then, if prompted, click “Continue.”

Let’s use Field Layout to control the layout of a new Paragraphs type in which we create a two-column unit of “Pros and cons” information. Navigate to Structure > Paragraphs types, and add a new Paragraphs type. Give it the label “Pros and cons,” and add a field. For this field, select “Text (formatted, long),” and give this first field the label “Pros”. Save and continue, and keep all of the default settings through the next two pages until you are back at the “Manage fields” page. Add another field with a Text (formatted, long) input type, and label this one “Cons”. Save, and continue through the subsequent settings pages, once again keeping all default settings.

Once you’re back at the “Manage fields” page, click the “Manage display” tab. This time we will keep the label (positioned above, as is default) for each field so that when visitors are reading them, they know that we are listing pros and cons accordingly. If we look below the listed fields, we will see a new group of settings called “Layout settings.” This is made available by the Field Layout module. Click to expand these settings.

We have a handful of options here, and for our Pros and cons lists, we’ll select “Two column.” Then click “Save,” and you’ll be taken back to the “Manage display” page. Now we have additional layout areas to place our fields in for this Paragraphs type. In total, we have “Top” for the area spanning the width of the content space above our columns, “First” for the left column, “Second” for the right column, “Bottom” for the area spanning the width of our content space below the columns, and “Disabled” for fields we do not want to display. Drag and drop your Pros and Cons fields so that Pros is in the “First” column and Cons is in the “Second” column, and save.

Now, as usual, we need to add the new Paragraphs type to our Article content type. Navigate to Structure > Content types, and click “Manage fields” for Article. Edit the Body field, scroll to the bottom of that field’s settings, and check the box next to “Pros and cons” to add that Paragraphs type to this custom Body field. Then save.

Now we’re ready to begin using this “Pros and cons” Paragraphs type. Let’s use it in a new article. Create a new article called “Swimming Is a Great Way to Stay in Shape.” Add two or so paragraphs of Body text to this article. Then click the dropdown arrow next to the “Add Body text” button, and select “Add Pros and cons.” Notice that this Paragraphs type has two long-form text areas to fill in, one labeled “Pros” and the other labeled “Cons.” Enter text for five or so pros, each separated by a simple line break (in other words, separated by pressing the Enter key). If you’d like, you can alternatively make these 5 bullet points. Do the same in the Cons field.

If you’d like to fill out this article a bit more, you can then add another field of Body text below the Pros and cons field.

Click “Save and publish.”

Viewing the article, you’ll see your comparison of pros and cons listed, with the pros listed in a left-hand column and the cons listed next to them in a right-hand column. You should also see your “Pros” and “Cons” labels above each list.

In most cases you would likely want to apply some CSS to these elements via your stylesheet. Again, we won’t take the time do so here because you have seen how that works. Some styling suggestions might be to add a vertical border between the lists of pros and cons (and potentially borders surrounding the entire Paragraphs type) and to make the “Pros” and “Cons” labels more prominent. Additionally, you may consider going back and editing the Pros and cons Paragraphs type to add a title field which can be displayed in the “Top” area above both columns. In this case, such a field might read, “Some Pros and Cons of Swimming for Exercise.”

Permissions for the Paragraphs Module

At this point, we’ve set up all of our Paragraphs types and integrated them the way we want, aside from some styling we would need to apply to the Info box and Pros and cons types. However, we have not yet configured any permissions pertaining to Paragraphs. This is an important step. Currently, if an anonymous visitor were to view our site, they would not be able to see any of the content entered via Paragraphs types (which is all of the content we have entered in this tutorial) because by default, only administrators have permission to view such content. You can see this for yourself by logging out of the site in its current state and trying to view the content. You will see the titles of articles but none of the body content.

Additionally, we want to have a “Content creator” (or similar) role on the site so that not everyone adding content has full access to all administrative configuration on the site. These users need permission not only to view Paragraphs content but to create, edit, and delete it.

We’ll start by giving everyone permission to view Paragraphs content. Navigate to your site’s People page, and click on the “Permissions” tab. Scroll down until you see the “Paragraphs Type Permissions” section. Beneath this header, find “Body text: View content,” and check the boxes for Anonymous User and Authenticated User. Do the same for the “View content” permission of all the rest of the Paragraphs types we created: Centered image, Centered image with caption, Info box, and Pros and cons. Then click “Save permissions.” At this point, all users can view all Paragraphs content. Feel free to log out and view the site as an anonymous visitor to confirm.

Now to create a new role for those who will be adding and editing content on our site. Navigate to People, click the “Roles” tab, and click “Add role.” Call this role “Content creator.” Back on the Roles page, click the dropdown arrow next to the Content creator role, and select “Edit permissions.” There are quite a few permissions we will need to give users of this role. Some of these are unrelated to Paragraphs, but we’re including them anyway to mimic a real-world scenario. Additionally, it will be difficult to test the new role reliably if it does not have all the permissions it would have in practice. Note also that we’re granting these permissions assuming that our content creators are all working in-house. That is, we don’t have large numbers of technically authenticated but still pseudo-anonymous users creating content on our site, so we do feel we can safely grant these users permission to do things like use the Full HTML text format, which in other cases would cause some security concerns.

Here is the list of permissions the Content creator role should be given:

A few notes about some of the permissions we did and did not grant here: We did not grant permission to administer Paragraphs types because we do not want them creating new Paragraphs types or changing the way that existing Paragraphs types work. They will simply be entering information using the Paragraphs types that we as the developers have created for them. Additionally, though in some cases it is wise to avoid granting non-administrative roles the ability to delete content (in most cases, it is sufficient that they can unpublish content, and deleting content makes it nonrecoverable), we do need to give them permission to delete Paragraphs types content under “Paragraphs Type Permissions.” This is necessary because if they are unable to delete this type of content, and if they accidentally click to add any content via Paragraphs type that they do not actually need in a given article, there will be no way for them to remove that unit of content from the article. It would be similar to disallowing use of the Backspace key.

To test our new permissions, we’ll create a new user of the Content creator role and go through the process of adding a new article as that user. Navigate to People, and click “Add user.” Create a user named Mary (you can skip the email address), with a password you can easily remember. Make sure the user’s status is marked as “Active,” and, most importantly, make sure you check the “Content creator” role for this user. Then click “Create new account.”

Log out, and log back in as Mary. If permissions were assigned correctly, you should have access to the admin toolbar. Click “Manage” in the toolbar if you do not see the administrative links (“Content,” “Structure,” etc.). Then navigate to Content, and add a new piece of content of type Article. You can title this article “Broccoli Is Great for You.” Add a Body text field, and enter some text. You should then go through and try to add content of each Paragraphs type we have created: Centered image, Centered image with caption, Info box, and Pros and cons. After doing so, save the article, and view it. This full process should be the same as when we did so as a site administrator, and you should then be able to view all content with no problem.

If you do not have the option to add one or more of these, or if you encounter other problems while trying to do so, you probably missed one or more of the necessary permissions when granting them to the Content creator role. Go back to the permissions for Content creator, and make sure you gave them all of the permissions as listed above—especially those under the “Paragraphs Type Permissions” header.

Once you’ve confirmed that you can create and view content using Paragraphs content as a Content creator, you’ve completed this tutorial. At this point, you should have an understanding of why and how to use the Paragraphs module. To recap, the usefulness of this module lies in its ability for us to define special in-article content components, such as boxes of supplementary information and centered images with captions, without forcing content creators to try styling things on their own. With Paragraphs, they are simply asked to provide the content for these parts of our articles, and we as the developers can write site-wide rules (using CSS) for how that content should be displayed. This makes the content creation process easier for non-technical users, and it makes the appearance such content more consistent for technical and non-technical users alike.

About the author

Steve is the founder of OSTraining. Originally from the UK, he now lives in Sarasota in the USA. Steve's work straddles the line between teaching and web development.

By default, a Drupal 8 user account collects only very basic information about the user.

And, most of that information is not visible to visitors or other users on the site.

Fortunately, Drupal makes it easy to modify and expand this profile so that people can add useful information about themselves such as their real name (versus a username), address, employer, URLs, biography, and more.

If you're new to how Drupal handles users, read this tutorial before starting. In this tutorial, I'm going how to create expanded user profiles for your Drupal users.

First, let's add some fields to your user profiles. This allows users to provide more information about themselves.

Go to "Configuration", "People", "Account settings", and then "Manage fields". You can now see a screen which looks the one below:

Let's add the following Text (plain) fields:

First Name. Set the "Maximum length" to 50 characters.

Last Name. Set the "Maximum length" to 50 characters.

Next, add the following Link fields:

LinkedIn

Facebook

Personal Website

Go to the "Manage display" tab and arrange the new fields in the order you want them to show to site visitors.

Go to "People" and "Permissions".

Give the "View user information" permission to the Anonymous and Authenticated users.

Now, go and see those user profile fields that you just created:

Click your user name to go to "My account" in the black menu bar at the top.

Click the "Edit profile" tab.

Scroll down and you can use all the fields that you just created.

Fill in the fields.

Save your data and click the "View" tab to see your profile:

Now, see how these fields appear to your site’s users. For many users, this user profile editing area should look similar, but slightly different:

You can use the Masquerade module to see the site as the user would. If you're not familiar with Masquerade, read this tutorial.

Click the article writer name to go to "My account".

Click the "Edit profile" tab and see what the user sees:

Finally, see how this appears to a new user:

Log out or visit your site in another browser.

Visit http://[your_web_address]/user/register

The registration screen should show the default Drupal fields, plus your new fields:

If you want to remove any fields from the registration area, you can hide them by going to "Configuration, "People", "Account settings", and then "Manage form display".

Want to Learn More?

This tutorial was an extract from Drupal 8 Explained, the best-selling guide to Drupal 8. Grab a copy today to learn all the fundamentals of Drupal 8.

About the author

Steve is the founder of OSTraining. Originally from the UK, he now lives in Sarasota in the USA. Steve's work straddles the line between teaching and web development.

Every year, Dries Buytaert gives his keynote address, known as the "Driesnote".

However, something was different this year.

In the past, Drupal's release cycles were vague and so the Driesnotes often focused of proposals and ideas. "It will be ready when it's ready" was a favorite quote.

That changes this year. In Nashville, Dries presented a detailed roadmap for where Drupal is headed. There has been an official roadmap page on Drupal.org since 2016, but it never had any real information. Now it full of information about what's coming to Drupal 8.

I'm going to give you a quick-start guide to every item the roadmap presented at DrupalCon, starting with the next release: Drupal 8.6 in September. This image belows show the roadmap from the Driesnote:

A Drupal 8 demo: This is also known as the Out-of-the-Box initiative. Here's a quote explaining the goal of this project: "Installing Drupal currently gives you a mostly empty box. There is no demo content nor much preconfigured functionality. This makes for a weak first impression and makes it hard for the evaluator to connect the dots and find out what Drupal can do for them. The Out of the Box Experience initiative (OOTB) aims to improve this situation. The goal is to add sample content presented in a well designed theme, presented as a food magazine. Using recipes and feature articles this example site will make Drupal look much better right from the start and help evaluators explore core Drupal concepts like content types, fields, blocks, views, taxonomy, etc." Click here to see the issue for this new demo content.

YouTube support: This is part of the new Media features in Drupal 8. This basic Media module is already in the Drupal 8 core, but it's not very useful yet. The plan is that you will be able to add YouTube embeds to your site, alongside the more basic Media types: Images and Files.

Drupal 7 to Drupal 8 migration path: The migration path to Drupal 8 will finally become stable ... three years after the launch of Drupal 8. That's way too late, but at least it's almost done. In fact, if you read the official issue queue, the migration tools are stable now: "So the only thing blocking it from going stable at this point is that it depends on an unstable module. Meaning, migrate_drupal. Otherwise, the UI is now as stable should be considered Un-Officially stable!!! Go out and migrate using it." The main limitation at the moment seems to be with multi-lingual sites.

Support for JSON API specification: I'm not quite sure why this item made the list, as it's a more minor change. This update allows Drupal to show which version of the JSON API specs is currently supported.

Media Library (experimental): Currently Drupal 8 does not have a browseable media library. You need to know the name of the file in order to find any media that you uploaded previously. Go to 44:50 of the Driesnote video and you'll see a preview of the new library. Click here to see the full Media Library issue.

What's planned for Drupal 8.7?

Full-site previews: This is a really interesting new feature which introduces the ability to preview and stage changes. Drupal will have the option to create a new version of a page. You can work on this page in private, and then push it live. Drupal will call these "Workspaces", so you'll have a Staging and a Production workspace. This would be an ideal solution if you wanted to prepare landing pages to launch on a certain date, or get approval for updates to existing pages. Click here to read more about this initiative.

Auto-generated API docs: It's generally agreed the Drupal 8 API documentation is lacking. There's talk of a new project to overhaul all the documentation, but the API docs could be automatically generated as with Symfony.

Redesigned Javascript admin interface (experimental): Scroll down and watch from about 43:00 of the Driesnote for an introduction to this topic. The image below shows what the redesigned Drupal 8 could look like. You can find more images on this Drupal.org issue. This is part of a larger initiative called "Modernize Drupal's Javascript". It is 10 years now since Drupal added jQuery to the core, and it's now time to move on to alternatives such as React. The very ambitious goal for Drupal 8.7 is to "create an alternative admin experience for Drupal as a single-page React application".

What's on the Wishlist?

Automatic updates: There is an official initiative working on this. "Updating a Drupal site can be difficult, time-consuming, and expensive. While implementing an automatic updates system is a difficult problem, and not without its risks, it is a problem that has been solved by other platforms, and that Drupal can address." We wrote about the need for this in 2014. The short version of this after Drupalgeddeon 1 and Drupalgeddeon 2, Drupal can't afford to leave so many sites unpatched. Blaming the site owners is not a good strategy.

In this blog post, I'll give you an introduction to three of the main new features you can start using in 8.5.

New Feature #1. Layout Builder

To me, the most exciting feature in Drupal 8.5 is the Layout Builder. No matter what you personally think about Page Builders, vast sections of the website-building world loves them. You can talk about other Drupal features headless frontends and continuous integration tools all day, but drag-and-drop Page Builders is what many end-users care about.

In Drupal terms, the best way to think about this could be, "Panels is now in core".

After enabling these modules, go to "Structure" then "Manage display".

You'll see that the fields have been replaced by a "Manage layout" button.

After clicking this button, you'll be taken to the front of your site. Here you'll see a Panels-style page builder tool. You can drag-and-drop fields and other items between different regions of the page.

If you click the "Add Section" button you'll have a choice of layouts in the right sidebar:

Inside each section of the layout, you can choose from a wide variety of Drupal items to place on the page. Did I mention that this was "Panel in core"? In fact, at first glance, this appears to be far better. The user interface is certainly a big improvement over Panels.

New Feature #2: Settings Tray

This is an experimental module that has gone stable in Drupal 8.5.

After enabling the module, click the blue "Edit" button in the top-left corner of the admin toolbar.

Now you'll see a "Quick edit" link next to all your blocks. In previous versions, you only had the "Configure block" link.

If you click "Quick edit" you'll see the block configuration options in the sidebar of your site. This is the "Settings Tray" from the module title. This should make it easier to configure blocks without needing two switch back-and-forth between multiple pages.

New Feature #3: The Media module

The Media module landed in the core 6 months ago with Drupal 8.4. However, in 8.4 the Media module was completely hidden. In 8.5, the Media module is stable and visible but it is not enabled by default.

When you add a new field, there will be a "Media" option, alongside the old "Image" and "File" types:

When you select the settings for each field, you can choose which media types are acceptable:

The usability of this new Media workflow is not perfect. When a content creator sees a Media field, they're going to be sent to a new screen to add their media. After navigating through the other screen, they can then come back here to choose their newly uploaded files.

At the moment, there's no browseable media library. Users will need to search using the file's title:

All in all, the Media in 8.5 shows progress, but has real limitations. The old Image and File field types are still the default option and I suspect most sites will continue to use the old field types.

Honestly, the non-default status, plus some usability issues, left me underwhelmed. We may be looking at Drupal 8.6 before use of the Media module really starts to take off.

Summary

Drupal 8.5 is shaping up to be an exciting release. I didn't even touch on a host of other improvements such as the Content Moderation features finally going stable, and BigPipe being enabled by default.

Did you see any features that you're really looking forward to in 8.5?

About the author

Steve is the founder of OSTraining. Originally from the UK, he now lives in Sarasota in the USA. Steve's work straddles the line between teaching and web development.

When you are adding Views, you may have seen an extra option called "Delta".

Several students have asked us about the purpose of this field, because it wasn't clear.

The Delta option is available throughout the site, but ordinary users are most likely to encounter it inside Views. Here's how the "Delta" options appear in Views:

And here's how the Delta fields appear if you add them to your view. It's really not something you're likely to want to display.

So what does "Delta" mean?

"Delta" only appears fields which have multiple value. "Delta" refers to the order of the values:

0 is the first item

1 is the second item

2 is the third item etc.

You can use Delta to restrict the results you show. For example, you might only want to show the first and third items stored in a field.

The Delta option isn't available only in Views. With the "Image Delta Formatter" module, you can use Delta to display fields. In example below, we're using "0,2" to only show the first and third images:

If you go to the database and find the table for a field with multiple values, you'll see that the Delta is stored here:

Let's take another example. Imagine that you have a Date field set up in Drupal 7, and you allow people to choose to repeat the date.

In this situation, every possible repeating date will be stored in the database, with it's own Delta. The use of the "Delta" fields allows you choose only some of the many possible dates.

About the author

Steve is the founder of OSTraining. Originally from the UK, he now lives in Sarasota in the USA. Steve's work straddles the line between teaching and web development.

The Drupal team are also looking to make progress with at least 3 other experimental modules:

Migrate / Migrate UI: Get as close to stable as possible.

Place Block: This won't go stable but may become a patch to the Block module for 8.5.

Settings Tray: Move from alpha to beta.

This is a lot of progress for one release of Drupal, but it isn't even the most interesting part of this upcoming release.

Media in Drupal 8.4

The most intriguing part of 8.4 is probably Media. Better media handling the most commonly requested feature in all our Drupal training sessions. Here's what the official Media initative has to say:

While Drupal core includes basic file and image support, it is a far cry from what a modern web system should support out of the box for media handling. External media cannot be embedded easily in core and media cannot be reused.

So what will the Media module do? That part is still a work-in-progress, particularly for 8.4. Yes, the main module is in the core but there's more work to be done. The file field and image field widgets need to be converted to use the Media module, and a lot more of the Media ecosystem needs to be built out. There's a chance that the main UI features won't be available until 8.5 arrives in April next year.

If you want to see what the final version of Media will look like, it's worth trying the Lightning distribution. This is a project from Acquia and is designed to bring core features to market early. Lightning allows Acquia to move more quickly than the Drupal core, putting new features into production and then contributing them back. Click here to install Lightning at SimplyTest.me.

When using Lightning, content creators get access to a searchable media library

You can embed videos and save them to your media library:

You can embed tweets and save them to your media library:

This is a reusable system and can also be applied to documents, audio files, Instagram posts, Slideshare documents and any other type of media you want to use with Drupal.

All-in-all, this will be a big step forward for Drupal and will make the platform much more user-friendly.

There are a couple of other notable things about the Media module:

This module wasn't even in the Drupal 8.3 core. Instead it has skipped skipped the experimental phase and jumped straight to "stable" status. Perhaps this is becase Media module in 8.4 is a direct copy of the Media Entity contrib module.

The Drupal team will hide the Media module. You won't be able disable or enable the module, but developers can rely on it.

Summmary

This is a very early look at Drupal 8.4 and much can change between now and the final release in October.

However, 8.4 is currently shaping up to the most interesting update since 8.0.

About the author

Steve is the founder of OSTraining. Originally from the UK, he now lives in Sarasota in the USA. Steve's work straddles the line between teaching and web development.

Now you can go back to your Drupal site and start setting up the slideshow:

Go to Structure > Content types.

Make sure you have a content type with an Image field attached:

Step #2. Create the view

Now we're going to use Views to create our slideshow:

Go to Structure > Views > Add new view.

Enter a "View name".

Click "Create a block".

For "Display format", choose "Slideshow".

Click "Save and edit".

On the left-hand side, look for the "Fields" area. Only "Content: Title" will be showing.

Click "Add".

Search for your image field and choose that field.

Click "Add and configure fields"

Click "Apply"

Scroll down to the Preview area at the bottom of the page and you will see that the image has been added.

Click "Save" to finish creating your View.

Step #3. Publish your slideshow block

Now let's publish our View so that people can see it:

Go to Structure > Block layout.

Click "Demonstrate block regions".

Choose the region you want to use for your slideshow. In my example, I'll use "Content":

Find the block region you want to use and click "Place block":

Find the block that you just created and click "Place block":

Under "Pages", choose which pages you want the slideshow to appear on:

Click "Save block".

If your chosen block region has multiple regions, make sure your block is correctly placed. In this case, I want it at the top:

Click "Save blocks".

Go and see your slideshow published on your site:

Step #4. Create image styles for your slideshow

At the moment our images are all different sizes and don't fit into the block region. Let's create an image style to ensure that all the images are the correct size.

Go to Configuration > Image styles > Add Image style.

Enter an "Image style name".

Enter a "Machine readable name".

Click "Create new style".

Choose an image effect. In my example, Resize will guarantee that all the images are the correct size:

Choose a Width and Height for your images. This will depend on the size of the block region you've chosen.

Click "Update effect".

Go back to edit your View:

Under "Fields", click on your image field to edit it.

Set "Image style" to the style you just created.

Save your view and visit the front of your site. Your slideshow should be working:

Pro tip: if you need help to make your slideshow responsive, enable the "Responsive images" module in the Drupal core. That will provide more image style options under Configuration > Responsive image styles.

Step #5. Add controls to your slideshow

Finally, let's add some controls so that our slideshow is easier for visitors to navigate:

Go back to edit your view again.

Under Format, click "Settings" next to Slideshow".

You'll now be able to add controls to your slideshow, including Previous / Next buttons, a counter and a pager:

About the author

Steve is the founder of OSTraining. Originally from the UK, he now lives in Sarasota in the USA. Steve's work straddles the line between teaching and web development.

One of the most common hurdles that Drupal beginners face is learning to navigate all the modules available on Drupal.org.

With over 38,000 modules, choosing which ones to use can be a daunting experience.

One answer is often to use a distribution.

Building your own e-commerce, intranet or a social networking site in Drupal can be intimidating. Imagine how much easier it would be if an expert had found all the best modules for your purpose and had combined them into one package. Imagine that you could download and install that package as easily as a normal copy of Drupal. That's what distributions can do for you.

Lightning: Acquia's version of Drupal that moves faster than core, and ships cool features early.

aGovGov: A Drupal package specificially designed for the needs of the Australian goverment.

Installing a Drupal Distribution

In most cases, installing a Drupal distribution will be exactly the same as installing a plain copy of Drupal. We're going to use the example of Drupal Commerce to walk you through installing a typical distribution. You can download this package from http://drupal.org/project/commerce_kickstart.

The main difference during installation is that you will be given the option of choosing an installation profile during install.

The installation profile might also offer you the choice of some additional features. In the case of Drupal Commerce, you have the option of installing sample content:

The File Structure of Distributions

When you install a distribution, you'll see the phrase "installation profile" used. This can cause confusion, so let's explain the difference.

A distribution is not an installation profile. The installation profile is underneath the distribution and site in the /profiles/ folder.

Take a look at the image below which is a screenshot of the Drupal Commerce distribution for Drupal 7. All of the extra modules and themes are in the /profiles/ folder. They are not in the /sites/all/modules/ folder as you would expect.

Installation profile = all of the files in /profiles/commerce_kickstart/

Distribution = all of the files into the entire package, not just in the /profiles/ folder.

The same is true with distributions in Drupal 8. The image below shows the files for the Lightning distribution:

Notes of Caution on Using Distributions

Although distributions can be time-savers, it's worth being aware of some potential drawbacks:

Not Drupal 8 ready. Because of their complexity, many distributions are still only for Drupal 7.

Confusing for beginners. You do need some knowledge of Drupal before using them, otherwise you'll find yourself trying to reverse engineer some fairly advanced features.

Learning curve. It's not unusual for a Drupal distribution to have a radically different admin area design. The advantage is that the admin area is often good fit for the purpose of the distribution. For example, the image below shows Open Atrium which was designed for intranets. This admin area design works much more effectively for an intranet than the default Drupal design. The disadvantage is that distributions often need custom training. For example, normal books and training materials won't apply to Open Atrium so it had its own books and materials.

Evaluating Drupal: Distributions are easier to setup and you can see real life examples of what Drupal can do.

Demoing Drupal: Before building a site for someone it can be useful to show them examples of how Drupal can be configured.

Learning Drupal: You can analyse real, working features.

Quickly Building a Site: If you're building a site similar to one provided by a distribution, it makes sense to start with a distribution. If you're changing too much though, it may make more sense to just start with stock Drupal and build from there, rather than try to undo and change what was setup for you.

About the author

Steve is the founder of OSTraining. Originally from the UK, he now lives in Sarasota in the USA. Steve's work straddles the line between teaching and web development.

There is one module that makes designing for Drupal 7 much, much easier: Theme Developer.

You can think of Theme Developer as a Drupal-specific version of Firebug or Chrome Developer Tools. Using Theme developer you can click on any element of your Drupal site and get a breakdown of how it was built.

Theme Developer has some downsides: it's not been updated in a while, and (like anything related to the Devel module) shouldn't be used on live sites. But, it can still be a useful tool for Drupal 7 themers.

In the bottom-left corner of the screen, you will see a small "Themer Info" area:

Check this box:

Up in the top-right corner of the site you'll see a larger black box:

The bar does a pretty good job of explaining what to do! Just like Firebug, or Chrome Dev Tools, you can inspect areas of your Drupal site.

Here's what happens when you click on a page element: you'll see a red box around that particular element.

The theme developer box will now show information about your chosen page element:

Here are some of the details you'll see:

Template called: the name of the file which is controlling the layout of this element

File used: the location of the file controlling the layout

Candidate template files: if you'd like to create an override for this part of the page, these are suggested file names.

Preprocess functions: These functions connect what happens in the module code to what gets sent to the theme

If you want to use the candidate template files, easiest thing to do is copy the "Template called" file, rename it and save it in your template folder. This is what the files mentioned in this example would do:

block-user-1.tpl.php ... if you create this file, it will only provide a template for this particular block

block-user.tpl.php ... if you create this file, it will only provide a template for this user blocks

block-left.tpl.php ... if you create this file, it will only provide a template for blocks in the left div.

block.tpl.php ...if you create this file, it will provide a template for all blocks

In this tutorial, we'll show you how to add a "Printer-friendly version" button to your Drupal articles. The main reason you'd want to do this is a courtesy for your readers. Many still print things they read online and you don't want them to waste that expensive printer ink just to print your logo and theme as well as the article.

Without this solution, you'd likely need to create a separate CSS file with styles specifically for the printed page. Fortunately, the "Printer, email and PDF versions" Drupal community module makes this much easier. It will automatically create a printer-friendly version of each article

It allows you to use small placeholders to automatically complete tasks.

To take a simple example, if you put [site:name] on your site, it will be replaced by the actual name of your site. To take a more complicated example, you can use Token together with the Pathauto module to automatically create URL patterns for your whole site.

However, Token needs other modules to work. If you want to use Token inside fields, there are several options but one of the most reliable is a module called Token Filter.

If you have Token and Token Filter enabled, here's how to add tokens to your fields:

Go to Configuration > Text formats

Click "Configure" next to the text format you want to use. Be careful with this - do not choose a text format that your regular site visitors will be able to use.

Check the "Replace tokens" box, as in the image below.

Click "Save Configuration".

Go to Structure > Content types > Manage fields

Click "Edit" next to a field

There will be a "Browse available tokens" option.

You can use these tokens to set up default values for your fields:

It's worth noting that some fields types use the "Plain text" format, by default. So, make sure you have token support available for Plain text if needed.

However, be careful with this. Remember that you don't want to give token access to anyone on your site. In the wrong hands, tokens could expose private information.

About the author

Steve is the founder of OSTraining. Originally from the UK, he now lives in Sarasota in the USA. Steve's work straddles the line between teaching and web development.

Drupal 8 introduced an interesting new approach called "experimental modules".

These experimental modules are included in the Drupal core, and have inspired several questions from OSTraining members. What are these experimental modules, and is it safe to use then?

Yes, experimental modules are shipped with the Drupal 8 core, but they are not yet fully supported. Here's the official explanation:

Experimental modules allow core contributors to iterate quickly on functionality that may be supported in an upcoming minor release and receive feedback, without needing to conform to the rigorous requirements for production versions of Drupal core. Like other features, new experimental modules can only be added in minor releases, but unlike other features, they may change between patch releases while they are still experimental.

Officially, the experimental modules are only for testing:

Experimental modules allow site builders and contributed project authors to test out functionality that might eventually be included as a stable part of Drupal core. Use them at your own risk. See the experimental module version information below to help you evaluate whether you should test the module. Also keep in mind that the experimental module might be removed from Drupal core if it turns out to not be a good fit.

If you install an experimental module, you'll see a message like this:

Is it unusual to have features like this, half-in and half-out of the core? No, not entirely. For example, WordPress used "Features as a Plugin" which resulted in several non-core plugins being officially supported while they were tested and developed.

To understand the thinking and planning behind experimental modules, I highly recommend this presentation by Gabor Hojtsy:

What features are included as experimental modules?

More and more important features are being developed using the experimental route. Here are the experimental modules in Drupal 8.0, released in November 2015:

And here are the experimental modules in Drupal 8.3, released early in 2017. As you can see, the number of experimental modules has more than doubled:

Currently, only the Big Pipe module has graduated from being an experimental module, to being an official module, but I expect more to make the leap when Drupal 8.4 is released in late 2017.

Only for testing purposes?

Despite the official line, the "only for testing" line is starting to get blurry.

For example, if you install the new version of Display Suite, you will get a message saying you must enable the Layout Discovery module. However, the message also says "Use at your own risk" because experimental modules are provided for testing purposes only.

That is clearly a confusing situation. Experimental modules are starting to move beyond the testing phase.

You can see this in Dries' keynote from Baltimore. At the 59 minute mark, he gives a great big warning about the dangers of experimental modules. He then gives a great sales pitch for all the cool new features in those modules:

Summary

The experimental modules approach is an interesting approach to developing the Drupal core. This approach isn't going away and is actually becoming more popular. However, there is the risk of confusion as more contrib modules and sales pitches come to rely on these experimental modules.

If you install a module like Display Suite and are asked to enable an experimental module, I would advise you to tread cautiously. Experimental modules can change and may (although it's unlikely) be removed from the core in future versions.

About the author

Steve is the founder of OSTraining. Originally from the UK, he now lives in Sarasota in the USA. Steve's work straddles the line between teaching and web development.

Websites will run into problems. Whether you're using Drupal or any other software, there will be problems at some point.

Drupal runs on PHP and when PHP has problems, it reports them to you. However, often these errors will appear on your site and will be visible to visitors:

However, often these errors will appear on your site and will be visible to visitors:

In this tutorial, we're going to give you a quick introduction to these errors. We'll explain the different types that might appear on your site and how you can stop them from showing.

There are three main ways in which PHP will report problems: notices, warnings and errors.

Notices

These are the least important. According to the official PHP website, notices are generated when:

"the script encountered something that could indicate an error, but could also happen in the normal course of running a script."

Warnings

Warnings are more serious, but probably won't break your site. According to the official PHP website, warnings are:

"non-fatal errors. Execution of the script is not halted."

Errors

Errors are the most serious type of problem and may break your site. According to the official PHP website, warnings are:

"Fatal run-time errors. These indicate errors that can not be recovered from, such as a memory allocation problem. Execution of the script is halted."

Option #1: Disable Error Reporting on Your Drupal Site

One solution is to simply stop the errors from showing.

Go to Configuration > Logging and Errors.

You have three choices:

None will disable all error reporting.

Errors and warnings will display on the most serious problems.

All messages will display all problems and is probably only useful for developers.

Option #2: Fix the Problem

Yes, yes, I know this is a controversial idea. Fixing a problem is definitely harder than hiding a problem.

Here are some suggestions to help you fix the problem. Please backup your site before trying any of these.

Make sure your Drupal site and all your modules and themes are up-to-date.

Search Google and Drupal.org for anyone who has reported the same message. See if they have found a solution.

Read the message itself for hints about the problem. For example, the problem in the image at the top of this tutorial is all/modules/calendar/includes/calendar_plugin_display_page.inc on line 47. This tells that the problem may well be with the Calendar module, because the error is coming from the Calendar module folder. If the problem is serious, you might consider disabling the problematic module or theme.

About the author

Steve is the founder of OSTraining. Originally from the UK, he now lives in Sarasota in the USA. Steve's work straddles the line between teaching and web development.

The UI has changed with Drupal 8.3. You can now see a whole workflow on a single screen. In the image below, you can see Workflows enables you to create custom publishing states and control the transitions between them.

This does mean that the Workflows configuration screens are surprisingly simple. You can control who has access to each stage of the workflows by going to People > Permissions > Content Moderation.

Change #2. New Layout modules

The Field Layout module is new in Drupal 8 and so is the Layout Discover module. Both of these are also experimental modules. This code is adapted from the Layout Plugin module.

These modules currently provide two rudimentary layouts, but additional layouts can be added by others modules. Here's the plan for the layout options in future versions of Drupal. You can also expect modules such as Panels and Display Suite to build more integrations with these new core features, particularly as they already rely heavily on the Layout Plugin module.

Change #3. Big Pipe is stable

This is the first module to graduate from Drupal 8's experimental module program. We first wrote about BigPipe this time last year, when it was called "RefreshLess" and was being prepared for inclusion in Drupal 8.1.

The purpose of BigPipe is to allow sites to deliver personalized content more quickly. Normally, dynamic and personalized content is slow-loading. Dries wrote an overview of BigPipe, which was originally a Facebook project:

Instead of waiting for the entire page to be generated, BigPipe immediately sends a page skeleton to the the client so it can start rendering that. Then the remaining content elements are requested and injected into their correct place. From the user's perspective the page is rendered progressively. The initial page content becomes visible much earlier, which improves the perceived speed of the site.

Here's a visual comparison between BigPipe and standard Drupal:

[embedded content]

Change #4. Authoring improvements

You can now upload images directly via Quick Edit. I suspect this is a feature we may see rolled out to other Drupal administration screens in upcoming versions.

What didn't change?

The Drupal team have ambitious plans to improve Drupal 8's media handling, but those changes will have to wait for Drupal 8.4 later this year. Unfortunately, the migration paths to Drupal 8 are also still largely not stable.

Drupal 8.3 dates and downloads

About the author

Steve is the founder of OSTraining. Originally from the UK, he now lives in Sarasota in the USA. He was a teacher for many years before starting OSTraining. Steve wrote the best-selling Drupal and Joomla books.

Many modules have been in flux during the early stages of Drupal 8's development.

Few modules have changed as much as Pathauto, which the vast majority of Drupal sites use to control their URLs.

In this tutorial, I'll show you the current way to use Pathauto with your Drupal 8 site.

Before we begin, it's worth noting that it is much easier to do this *before* launching your site. It's never easy to change URLs after launch. Also, if you're using Drupal 7, try our complete video class on using Pathauto.

Video on using Pathauto in Drupal 8

Step #1. Install the modules

Yes, all three are marked as "Alpha", but that's the best we have right now.

Install and enable those three modules.

Now, let's see if it's working correctly.

Click Content > Add content and choose a content type.

Make sure that the "Generate automatic URL alias" box is checked. This should be checked for new content, but you may have to enable it manually for existing content.

Step #2. Create the Pathauto patterns

Go to Configuration > URL aliases > Patterns.

Click "Add Pathauto pattern".

In this example, we'll create a pattern for our Drupal content.

Pattern type: choose "Content".

Path pattern: click the "Browse available tokens" link.

You'll see a pop-up box with tokens that you can use. For example, if you want to use elements from your content to create URLs for your content, click "Nodes". Underneath, you will see

In this example, I'm going to use the content type and the Node ID. This will create URLs like this: /articles/1/.

So, in "Path pattern", I enter [node:content-type] and also [node:nid]. The exact format I choose is [node:content-type]/[node:nid]

Content type: Check all your content type boxes.

Label: Choose a name for this pattern. Only admins will see this.

Step #3. Generate the URLs

Now we need to generate the URLs for our existing content.

Click the "Bulk generate" tab.

Check the "Content" box.

Click "Update".

Click the "List" tab and you should see your new URL aliases:

About the author

Steve is the founder of OSTraining. Originally from the UK, he now lives in Sarasota in the USA. He was a teacher for many years before starting OSTraining. Steve wrote the best-selling Drupal and Joomla books.

One of the most common questions we get at Drupal beginner classes is, "How can I tell if a site is built in Drupal?"

We get that question because it's just not possible to know the answer without a few tips and tricks.

If you look at a website such as WhiteHouse.gov, there is no way of telling if it's built Drupal. The design of a site is completely independent from the platform it uses.

We're going to give you 5 ways to tell if a site is built in Drupal. Not all of these suggestions will work on all Drupal sites, but taken together they should give you a clear answer.

Option #1. Check the Source Code

One of the most reliable ways to show if a site is using Drupal is to check the source code.

In the source code, check to see if important files are being loaded from the /sites/ folder. This identifies all Drupal sites, except for Drupal 8. This example is taken from WhiteHouse.gov:

If you find a Drupal 8 site, you will see files loading from the /core/ folder. This screenshot is taken from Dries' site at http://buytaert.net:

You can also search the source code for the words "Drupal", which will identify any version of Drupal:

You can also search the source code for the names of key modules such as "Views", "Panels" or "CCK":

Option #2. Try to access certain files

Some sites may remove this file or block access to it, but if you CHANGELOG.txt to a site's URL, you can often find useful information about the site. For example, view https://drupal.org/CHANGELOG.txt and you can tell that Drupal.org is still running Drupal 7.

Other files that you can do this with include:

/misc/drupal.js

/misc/druplicon.png

For example:

Option #3. Visit the User URLs

One common identifier of Drupal sites are the URLs for user pages.

The URLs /user/ and /user/password and /user/register/ are commonly used to allow people to login, recover their password or register.

An expires header is the most geeky way to check for Drupal sites. Web servers use an expires header to tell the client how long a component can be cached. Use a site such as http://web-sniffer.net to check your site:

And in the results, look for the Expires date. You're looking for Sun, 19 Nov 1978 05:00:00 GMT. What is special about 19 Nov 1978? It's the birthday of Dries Buytaert, the founder of Drupal.

About the author

Steve is the founder of OSTraining. Originally from the UK, he now lives in Sarasota in the USA. He was a teacher for many years before starting OSTraining. Steve wrote the best-selling Drupal and Joomla books.

Are you looking for an easy way to find errors thrown by your Drupal modules and themes?

A lot of new developers are learning to create their first Drupal 8 modules or Drupal 8 themes. Often they've made a very small typo or spacing error and are looking for an easy way to debug their mistake.

Follow this tutorial, and you'll quickly be able to see a detailed list of recent errors on your Drupal site.

Go to Configuration > "Logging and errors".

Under "Error messages to display", check "All messages".

Click "Save configuration".

Go to Reports > "Recent log messages".

You'll now be able to see many of the errors that themes and modules are reporting to Drupal:

About the author

Steve is the founder of OSTraining. Originally from the UK, he now lives in Sarasota in the USA. He was a teacher for many years before starting OSTraining. Steve wrote the best-selling Drupal and Joomla books.

Throughout the life of your Drupal site, you'll have to perform updates. New features, bug fixes and security patches will be released for Drupal itself, plus modules and themes. This process is essential to maintain a healthy Drupal site.

We're going to take you through the process of updating your Drupal sites. Watch the following 5 videos below, and you'll see to update Drupal 8.

Video #1: Introduction

[embedded content]

Video #2: Automatic Updates

Updating Drupal modules and themes is fairly easy because Drupal provides an automatic update option. Drupal does also provide a manual update option if your site or server doesn't allow automatic updates.

[embedded content]

Video #3: Manual Module Updates

Sometimes you may not be able to use Drupal's automatic update functionality. If you can't, it's not a big deal. You can still update Drupal via the manual method. This videos shows you how:

[embedded content]

Video #4: Manual Theme Updates

To manually update a theme on your site, you use the same method as if you were updating a module. Go to the Available updates page in your Drupal 8 admin area and you'll see all required theme updates.

[embedded content]

Video #5: Core Updates

Just as modules and themes are updated from time-to-time, Drupal itself has regular updates. The process for updating the Drupal core is different from updating modules and themes.

[embedded content]

About the author

Steve is the founder of OSTraining. Originally from the UK, he now lives in Sarasota in the USA. He was a teacher for many years before starting OSTraining. Steve wrote the best-selling Drupal and Joomla books.

The current state of Drupal 7

Drupal 7 is currently the "Long Term Support" version of Drupal. That means Drupal 7 will not get new features, but will continue to get bug fixes security support.

The future plans for Drupal 7

Drupal 7 will get bug fix and security support until Drupal 8 becomes the Long Term Support version.

OK, that's great! But when is the final version of Drupal 8 going to arrive? At the moment, it's scheduled to be version 8.4 which is due in early October 2017.

After October, Drupal 7 will no longer get bug-fixes, but it will still get security support. That security support will continue until (bear with me, now!) Drupal 9 becomes the Long Term Support version.

Conclusion

Drupal 7 will likely get bug-fixes until October 2017, and official security support until 2019 or 2020 at least.

About the author

Steve is the founder of OSTraining. Originally from the UK, he now lives in Sarasota in the USA. He was a teacher for many years before starting OSTraining. Steve wrote the best-selling Drupal and Joomla books.

In the last few weeks, there's been some controversy in the Drupal community. Acquia launched a major partnership with Magento, which has left some people wondering about the support for Drupal Commerce. There had already been some nervousness, because Drupal Commerce 2 has been slow to arrive in Drupal 8.

So, what's happening with Drupal Commerce?

First, I would recommend you read Dries' post on Acquia's plans for e-commerce. "Open source e-commerce" by Maxime Topolov also has some useful background information.

Next, I'd highly recommend that you watch this video from Ryan Szarma, one of the lead developers of Drupal Commerce. This video was recorded at Drupal 8 Day. Ryan covers the history, architecture, and features of Drupal Commerce 2 on Drupal 8. There was a lot of interest in Ryan's presentation, with over 30 minutes of questions afterwards.

[embedded content]

Overview of the Drupal Commerce video

Development on Drupal Commerce 2 began with a code sprint in July 2014.

First, Ryan and his team released a handful of standalone PHP libraries for tasks such as currency formats and addresses. Next, they created modules that made use of them, such as the new Address module.

Finally, they rebuilt Drupal Commerce itself from the ground up, taking full advantage of Drupal 8's new features.

This video gives you an overview of how they engineered Commerce 2.x to make it simpler to solve some of the hardest parts of eCommerce.

Ryan includes both explanations and demonstrations of topics including:

Installing Drupal Commerce and its dependencies

Creating and configuring one or multiple stores

Full support for currency and address formatting

Adding product pages and their variants

Customizing Add to Cart forms and Line Items

Configuring the redesigned Checkout form

Managing Payment methods and their new UI

Managing Orders and their workflows

About the author

Steve is the founder of OSTraining. Originally from the UK, he now lives in Sarasota in the USA. He was a teacher for many years before starting OSTraining. Steve wrote the best-selling Drupal and Joomla books.

The changes started with Drupal 8, but are going to impact almost all current and future versions.

In this blog post, I'll give you a short, plain-English overview of the changes.

I'll show how the changes will impact users of Drupal 6, 7, 8 and 9.

What has changed for Drupal 8?

Drupal 8 is not fixed and unchanging. It will evolve over time with the addition of new features.

New Drupal 8 releases will come out every 6 months. Versions 8.1 and 8.2 have already shipped with new features. 8.3 and 8.4 are due in 2017.

The latest release will be the only one that's supported.

The end of the process will be a Long Term Support version or LTS. When that LTS arrives, no new features will be added, only security fixes.

Here's a graphical overview of how the releases work:

Here's the big change: new features can now be added after the 8.0 release.

One of the downsides to Drupal's old release cycle is that new features couldn't be added.

Drupal 7 was essentially finished in 2010 (although it was released the next year). So no new features have been added to Drupal since 2010.

That feature freeze is great for enterprise customers, but very clunky for today's software developers who are used to working iteratively, making fast and regular updates.

In the proposal, Dries said that the new release cycle allows them to use "a more agile development approach of getting smaller changes out faster, seeing how they do, and making further changes based on real-world data. "

In the comments, Jesse Beach (who is responsible for much of the work on Drupal's UI) said, "Building a usable UI requires numerous iterations and we really don't get those over large major release cycles."

What does this mean for Drupal 9?

Drupal 9 will only start development when the the core team have completed a new feature big enough to justify a new version.

Drupal 9 should arrive on a normal schedule, which is 2 or 3 years after Drupal 8.

What does this mean for Drupal 6 and 7?

Wait, why are we bringing 6 and 7 into this?

Because this new release cycle may be good news for owners of Drupal 6 and 7 sites:

Drupal 6 would be security supported until 8's LTS rather than only until 8.0.

Drupal 7 would be security supported until 9's LTS rather than only until 9.0.

So this change could mean an extra 18 months of fixes. It's possible that this could mean Drupal 7 support until 2018 or 2019.

What does this mean for you building sites in the future?

Be very careful with the selection and quantity of modules you use in Drupal 8. This is good practice anyway, but will become a more formal recommendation with Drupal 8.

Here's the advice from the release cycle proposal:

"Don't use custom modules; stick to only contrib modules that are adequately maintained. Or, if your site requires custom code, make sure the developers you hire know to limit their code to only accessing APIs marked as stable."

In other words, changes may happen between Drupal 8.0 and the Drupal 8 LTS. If you build you own modules or use poorly supported custom modules, watch carefully in case updates cause problems.

Wait, doesn't this all sounds very familiar?

Yes, this release cycle is very similar to those adopted by Joomla and Typo3 amongst others.

This release cycle is one form of Semantic Versioning which is adopted by many products: http://semver.org.

Can I found out more about this change?

Yes, this video from Margaret Plett at Drupal 8 Day is a great introduction to the thinking behind the new release cycle.

[embedded content]

About the author

Steve is the founder of OSTraining. Originally from the UK, he now lives in Sarasota in the USA. He was a teacher for many years before starting OSTraining. Steve wrote the best-selling Drupal and Joomla books.

Object oriented programming (OOP) is the most popular model used by PHP developers.

You'll find object oriented code in most major CMS's and platforms. Joomla has relied on OOP since version 1.5. Drupal 8 was completely rewritten, in part to introduce OOP principles.

In this class, you'll learn the fundamentals of OOP and, in particular, how they apply to PHP.

This class focuses on the use of classes, objects and methods in OOP and covers the following topics:

How to Create a Class in OO PHP

How to Create an Object from a Class

How to Access Object Information in a Template

How to Add Methods to Classes

How to Use the Construct Method and Magic Methods

How to Incorporate Global Variables into a Class

Public, Private and Protected Visibility

Why Should You Use Private Visibility?

Using Subclasses (or Child Classes) in OOP

An introductory video from the class

About the author

Steve is the founder of OSTraining. Originally from the UK, he now lives in Sarasota in the USA. He was a teacher for many years before starting OSTraining. Steve wrote the best-selling Drupal and Joomla books.

Understanding the problem

In September, eight themes were published. The breakdown was two themes for the aGov distribution, four base themes, and one administration theme.

In August, two themes were published. That's not a typo ... two themes in a whole month.

Looking at the August themes, one was a base theme and the other was "Drupal 8 Custom Theme". This second theme is ready for beginners, but it was published on August 4th. That's not a typo either. Right now, we've now gone eight weeks without a single site-builder friendly theme published to Drupal.org.

What about themes published before August 4th? We have to go back to July 11 to find a new theme. That's nearly a whole month with zero new Drupal 8 themes.

So, not only have less than 50 themes been added to Drupal.org this year, but the pace is actually slowing:

Around 80 themes were available when Drupal 8 launched.

36 themes were added in the first half of 2016.

Only about a dozen themes have been added in the second half of 2016.

Why are we facing this problem?

I wish I knew. In contrast to the problem with themes, new modules are added to Drupal.org daily.

It's possible to guess at some reasons why themes are not being published:

The Drupal community is standardizing on a small set of base themes (Bootstrap, Zen, Foundation)

Designers are taking a while to get used to the new Drupal 8 theme layer.

This was just a summer slowdown. As people get back to work in September, more themes are being published again.

The theme review process is brutal. It's taken us over 3 months to get one theme close to approval, but the process is incredibly slow and opaque. Drupal.org's theme review is one of the most frustrating and broken processes I've seen in 14+ years of open source work.

The lack of any commercial theme designers focused on Drupal 8.

I don't know if these explanations are valid, but I'm sure that the lack of themes is a hinderance to the success of Drupal 8.

Over to you ...

What are your thoughts on the state of Drupal 8 themes?

Are there ways we can encourage Drupal designers to publish on Drupal.org?

Updates

Update 2: I underestimated the scale of the problem. Not a single theme has completed the approval process in 2016. Zero. That's absolutely astonishing. Every new theme in 2016 has come from a long-term contributor who can skip the approval process. There were no new contributors in 2016. The most recent approvals are from December 2015:

About the author

Steve is the founder of OSTraining. Originally from the UK, he now lives in Sarasota in the USA. He was a teacher for many years before starting OSTraining. Steve wrote the best-selling Drupal and Joomla books.

This week is DrupalCon Dublin. And as always, Dries gave the keynote address on the first morning of the event.

This year's keynote was broken into two sections: "Drupal 8 Update" and "The Why".

In "Drupal 8 Update", Dries talks about the technical side of Drupal. From minute 27 to minute 42, Dries talks about what's new in Drupal 8.2, which arrives on October 5th. We've covered those new features in previousposts. Then, from minute 42 to 48, Dries discusses features may arrive in future Drupal versions. If you're short on time, watch those 6 minutes. Scroll down in this post, and we'll cover those 6 minutes in detail.

In "The Why", starting at minute 40, there's a much broader focus on the larger purpose of Drupal. This section of personal anecdotes and stories of Drupal in action.

Here's the video of the keynote:

[embedded content]

New Drupal 8 Ideas: Sample Content

Angie Byron from Acquia also talked about this in her excellent Drupal Dublin talk. The sample data in Drupal really is not user-friendly and needs to be improved to welcome new users more effectively.

New Drupal 8 Ideas: Page Layout

In short, this looks like it would be a simpler and more elegant version of the Panels module in the Drupal core:

New Drupal 8 Ideas: Media

I suspect this is the number one most requested feature amongst Drupal users. And there's already a long, detailed discussion on improving Drupal's image handling.

New Drupal 8 Ideas: Field Layouts

We've already seen a Panels-like idea. This sounds more like the Display Suite module.

New Drupal 8 Ideas: Refreshless

As some or all of these feature arrive in the Drupal 8 core, we'll be sure to cover them here at OSTraining.

About the author

Steve is the founder of OSTraining. Originally from the UK, he now lives in Sarasota in the USA. He was a teacher for many years before starting OSTraining. Steve wrote the best-selling Drupal and Joomla books.

All you need is a Drupal 8 site and you should be able to follow along in just a few minutes:

Video 1. Create the required module files

In this first video, you'll set up the folder and basic files needed to register your module.

Video 2. Add your first hook

In this video, you're going to implement your first hook. This hook will allow us to alter a form before it's rendered.

Video 3. Add routing

Now that you've created a module, it's time to make it visible. In this lesson, you'll build a FirstController.php and a routing.yml file. This controller will create a page with a URL and the access permissions.

Video 4: Add a menu link

In this lesson, you'll create a new file called .links.menu.yml. This file will define the menu link so that it appears on your Drupal site.

About the author

Steve is the founder of OSTraining. Originally from the UK, he now lives in Sarasota in the USA. He was a teacher for many years before starting OSTraining. Steve wrote the best-selling Drupal and Joomla books.

During the four weeks since that post, the Drupal team has added more major features. Drupal 8.2 is now in the release candidate stage, so the features are finalized. Now is a good time to download and test.

You can read the 8.2 changelog for a rundown of all the changes, but in this blog post we'll introduce you to three more big improvements.

First, it's important to note that all these new features are disabled by default. These are called "Experimental modules". Some of them have been in this state since Drupal 8 launched a year ago.

When you enable one of these modules, you will get this warning message:

On the upside, these experimental modules have no known security issues and don't impact the core in any way: they can be removed with no disruption. Plus, we've written very positively on how the new Drupal 8 development process is working, and if this is how the Drupal team want to roll out new features, let's give it a go.

Feature #1. Content Moderation

This is a port of the Workbench Moderation module and allows you to expand on Drupal's "unpublished" and "published" states for content. This project was announced by Dries during his keynote at DrupalCon New Orleans and is heavily supported by the Drupal team at Pfizer.

Go to Configuration > Content moderation and you'll see two options, "Moderation states" and "Moderation state transitions".

Moderation states provide "Draft" and "Archived" as additions to basic "Published" option.

You can click the blue "Add Moderation state" button and create new states:

If you move the "Moderation state transitions" screen, you can create the actual workflow. You decide the direction in which content moves from state to state, and which user roles are allowed to make that move.

Once your moderation workflows are established, go to Structure > Content types > Manage moderation and you can apply the workflows to different content types.

Feature #2. Datetime Range

The Date module in Drupal 7 packed many features into a single install.

In contrast, the Date module in Drupal 8 is far more basic, to the point where it left out some key functionality. The Datetime Range module is an attempt to restore one of the key features: start and end dates. This is vital for anyone needing to add events to Drupal.

After enabling the module, you'll now be able to create "Date range" fields.

Feature #3. Outside-in

To test this feature, you click the Pencil icon for a block, and then click "Quick edit".

After clicking, a right sidebar will appear with the configuration settings for that block. Dries has a longer explanation of this feature on his blog.

About the author

Steve is the founder of OSTraining. Originally from the UK, he now lives in Sarasota in the USA. He was a teacher for many years before starting OSTraining. Steve wrote the best-selling Drupal and Joomla books.

If you want to set up an online store, and don't want to set up a new website, then Ecwid is a great solution. Ecwid has everything you need to set up an e-commerce store from products and categories to payments and shipping.

Once your store is created, you can embed products (or the whole store) into Ecwid as simply as you would embed a YouTube video. This enables you to easily use Ecwid with Drupal, Joomla or WordPress.

About the author

Steve is the founder of OSTraining. Originally from the UK, he now lives in Sarasota in the USA. He was a teacher for many years before starting OSTraining. Steve wrote the best-selling Drupal and Joomla books.

Drupal 8 has been out for nearly one year, and is now maturing into a really powerful platform.

We will hold an online event all about Drupal 8 on November 19th, the first anniversary of Drupal 8's release. This will be the perfect day to celebrate D8.

The event will be called "Drupal 8 Day" and will be an online version of a Drupal Camp.

It will be one complete day of live presentations. To get a good feel for this type of event, check out Wordsesh.org in the WordPress space.

The goal is to present Drupal 8 in the best possible light, especially to people who normally can't attend a Drupal Camp. We talk with a lot of people who just don't live near any kind of DrupalCamp. Some typical examples are people outside the big Canadian cities, people living in Eastern Europe but outside capital cities, and people in sub-Saharan Africa.

Presentations are welcome on any Drupal 8-related topic and need to last about 45 minutes.

The event will be 100% free to attend so that anyone can attend.

Are you interested in taking part?

About the author

Steve is the founder of OSTraining. Originally from the UK, he now lives in Sarasota in the USA. He was a teacher for many years before starting OSTraining. Steve wrote the best-selling Drupal and Joomla books.