 Alright everyone, welcome to using paragraphs to weave a beautiful content tapestry. My name is David Needham and today we're going to be talking about paragraphs module and we're going to be going in from a beginner's perspective to describe what you can use beginner, I'm sorry, what you can use the paragraphs module for and some use cases, a quick demo of like how to make use, you know, install it and start using it on your own website. So my name is David Needham, I work for Enjoy Creativity and Triplo. Enjoy Creativity is a nonprofit that helps churches and ministries with web design like Drupal and other online services and Triplo is a collaborative network of freelancers that I started in the Twin Cities. I've been working with Drupal for a while, several years and I have a real passion for helping site builders and beginners to really be empowered by the websites that they are building or that they have built for them. So I really love giving presentations like this where you can take a lot of things that were once done and only in code and empowering site builders to be able to do more directly from the interface in a standards compliant and responsive in good way. And I'm Les Slim, I work at a small development shop called 10.7 out of Minneapolis, Minnesota. I'm approaching my 10-year triple anniversary. It's going to happen sometime this year so I'm going to have a party at some point. Quick shout out for Twin Cities Drupal Camp which I helped to run. It's happening on June 23 through 26. It's always one of the best times of the year. It's Minneapolis at its best. We have great outdoor parties that are not intimidating or elbow jostly or loud. There's no fire breathing dragons or anything but we have good people. The content is great. This year we're featuring a higher education summit on the first day and also an array of free trainings that are free with registration. So please check it out. It's TCDrupal.org and hope to see you there. All right so I think a really good way to talk about what you can use the Paragraphs module for is by describing a scenario. Let's say you have a client or maybe you are the client. You want to do something like this on your basic page. You want to have two columns of content with an image, some sort of a title, subtitle and a brief description. And you want them to be in two columns right next to each other. Well there are lots of ways you can do this. So certainly you can just use the body field. You can type in all the code. You can use the H2. You can do the inline styles to do float left and float right and all of that stuff. And this will work. This will actually generate what you saw on the previous page. This absolutely works. Thanks for coming. Write our talk on it. But the problem is is this is a blob. There are lots of problems with blobs but basically this is a lot of stuff all in the body field. This is an image and there's code. There's styles. It's just it's a big blob. And we're using blob for a specific reason. So who here is aware of the movie The Blob from 1958? Steve McQueen. So a quick overview. The blob is in a meteorite and shoots across the sky. The meteorite crashes in small town USA where an old man pokes at the meteor and the blob jumps out. And it looks like a harmless, innocuous little glob of red jelly but it immediately latches on to his hand and consumes him. And the blob moves through small town USA and consumes and eats people. Skeletons, individualities and all and adds them to its own indistinctness. Whatever they once were, they no longer are. They are just consumed by the blob. The blob is your body field. The blob of the body field will eat you alive if you allow it to do so. And it may not seem like it's going to do so but the more you let it, the more the more latitude you give it, the more likely it is that you are going to lose yourself inside the entity called the blob blob. So there are a few things that count as alternatives to blobs. We've listed a few of them here just because they're things that get discussed fairly often. The first thing that comes out of the box in Drupal is that we can simply define our fields and we can work in our template files. You know, there are several talks about what you can do on the front egg and the things that are front end, things you can do with twig. And there are lots of benefits to this approach. It's flexible, it's great for coders because you can do exactly what it is that you want to do with your template files. The issue with this is that if you're not a coder, if this is not one of your skill sets, it can be very hard for you to get into the files and to figure out exactly what it is that you want to change. If you're reliant on a programmer who is working for you or who you've given money, then you might be subordinate to that person for a while. There's also... There's also display suite, which is one of my favorite modules. It lets you take a lot of the things that you used to do with the template files or tipplefips and move them into the UI so that a non-technical person can move fields around into different orders. You can make columns, you can do things, and that works really well. You do still need to know a little bit of code to really kind of use it to its fullest. It's not essential, but it's a pretty good program or a pretty good module. Sure. Yeah. Another alternative, and this is a big one, it's panels. Panels plus panelizer. There's an entire ecosystem of modules that's based around the panel's approach. We're not going to go into great detail here. I actually enjoy using panels. There's reusability that's involved there, but the things that sometimes make me shy away from panels is that it's a lot of configuration. There's configuration all over the place, not just for the administrator who sets up the initial panel's interface, but also just for the users, the content creators, who have to then maintain their own content. There's a lot of stuff happening, and there's new patterns of user interface that aren't part of core, and it can be very complex to learn. It's also something that, if not configured correctly or very precisely, can expose parts of the interface that allow someone to totally break layouts, it can be brittle in that respect. So these are the alternatives, really, that we've identified and that we've used over the years, and this has evolved. We've used sort of each of these as we've progressed in our careers as Drupal themers, developers, whatever. But the reality is, none of these are really what we're looking for. None of these accomplished our mission of providing something almost entirely in the UI that makes it really, really easy for site builders who maybe even don't know anything about Drupal to come into and to make use of. Paragraphs comes to the rescue for us. So I define paragraphs, the Paragraphs module as a tool that lets site builders work together to create beautiful pages using clean-ordered XML-friendly content. The beautiful part is really because it's good for people. It's something that lets you construct a page where the end result is something that looks really nice. It merges video and audio and pictures and text and different column layouts or whatever you want on the front end that people can see and is a beautiful thing, which is difficult to do without code sometimes. And because it's XML-friendly because it's structured content. It's great for computers. It can respond and your developers can make it, can give it structure and give it meaning, which is hard to accomplish in the boundaries of a WYSIWYG field. So a quick overview of the concept of what a Paragraphs field looks like and how we might use it to replace the body field. If we imagine for a second that this box represents a piece of content, a node on a page. And so the node contains the title at the top of it. And we might have defined maybe a field that contains an image. And that image displays the very top of the node underneath the title. And then underneath the image we have one big body field. This is pretty common, a common pattern in Drupal Core. The body field in fact is something that is created for you when you create a content type. And maybe this body field contains your text. It might contain some markup, some images that you throw in using maybe some sort of media widget. This is pretty typical of what you get with Drupal out of the box. Where Paragraphs comes in is it gets rid of the body field. It kicks out the body field and replaces it with a Paragraphs field. Let me interject real quick just to say that we're suggesting you replace the body field with Paragraphs module or with the Paragraphs field. You don't have to. Paragraphs really will just add a field for you. You don't have to replace the body field. That's true. But we do do that. We often do that. I've yet to come across in their instance where I've kept a body field and a Paragraphs field as well at the same time. The benefits of the Paragraphs field, you can contain any number of Paragraphs. The body field, you have one Paragraph, which is a blob of all of the things that come in it. But a Paragraphs field can contain individual Paragraphs that are chunked together and retain their distinctiveness and their structure. So one of the other benefits of Paragraphs, you can create multiple different kinds of Paragraphs. So you can, as a developer or as your site builder, define a Paragraph type that might be image, a Paragraph type that might be meant to contain a video, and a Paragraph type that might just be for text. And you can mix and match these Paragraphs on the page. Each Paragraph type can have its own set of fields. So all of the field modules that are available to you in the Drupal ecosystem, all of those field modules inherently work with a Paragraphs approach. And so there are a couple of different examples of types of Paragraphs that we might have. Text we've talked about, this would just be like you've got a Paragraph or a section of text, what you might normally have in your body field. This is still useful, because we still are very much associated with words. Maybe a pull quote, which is a specialized paragraph, which is just something that you want to pull out of the page and style a little differently, give it some emphasis, maybe a little bit bigger of a piece. You might have an image field or an image paragraph, which contains an image field, but it might also contain an image field and a text field for a caption, so that you have a Paragraph type where you can very specifically define where the caption is in relation to the image or whatever other attributes that you might want to associate with an image in a layout. A video, there are several video field modules that are available in Drupal 7 and Drupal 8, where you can, for instance, paste the URL of a YouTube video and it will automatically render on the page. And you can also put a caption on it the same way you might want to put for an image paragraph type as well. This type of paragraph that we have here is something that I like to call content paragraphs. They're paragraphs that define things that would go inside your body field. They're pieces of content in and of themselves. There's another type of paragraph that is distinct from that in my universe of what paragraphs means to me. And they would be things like in a side, something like a sidebar or some pulled-out piece of a layout that you might have on a page. So an aside might contain other paragraphs in it. And I might have it styled so that it can float to the right of a particular piece of a layout or float to the left of a layout. There might be an accordion. So you might have a paragraph which contains a bit of text that is hidden behind an accordion so that there's a title that you can click on. And it expands the accordion. And you can have several accordions stacked on top of each other as different accordion paragraphs. You might have something like a two-column paragraph type, which would give you the ability to put different content side by side with each other. These paragraph types are what I like to term as layout paragraphs. Layout paragraphs would have styles associate them that would maybe allow you to generate some simple page layouts without having to resort to a panel's strategy or without leaving the interfaces that are common to editing content. There's a third type of paragraph, I think, in this ecosystem. And it's something I like to call a pony. And you might ask me, what is a pony? And it is a small horse. And it's a beautiful, special creature that requires a lot of attention. And no pony is the same as any other. My pony is not going to be your pony. I love my pony. I don't love your pony. Ponies are special. And they are specialized use cases for your particular client. I don't know what your pony might look like. But it's one-off cases that you may not be able to satisfy using layout paragraphs or content paragraphs. Ponies have their uses. But because they're special cases and because they're required so much attention, you should try to keep those maybe to a minimum. I think it's important here to reiterate also that the content paragraphs or layout paragraphs are distinctions that we're making ourselves. These aren't different types of paragraphs that you define in the paragraphs module. It's just we like to think about it as creating the layouts that you put content within. And so you use the content, like the text or the photos or the stuff, and you put those paragraphs within layout paragraphs so they arrange things. You don't want to mix those together or get several layers of a layout within a layout within a layout. You can, but the code turns ugly. That's exactly right. Let's see what that looks like. So special cases. So returning to our example of what a node looks like. This is the traditional node that comes out of Drupal Core. This is a content type with a node title, image field, body text. And again, we're going to, in our example, we're going to remove the body field entirely. Body field out. And income flying in are paragraphs. You can see these are an assortment of paragraphs that I put here, a text paragraph, followed by maybe a poll quote, another text paragraph, and then I put a layout paragraph down at the bottom of the page there. One of the things that's great about this is that image field that I had added to the node previously doesn't have to be its separate image field anymore. Because paragraphs is flexible enough to have an image paragraph type, I can get rid of that structure and add in the flexible paragraph structure and replace that entire field with another image. If I don't like where that image paragraph is, if I didn't want that to be at the top of my content, that's fine. I can reorder these paragraphs on the edit form to whatever I like. So let's move that two column paragraph up and put that second text paragraph down at the bottom. In fact, let's also move that image paragraph further down to the content. Let's start with a poll quote. Let's start with something provocative to say at the very top. The order is up to you. You have the flexibility to define how you want your content to look. And it retains the structure that you're looking for on the back end and to keep your developers happy. Because of that predictable structure and predictable HTML, you can build responsive CSS layouts which are so hard to do with unstructured content in your body field. If you imagine that the left side of the page is maybe a tablet view or a desktop view, and the right side of the page is what it might look like on a small device or a small phone, we can start putting in our paragraphs and seeing how that might respond. So I've got a text paragraph and a side, bit of text, video, two column. And because of the structure, I can tell it that maybe in the mobile view, the aside doesn't float anymore but that it fills the entire width of the page. And that I can maintain the beautiful flow of the content order that I intend while giving richness to both a tablet view and a mobile view. We mentioned that we have a distinction between content paragraphs and layout paragraphs. The aside is something that we defined as being a layout paragraph. One of the beautiful things about paragraph fields is that you can contain other paragraph fields inside of paragraphs. So my aside paragraph can contain other paragraphs. I can put a text paragraph in there, an image paragraph, a pull quote, and those are reorderable in the interface the same way as they would be as we've already seen within the aside. I can fill our two column paragraph with the paragraph types that we've defined for contents as well. Yeah, so that was a great overview of how you can use it in theory. But what about our scenario? So our scenario to remind you is just we want to build this within our Drupal interface on a basic page, for example. So here's how you do it step by step in Drupal. Specifically, we're going to be looking at Drupal 8. However, this module is available for Drupal 7. The steps are very, very similar. There's just a few differences, but you can figure it out. Do you want to try for one? Sure. All right. So the only modules that we have enabled right here, we installed Drupal 8 just kind of the standard installation profile, and we added the paragraph module and the entity reference revisions module. Entity reference revisions is required by the paragraph module, so those are the only two that we need to do this. So step one, after we install those modules and enable them, we just have to go to the paragraph type section. That's going to be under the structure section at the very top, so we hover over structure. We click on structure. We go to paragraph types, and we end up at this page. Right out of the box, we don't have any paragraph types. However, in Drupal 7, possibly Drupal 8, there is a module that comes out of the box with it called the paragraph pack. Paragraph pack, yeah. Paragraph pack. That includes a preset number of paragraphs that people sometimes use. Les and I have discussed it, and we decided we really don't use them that much. We prefer to make our own from scratch. But you might like to demo the paragraph module yourself by enabling that module and getting some paragraphs pre-entered on this list. So we want to get started by adding a few of our paragraph types. So we click on the Add a Paragraph Type button. And we need to, we clicked on the text, I'm sorry, we called it text, because we want to add a text paragraph type. And that works pretty well. But it's kind of like a content type at this point, and that you actually have to add fields to the paragraph type before you can actually add any sort of content onto it. So once we have that paragraph type, we go over to the Drop button, and we click on Manage Fields. We add a new field for text, because this is just a simple text field. So we chose text formatted long, typed in the label and the machine name. And now I went ahead and jumped ahead a little bit here and I created, I did the same thing over again for both a pull quote paragraph type and an image paragraph type. The only difference here is that the pull quote has another, I'm sorry, it has the same sort of text field on it. The image has an image field in it. That's all that there are. Yes? Sure, ask a question. It's existing for that same structure. Right, right. Do you see them all the way through? Oh, I see what you're asking. So the question was, are the fields that we're adding to the paragraph types reused in the same sort of way as content types? I believe they are. In Drupal 8, fields can be reused between entities of the same entity type, but you can't use a field that you created on a content type on a paragraph type. Right, so if you go to create another paragraph type, you'll see all the fields that you've created for all the previous paragraph types, but not your content types. All right, so we have a few of our paragraph types for content created, but now we're going to create a two-column layout for the layout sort of paragraph type. So I just created a new one. I called it columns two. And right out of the bat, there aren't any fields in here, so we need to add fields. So this is a two-column layout. So what we want to do, we're thinking about this, we want to add the ability for someone to add a paragraph within this layout paragraph. We have two columns, so we're going to have two fields. Each one of those is going to let someone add a paragraph into this paragraph. So we do that. We can go into add field and we choose the paragraph type. It's important to note that this is within the revisions. What was it called, us? Entity reference revisions. Entity reference revisions. There's two places where you can choose paragraphs from the list. You want the entity reference revisions one. Do you know the technical reason for that? That's the widget that we use to add multiple different bundles of paragraphs together. It requires entity reference revisions. And the regular entity reference field doesn't allow for revisions, which is useful to have for content. Absolutely. So just always use the entity reference revisions version of the paragraphs field here. Cool. OK, so within that field configuration, you can choose a default field if you want. We're not going to do that here. You choose the reference type. In this case, it automatically selected paragraph types. And we can choose from the list which paragraphs we want to be able to add into this particular paragraph field. So we selected image, pull, quote, and text. Again, you can choose self-defined layout paragraphs to put into a paragraph. But it's generally frowned upon. What would a two-column paragraph look like inside a two-column paragraph exactly? That would be complicated. But you could do an accordion within a two-column paragraph. Maybe. Maybe. So I mean, you can do it, but just be careful. So we did that. So I added the first column, which is a paragraph type with those three paragraph options selected. I did a second one with exactly the same options. So now, great, we have our paragraph types defined. We have some content. We have some layout. So next, we can jump over to our basic page. So it's a little ambiguous at this point. One of the things that I gripe that I have with the Drupal 8 interface is that it all kind of looks the same. Theoretically, that's a good thing. You want to be consistent. But it's really difficult to tell when I jump from paragraph types to content types. Very, very similar. So content types, in this case, are within structure, content types, and I selected the basic page. So I'm looking at manage fields now for the basic page content type. We have the body field here. In this case, we want to just replace the body field. We want to get rid of it completely. So I went ahead and deleted that. And I put in a new paragraph field, and I selected columns two. So now, whenever we go into the new basic page, we're going to now create a new piece of page content. This is what we see. We have the title. We have some stuff on the sidebar for typical node stuff. And then we have this section in the middle where it says add columns two. That's the name of our field. That's the name of the paragraph type that we had created earlier for the layout. Because we only told that we could select one, just the layout of this case, that's the only option we have here. So we click that. And now, within this particular paragraph, we have the option of adding as many content paragraphs as we want, because that's how we set it up in the paragraph type. This is one of those things where it's a little bit confusing to describe to someone. And it really only makes sense when you have a chance to play with it and sort of do it yourself. But in this case, we have the two-column paragraph with, at this point, no paragraphs within it in either of the first column, second column fields that we created. So we can click that little drop button, and we see all the options that we had selected when we added that field to the two-column paragraph type. So in this case, maybe we add a photo. We add that. Remember, we're recreating that scenario. So we add the Drupalicon. We put in some text here. And in this case, just to save myself a step, I did put in the heading for the Laura Mipson thing. You could also create as many paragraph types as you wanted. You could have a heading if it's something we're using over and over again. But in this case, I just put it in the text field. So I did this twice. I did it for the first column. I did it for the second column. I put in the heading and all that stuff. And it doesn't quite look right. First of all, there's labels all over the place. If you are setting up a new Drupal website, new content types, and new fields and stuff, this is probably something you've seen a lot where you're like, oh, yeah, I have to go to manage display. I have to disable the labels. It's just one of those things you have to do. So with paragraphs, you might have to do this at a few different levels. So you have to do it, first of all, on the basic page to turn off the label for this two-column field that you added. And then you have to go into the two-column paragraph type and turn off the labels there. And then you have to go into the individual fields and turn off the labels there, unless you want the labels. But in this case, we really don't. No. No. So here's what it looks like when you get rid of the labels. Quite a bit better, but it still isn't quite what we're looking for. Two row layout? Yeah, two row layout. That's good, right? No. So in this case, this is where we jump into the theme a little bit and we add some code. Now, this code is a lot cleaner than we would have put if it was directly in the body. And this is where what Les was talking about. The code that you're creating is a lot more predictable. It's something that's a lot more responsive, too, because you know exactly what you're getting out of it. And you have a lot greater control over it. It's also a lot cleaner. So once we add in float left, float right, 50%, this could be done a lot better, too. But for the sake of the example, here you go. There we go. So we have our two-column layout selected and it works. And now we can recreate this. We can reuse this over and over and over again. Every time now that we use a two-column field, it's always going to do it just like this for us. So once you code it once, it's always going to work that way. So yeah, I think that's a demonstration of what we tend to like about paragraphs. It's a flexible system, but it uses the edit interfaces that people are already used to. It's the content type edit form. It's predictable in that way. The things that it allows you to do are to give your content editors the ability to remain flexible. The way that you do that the best is to think beyond the current request and try to make your paragraph types as simple as possible. Avoid ponies because ponies often can't be winnowed down into the use cases in the future that you aren't even thinking about. The more generic you can keep your content paragraphs and your layout paragraphs, the more likely is that your end user, the editor, the content creator is able to create the views that he or she wants. There are a few contributed modules that are great with paragraphs. In Drupal 7, there is paragraph ID and classy paragraphs. Yeah, I found these modules to be really great because the paragraph ID will give each paragraph that you add a unique ID. I don't mean ID like the ID tag. I think it actually does classes too. So you can theme each individual paragraph with a unique identifier, which is great. For classy paragraphs, it lets you add classes directly to each paragraph field that you add to. Theoretically, you could do things like, I want my paragraph to have a class of float left or float right or justified or whatever other things your theme might already be using. You can just add these into a field and then know that whatever text or call out or image or whatever is already going to be inheriting those simply by putting in the class that you select. That's right. Also paragraphs are entities. They are reusing the concept that was used in Drupal all over again. And because they're entities, any of the field modules that are available in Drupal 7 or Drupal 8 are available in your paragraphs types too. They enrich the ecosystem of what you can allow your paragraphs to do. So in Drupal 7, for instance, there's a module called block reference, which you can use to allow people to embed blocks into content directly into the content of your node. That's something that's available in Drupal 8 and Core using reference fields, but in Drupal 7 you might need a field module to do that. It already exists. Just grab it and use it. It's great. View field in the same way. I just want to interject too. The great thing about the block reference field is it lets you reuse content that you might appear on multiple pages. So for example, if you have your call to action that appears on most pages, but maybe it appears on different spots on most pages, you can put that in a block, which is a lot more flexible in Drupal 8 now, and then embed that wherever you want on your page using paragraphs. Exactly. Same kind of thing for something called the view field, which is a field that allows you to embed the output of a view into your node using a field. And so this means that, for instance, for example, you might have a view that is related content, content that is related to the article or the content that you are looking at right now, and you may not want to put this in your footer or in one of your sidebars. You might want to have this injected somehow in the middle of your content, and because you can make it into maybe a view paragraph, you can intersperse that wherever you like in the flow of your content. Additionally, there's myriad video modules available in both Drupal 7 and Drupal 8. You can pick the one that you tend to like, and it will work out of the box with your paragraph type. And real quick too, it is important to note that since it is an entity, you can use any field, any sort of field module, whatever your favorite field module is, it should work. So if you have a favorite date, email, link, those are a few popular ones. There's tons and tons, address, whatever. Those can all be put into paragraphs. Exactly. There's also a neat trick in Drupal 7 and Drupal 8. There's a module called view mode selector. The really awesome thing about this, it's a field that you can put on an entity type, and it will allow you to switch which display mode is used to display that particular entity. So one of the things that we use this for example for is we might have a layout paragraph called an aside, and the aside is meant to be floated either to the left or to the right on a page. We use view mode selector module to define for the aside paragraph type two display modes. We have a left display mode and a right display mode. And putting a view mode selector field on that paragraph type, we can allow the content editor to decide whether or not they use the left display mode or the right display mode. And the entity is going to be classed with that display mode, so we can respond to it correctly in our CSS. We can make sure that it floats when you are on a tablet view and that it correctly expands to fill the entire width on a mobile view. That's just one of the options that you can have with view mode selector. You can selectively remove fields from display and some display modes and display other fields and other display modes so you can enhance the reusability of your paragraph types by giving them distinct display modes that you can expose to your editors as well. So one thing that I used this for recently on a project was we had basic pages and we had articles, news articles, blog posts, whatever. We added a article reference field within our paragraph so that the people writing... Actually, let me take a step back. So we had articles where you could reference other articles basically. So within an article, you're writing it out, you're doing all that stuff. We could then reference another article in a paragraph field and then using view mode selector, we can say, should we see just the title of the article? Should we see the summary? Just a brief, like here's a little thing in a call-out box, maybe push to the side. Should we see the full article? It doesn't happen as much, but sometimes maybe. Or should we see the author of that article that we created? And that's all possible through tweaking that view mode selector. A couple other enhancements that we have in mind that have really helped us wrangle the experience. One is to use field group module. It's a handy little module that allows you to group sets of fields together on your form displays, on your edit forms, and also group fields together on the display side. But where it helps us particularly is that we can put sets of fields inside a vertical tab field group or a horizontal tab field group or a field set that you can collapse on the page. So by grouping fields together, you can organize what the edit experience is like. For instance, you may not want to expose all of your paragraphs that comprise your content when you edit the page. You might not want it to be listing all the way down the page. You can put your paragraph field inside a vertical tab so that your editors can click on the tab to reveal their paragraphs when they're ready to look at it. You can put it inside a collapsible field set so that it doesn't pollute the initial view of the edit page. But when they are ready to look at the paragraphs, they can expand the field set and view it that way. That's exactly how I have been using it. There are a few times where, for example, the two columns that we just did, it works okay when you have one or two or three fields within a two-column layout, but what if you have a lot? What if you have several fields and it gets really, really long? I always like to wrap all of the regions, whatever, within my layout paragraphs within pre-collapsed field sets so that someone adds a two-column layout. They have two field sets that are closed. If they want to edit anything within it, they just click it and then they can see all of the fields within that particular field set. So it keeps it from being just scroll, scroll, scroll down the page. It really cleans it up quite a bit. Another thing I like to do in particular is, and this is a little more cody, but in your twig file for your paragraphs field, the field that's responsible for containing all of the paragraphs that replaced your body content, there's a lot you can do to simplify what that template looks like, especially with nested paragraphs. If we see, this is an example of what it might look like out of the box, the markup for a couple nested paragraph types. This is actually the same example that we went through before. This is the markup for a two-column paragraph that contains two different paragraph fields for each column and then each of those columns contains an image paragraph and a text paragraph. This is the divitus that we're now used to in Drupal, unfortunately. There's a lot of cruft in there. What you can do if you edit that field template that's responsible for your field paragraphs is you can identify all of this cruft. The things that the field markup puts in that maybe doesn't make sense for containing paragraph entities, and we can remove those. With a few lines of code in there, we can just get rid of those extraneous divs and now our paragraph structure looks so much better when we're inspecting our code. We've got our page at the top level and then the field that contains our paragraphs that replace the body field, and then in there we see our column, our second column and just the individual paragraphs in there. It's simplified this example, but it is so much better than what you might have to look at if you are inspecting your HTML code with Drupal markup. The example here is with Twig. It's also relevant for Drupal 7 with tipplefips. Or TPLPHP files. You can go and edit the template file and do the same thing. There are also modules that let you control what output the fields are doing. Like I think the fences module and then if you're using DisplaySuite, I personally use DisplaySuite along with the paragraphs module so I have even more control on the interface. You can choose and say, I don't wanna see any wrapper divs or instead of a wrapper div, I wanna see a wrapper H1 or whatever. It's okay, this happened in another session too. Clowns are gonna bust in with balloons. By the way, one of the things that I love about Drupal 8 so much is that we can finally get rid of the euphemism tipplefip from our vocabulary. No, we need to make a new one. Hitmult Twigs? Let's not do this live. So we do have, we need to plug this. I think it's really important myself specifically since I do consider myself sort of an advocate for beginners and people like site builders. Everyone is welcome to sprint. You don't have to know code. There's lots of ways you can help with sprinting that it does not involve PHP or anything like that. We do also have all morning, tomorrow, and it was early as nine o'clock I think it starts. First time Sprinter Workshop. Anyone can come and learn how to use the issue queue on Drupal.org. How to install Drupal 8 on your computer. If you've ever wanted to do that, even if you don't wanna sprint, come let us and help you install Drupal 8 on your computer so you can work with it locally. It should be really cool. Both David and I are sprint mentors on Friday, so if you wanna just talk to us too, we'll be there. And really, I mean it's about making Drupal better, but really that's an ancillary benefit. The main reason why we do sprints is for community. And we want you to be there. And the sprints will be here. So you already know where here is. It's like the room right down the hall. Yes. Congratulations for being here. So we do have slides. These slides are available at bit.ly slash using dash paragraphs dash NOLA. We do also have a survey. It's just on our page on the DrupalCon website. If you could please fill out the survey. It really helps us with our feedback. We might be presenting this at a few other camps. So any feedback you have is really, really helpful. It also helps the DrupalCon choosing committee to pick sessions based on the feedback for presenters. So if you think we did really well, please let us know. If you think we didn't do really well. Even better, please. Yeah, we still wanna know. We can take it. We can take your abuse. We like it. Thank you. So we have a fair amount of time. And I know that we didn't cover everything we possibly could have. And there are plenty of questions. So I'm gonna put this back over here. If we can try to clear away the middle aisle and have this available for questions. Hi. Yeah, I'm curious how this works with views. With views. I need to write it. Yeah, it works fine. That's a, there's a caveat there. Oh, what do you mean by view? Like, is it simple enough to say I wanna pull the pull coat paragraph from node X or some version of that. How does that function? It's a reference. So that is, there's the technical possibility to do that. However, it gets a little bit dicey. Insofar as you're mixing different paragraph bundles and often if you are nesting content paragraphs inside layout paragraphs, for example, then the chain of relationships isn't always going to be obvious. It, I'd say that it's not necessarily the use case that you're looking for. If you're trying to very atomically grab very specific paragraphs out and use those in views. What I would suggest instead is that if there is field content that you mean to use that way, like for example, like you wanna have a teaser image, for example, that's associated with your piece of content. I'd suggest that you represent your teaser image as a separate field on your content type that is used just to indicate an image to use for your teaser image. Like outside of the paragraph module. Outside of the paragraph module. And there are reasons you wanna do that anyway. Like you'd wanna use that teaser image field, for example, as the OG image meta tag for Facebook. I mean, there are reasons why you'd want that to be structured separately from your paragraphs. So, yeah. Oh, there's a, yeah, we were talking about this earlier and it wasn't, we didn't get it into the slides. There's a lot of development going on in the Drupal 8 ecosystem especially for some of the modules that are like this. One thing in particular is that inline entity form is a really great module that exists right now in Drupal 7. The Drupal 8 version is coming out as well. Inline entity form does some of the same stuff in Safari as it allows you to add and create referenced entities inside of other entities. Which if you think about it is exactly what the paragraph module is doing. One of the things that is possible for the future of paragraphs is that paragraph module might become the content type of the paragraphs, but it defers to inline entity form for the widget for adding those things. So, I'm excited about that possibility myself because it means one last duplication of efforts that goes on on my site and in the community. And there might be some people sprinting on that on Friday as well and I'd love it if people could come and give some feedback or work on that anyway. All right, well the last person's question was my first of two questions. So, I was interested in the views compatibility. The other one is I've got one use case where the content editors and the content folks are pretty much addicted to tables. And I'm wondering whether or not we could constrain them using paragraphs to just insert a table and if anyone has created a good solution that would help. There is a module called Table Field. I don't know if you've seen it before. I've seen it. Yeah, so one of the things that you can do then is create a table paragraph that just contains a table field. Table field is a bit of a, so the, the, the. Yes, I have that reaction as well. But you know, that's also, it's a hard space because a table doesn't mean anything. It's not a structured thing, right? Those columns are, it's just a numbered list of columns. It's a, it's an, it's an array, right? That's all it is. And it probably got pasted in from word. Right. So. You know, that's where, you know, the, the, I work with a kind of bureaucratic world and they're, they're authoring either an Excel or Word and they're going to say, well, we want this on the website. How do we move it over? And so, you know, yes, you could create a multi-fielded entity that they're going and adding each cell and it creates a table and you could have a, a view field and pull it in and create a, no, it's not going to happen. I'd say it depends on what you need your tables for. If you're using your tables for, for layouts, then you should stop doing that. Oh yeah. And. Oh, it should. Yeah. In that case, you, you can absolutely create a paragraph space solution around that where you're maybe using layout paragraphs and content paragraphs together. But if it's for data. Yes. Table field is probably the solution that I would know about right now. And it does help to be able to put it in a paragraph because at least it means that you don't have to stick it at the bottom or at the top of your, of your node content. Yeah. But it's not a panacea. That's, yeah. Good luck. Thanks. What's the main advantage of paragraphs over field collections? Ooh. That is a good question. Seems like most the kind of challenges and things you mentioned here, I'm already using field collections, solving those problems. So. Is there something I'm missing? I feel like I don't know as much about this as you do, but I do know paragraphs started as a fork of field collections. So it is why it seems so similar. I think that the reason I like paragraphs more than field collections is because it does take it. It's a lot easier to use. It's a lot easier for me to wrap my head around than field collection. One time we talked about this and you could articulate it really well, but I don't remember. Yeah, so a couple of things. One thing is that I started with field collection in Drupal 7, and I haven't looked at it in Drupal 8, but at least with Drupal 7, the fact that field collection was named field collection made it almost impossible to theme a field, especially a field that was on a field collection. Like Drupal just got way confused, and then I got confused, and then Drupal and I weren't talking anymore. And we got a bit of a falling out, but it's okay, I broke up with field collection. Paragraphs additionally, one of the things that the paragraph module field widget does is it allows you to mix and match bundles, which at least Drupal 7 field collection, you had to only add another of the same type of field collection. So you couldn't have a text field collection and then an image field collection and then a video field collection. So that's mostly it. I don't know much about display suite and field collections, but display suite and paragraphs, have you used that, David? I haven't used display suite with field collection, so I don't know the trouble with paragraphs. Yeah, it works great with paragraphs. There was a buff earlier where we were talking about are people using field collections inside of paragraphs? And I think one person raised his hand and I think we made fun of him. So I'm sorry. It's not your fault, no one told you, but. And there are good reasons why you might want to use a field collection inside of a paragraph. If you want a structured bit of something that's pre-configured and I wouldn't do it, but you could. I think you would maybe think about whether you would want to maybe have another paragraph type of that thing instead so you could reuse the same interfaces, but. We can talk. Anyway. Sorry, yeah. So it seems like you give the editor a lot of control over the page and I kind of wonder, in use cases, what is going to be your separator as to when you use views, right? To display a list of pre-configured content. Like, let's talk about a staff page, right? Got a picture and a name and maybe a position in the company. So that's an image field and maybe two text fields that exist in a content type and they're just creating that content and it goes up in a view versus you giving a little bit more control to the user in paragraphs to recreate the same thing but with too much control maybe. So I kind of want to know your thoughts on when they control. So I think the scenario you're describing is like, one is you're using the content type sort of as a data structure where you're collecting the data and you're using it, aggregating it and spinning it out in a view. Whereas I think where paragraphs really shines is where you're creating the tapestry, the constructed page of content that's woven together in a display. Like, it is the display. I don't know that I would use paragraphs if I was intending the content just to be used in a view. Yeah, I think intent is a huge part of it and I think you're vision for what the staff page looks like, right? So if you think about the staff page or rather, if the content creator thinks of the staff page as just a page like any other page on their site that they want to be able to edit that way then it makes sense to give them the same interface. Give them a paragraph where they can put in a staff blurb, for example. If they're thinking of it as a piece of structured content that maybe Drupal would be good for, like something that they can have a teaser view of and then maybe go to a full page bio or they're collecting their staffs into a table of a staff directory, then that's a more obvious scenario where you'd want that to be a separate content type that you collect in views. So I think it's something you ask the person who's gonna be responsible for maintaining that staff page. Cool, I like it. I think we probably have time for just one more question. I think we'll take more. Okay. I was wondering about the structure, how you save things in the background. Is it all entities, it's all references? That's right. So it would work with the deploy module. Say that the client push a button and it just deploys to prod. And with all their different layout and everything. Because with a panel layout, you can't do that. Like the panel is not entity-based, right? Right, I believe so. I haven't looked at the deploy module in a couple months and I wasn't thinking about Paragress at the time when I was doing it. But it does handle references and they are basically entity references. One thing I don't know about is because they're entity reference revisions specifically. But I think deploy is smart enough to deal with the reference revisions as well. So yeah, I would love to know if you try it and get it working if you wanna contact us. I'd love to see. Awesome, thank you. All right, thank you. Like I said, that'll be the last question but please come on up and we'll take more as we're packing up. Thank you guys for coming. That's amazing. Nice. Yeah.