 So it's six minutes past, so I guess let's start. So you already know why you're here. What we're gonna talk about today is who I am. I wanted to have some code examples in GitHub. The repo is there, it didn't turn out exactly as I wanted to, but still welcome to have a look at it. An introduction of what paragraph C is, some advanced use cases, and if everyone is interested in contributing back, how they can do that. And then we probably have a discussion. I'm open to hear suggestions, questions, and anything in between. So who I am. My name is Tathros Kutlas. I'm Senior Technical Consultant at Cameron Wilding. Over the years, I've been involved with web projects, machine learning things, image processing stuff, administering systems, and I'm a scrum master as well. The GitHub repo I've set up is on my GitHub account for Drupal Khan London. There's some automation going on. There's a script there to set things up. And my intention was to have different branches with different configuration, now that we are all Drupal 8. Well, yeah, use it at your own risk, basically. And yeah, if you have the script, except if you have multiple versions of trust as I do, you can pass it in so you can get all stuck. So what is paragraphs? I like to see it as a way to add components in a page without to have to add individual fields. It's like a field collection, but better. So usually, especially in the Drupal 6 and Drupal 7 days, what we used to when we wanted to create a content type or we wanted to depict some content on a page, we created different fields. And that was a good approach, but as content grew larger and larger, all the actual needs of organizations in terms of content grew, then we needed to accommodate more fields. And then we ended up having edit forms that were massive. That was on one hand. The other hand was to give the editors the full experience in a way or full control and give them a CK editor instance, for example. And then we usually ended up with markup that wasn't really great to work with. So paragraphs comes in between of that. They provide control structure, but also you get a useful editing experience. And they allow some creativity and assembling a page to the editors without sacrificing that structure. And an added bonus to it is that if you are into working in an agile way and you also have atomic design principles within your code, then you can tie these three together. So you can have really small granular pieces of functionality delivered within a sprint that follow those atomic designs, but in the backend. So you can have a component doing one thing. And then you can style it separately in your style guide and you have your commit and that's your story and you commit that, push it to production. So before we go to the advanced use cases, let's have a simple example. So let's imagine we need an image in our code, in our content type. So the easiest way to do that is create a paragraph, a component with an image field and the caption field. And we can get something like that. So that is within a node and that is a paragraph type or I usually refer it as component in my talk. So you can add as many of these components as you like. So if you want multiple images, you can add more. If we just backtrack a bit, if you just enable the paragraphs module, then you can see there's a paragraph types, menu item within structure. And within there, there are all the different biograph types. It's exactly the same paradigm that you have with a field collection. So you have a separate entity that is accommodating fields. The main difference I see is field collection is always the same set of fields whereas paragraph types is different fields. So you can have any of these and you can add your own. And by adding your own, you just create, you go through the same process of creating, adding fields to a node. So if we put that together at a node level, then we have our title up there. There's down here a dropdown menu that has all the paragraph types that we have or the components that we can add to the page. And then we can select components. In this particular example, we have an image component and then we have a text component. So that part and they are draggable between them. So you can switch the order of them and do whatever you want with them. So essentially what you end up with is a way to display an image to a page, a caption of that image and then a way to display some text. And that's okay for most of these cases but the real advantage of using paragraphs is the control that we get. So what if we wanted to extend the components that we had and we wanted the block quote component by just going back into the HTML5 specification, you can see that the block quote is an element that represents content that's quoted from another source. It optionally has a citation and which should be within site or a footer element. Essentially, come on, we want this. And I don't know about you guys but when I was working with frontend in Drupal 7 especially, having just that in the frontend was really painful. So let's see how we can do that. First of all, we need to add another component. To add a component, we just need two text fields. One is for the quote text and one is for the quote citation. And that's it essentially if we just add to those two fields. But if we add content to them, then we end up with that HTML. These after all are text fields that Drupal knows that usually are placed within divs and paragraphs and they have, well, paragraph tags, I mean. And that CSS is applied on top of it. So we still didn't get that. So how about we go to do that? Exactly. So that's where power of twig comes in and the eight. Essentially everything is a template. Everything is overwriteable. Every entity gets a template. Every bundle gets a template and every view mode gets a template. So that's quite a lot in our arsenal. The solution to that is to have a field HTML twig. That's only an example for this particular talk. Maybe you need some more logic in that template but works well for this instance. So you just list out the content of a field and then you create a paragraph block code HTML twig template with exactly the HTML that you want and you rebuild your theme class. Then you get this, which is much better from an HTML file perspective. So where does that lead essentially? That leads to us having full control over what the HTML generated is and also create really rich experiences with it. So we have a way to create exactly the HTML we want while giving the editors the power to add any components they want. And we do that within one single content type. So essentially we can use one content type or many depending on the use case but the simplest form is use one content type and you can create all those different HTML structures within your pages. And that's where the real power is. In this particular example, you can see that there's a title, there's a hero image, there are several subtitles within and text and images that they are full and block quotes and text with images on the side. And that's quite complicated but you can get that from just one single content type as you can get just the title and the piece of text for a press release. You can get that or you can also get a landing page. And I think that's where the power of paragraphs lie. So just to summarize that, you can compartmentalize your code. You can follow atomic design principles but on your backend. And that works really well when you work in agile projects to align front end guys with backend guys. You can reuse your components obviously. So when you have a paragraph component within a paragraph field within a content type and you create another content type with a paragraph field in it then you can reduce, you can choose and you use your components in there. So essentially you create once and you can use in multiple times. And you have way better control on the accessibility of the page that you're creating and you follow standards, you can follow conventions. Essentially you have full control of the HTML and the markup that's produced. And I think that sums up the introduction. If we leave it at that, we get to a point where we have really nice content on the page but nothing more than that. So the second trick that ties really well with view modes is linking content between different parts of your site. So there are two ways of linking content. One is manual which you can do that with empty references. And the other is automatic that you can do under certain criteria or contextual filters or filters in general through views. So I'll talk briefly about these two as well. There are some challenges ahead for paragraphs and how we can do that but there are some solutions already in place. So at the node level there's entity references. So you can reference other content and at the site level there are views. The nice thing to remember and to keep you in your back with your mind is that views are entities in Drupal 8. They're not content entities but they are entities. So what if we had a related content widget just as another paragraph type as another component within our paragraphs. That can look like that and you can link content. That is a manual procedure but essentially if you want to create something really simple you can have a site that needs a landing page with a few out onwards journeys and the content page that they can accommodate text images and some fancy slideshows. Essentially you can do all that within one content value. So you have that use case. Usually an entity reference renders as a link by default in Drupal and that's the case in both Drupal 7 and Drupal 8. That's the HTML that's produced. So that doesn't really look good for a particular landing page so we need something more. That comes from the field formatter. The field formatter can have a rendered entity and where the really nice trick comes when you have that rendered entity you can reference specific view mode and as such specific view mode gets its own template. So essentially you control that HTML too and you can get really granular. Well, I'll move on. The second is views. So what we saw on linking already was that you can get your content you can link to it and then you can have a template that controls how that depicts. But views are, well, sorry, I got confused. That's about view mode still. When you work in Drupal 7, view modes were really difficult to add in a site, essentially. You had to create a hook, an info hook and then you needed to do that through code. In Drupal 8, they are first class citizens. We have a view modes interface that can allow you to add view modes. Essentially, what you do there is create a new view mode and then on your field display you can go and say which fields are gonna be available. When you do that, then you can create a template and those fields are there and you can use it within your HTML structure. So essentially, part of Sanity Reference and ViewModes are best friends forever. You can manually link content and create widgets. You can replicate your markup that you want and you wish and you can create reusable facets of the data. But if we move on from that, we need automatic ways. I mean, it's nice to have a small single site that you can link content between but usually that leaves a large part of Drupal sites out of the equation because lots of us used axonomies to create different linking strategies and then use views to use that linking strategy within pages. So as I said before, views are entities in D8. They're not content entities though. So there's no display format at the moment that you can render a view. I was searching about that and there's the views field for MatterMozul. It's not a perfect solution, but it's good enough if somebody wants to start with it. And what that does is you can create an entity reference field that references a view and then on your formatter, you can have a view and then there's a dropdown menu that you can select any view from the system. What that essentially does is a small hack. You create a field and then you say that the formatter is a view and then you have all the views that are available in your system and you say, please render this specific view while actually you have all the displays from the views available in your system. So essentially you render a display on that field. There are several, so if you reference content there, you can have the content ID, the node ID passed to the view and stuff. So you can use it in a relation. But then again, it's still a simplified way to create that automatic linking. So that's how it looks in the node. So you have a views reference field. You can choose which view you want, but then essentially that is not controlling the output. The output is controlled by formatter and that's the problematic thing about that. The one big advantage though that you can have either way is that views like view modes already. So if you create, on that show there, this content and this fields, that's the two options that you usually have. So if you use content, then you can create, you can choose which view mode you want and that's the one that I created before related content. So essentially I can end up with the same HTML regardless of how I'm choosing to link content. So I can get really granular strategies how I can assemble different content from other places of my site within my content type and please remember there's still one content type. So what's missing? The views field from other is from the seven and in the seven views, well entities. So you install the available displays that you have, you pick one and you stick with it. So essentially you wanna add different views in your system, you need many different fields. So the next thing is, I mean now we have an entity reference field that can reference a view. It would be nice to get that view and then on your code item or your code icon, you can say, okay, I know which view is that. Which display would you like rendered in this place? So that's essentially where we want to go with this. It's not there yet, but there was a slide about contribution guys, so you know. So just to see how that can materialize in production. Please bear in mind that this is a D7 site. Let's see how a hero image paragraph can render. That's a hero image paragraph. Somebody, an editor can go into that site and the title, say I wanna hero image and there it is. I want some text with an image on the side and some text and that's there. Or I want the subtitle. And if I cannot backtrack for a second, that subtitle creates that little widget there. Or I want to create a reference content widget with a subtitle and that's other pieces and that's a specific view mode from another content type that is referenced there. So how to contribute? That's the paragraphs issue queue just right there and the views filled from other issue queue and spread the word, start using it essentially. It is, it's a way to liberate yourself from having to have like multiple content types and you can give the freedom of expression to your editors. I would like to thank you for your attention and please we have plenty of time to have some discussion around impressions. So thanks very much. The slides, but it's the, yeah. What was it? Whoever runs that code, please bear in mind this is the eight trying to do something complicated. They are, yeah. Please. So the best I can do is this one. Well, give me a minute. So that's the best I can do or the closest I can do. Essentially what you get is your title up there and you start with this drop down menu. So if you click that arrow, downwards arrow, then you have all your paragraph types that are listed there, there. And once you click one on one, then you have one component added. So that's, there's a slight line here that separates these two. So essentially you see there are two here. So we get that. So essentially you can add as many of these blocks as you want. So if you remember the HTML that I did with the article, it's essentially replicating that, but on the front end. So if you have, let's say, a text paragraph, a hero image paragraph, a subtitle paragraph, and a full width image paragraph, you don't dictate where anything happens or you don't dictate how. You don't have anything that is hard coded. You just say how, when the node renderer will see that content, you just say how that's gonna be rendered. So all that experience is given back to the editor. I found from experience that people can be really accustomed to it. One of the shortcomings is some of them, they ask for two things. Well actually, and it's shortcomings in the paragraph modules in general. One is that you don't have the concept of a required field. You can have it within a component, but you don't have a required component. You can't say that this content type at least needs a text paragraph and hero image. So usually, that's why usually hero images sometimes, they make it in their own separate field, but yeah, there is some discussion around addressing that. The second is some editors that are really lazy, that's my opinion. They just want a skeleton, a pre-built sort of node with that flexibility, but have some components pre-built. So you can have like a text component with the full width component and another text component instead of just clicking that and doing three clicks. Which is something that we, there's also discussion around addressing that, have like a saved state of some sort, but we don't, yeah. I mean, there's no plan yet, but it's something that comes up sometimes. Other questions? Please. You add a new paragraph, copy paste the image, the text, and then you can remove it also. So you just, and that's in place removal. So if you had the third one and you removed the middle one, then you would end up with two. So yes, there's no such thing as shopping between, please. So we are the process of doing that. I can disclose for whom, but it's a large publication in the UK. And they had, we are just phasing in paragraphs, phasing out fields. And we'll do that on the live site as we go. Sorry? Well, they want lots of deployments, but I can't, I don't think that's necessarily bad. So in Drupal 7, if you wanted to unlock, or if you wanted to create new view modes, so Drupal comes with a few modes on its own. So it's the full node, the teaser, RSS, search, something else, I don't remember. So if you wanted, for instance, a paragraph view mode, or a related content, so you could say, you could create that widget on the examples. So you can say that the title of that, I want it to be an H3. There's a small text that I want it to be within a site element or whatever. You need it to create a separate module and sort of like tie your new view mode within the node object. So that's how you do it. It wasn't massively complicated, really easy to implement and doing it. I've read, I've actually written the documentation on Drupal.org on doing it. So yeah, there are a few, but I mean, if you value your not having another dependency on another module, then you can just write your own module that is like a very simple hook-in for implementation. But yeah, obviously there are ways to allow people to do that. I've seen you. Can you repeat, sorry. Can you repeat your question, please? Yes, yeah, so for my, I mean, I was ready to use it in production, but for other reasons I couldn't, that project didn't go through. But yeah, yeah, I mean, if you see the issue, there's no massive things in terms of the core value proposition of the module, if I'm allowed to say so. But there are a few things on extending it, please. Yeah, well, I had the same problem with it. I created a free processor basically to create tokens from the paragraphs. And then I had those available within meta tags. And that's how I solved it. Yeah. Yes, yeah, the only short answer is yes. I can see. Well, there have been suggested other methods of going at rich web content. And I can't remember the name, but the guy that does the DrupalizeMe videos, it's a fit. So he had a DrupalCon presentation last year in the US where he explained another strategy of creating tokens within your blob of text and then have pre-processor substitute content for that. It sounds a great idea, but I have tried to do something similar like long ago in this six. And what I found out from that approach then, which I think still very much applies now is that you don't keep the semantics of your data. So if you want to port that into something else, then you don't have the semantics, the semantic information. So, well, there is no easy answer to it. I think by having it separate though, it might be a little bit more labor work, but then you have some of the benefits of creating when you need to port that into another system, export it in a way or port it in another Drupal version, then you can have a very easy way to do. And I think that's more important in some situations. Anyone else, please? No, no, I mean, the performance issues from the back end, sorry, yeah, I mean, essentially is how many text fields you're gonna load with the CK Editor instances. That's the only problem I see. We haven't had that. How did you solve it? I think, yeah, probably, yeah. I think probably that's the best way to go at it. Yeah, yeah, separating them out and then loading them on demand. Essentially, if you do that, then everything is load at the same time. Well, it's a great tip, thanks. Well, yes, it's the failure of that repository working really well. You can experience it yourself by just trying to follow the directions or the readme of the repository. So essentially, it's not paragraphs in CMI, it's probably my failure to actually trying to do too much with the branches, essentially, and some of the CMI components got in a bit scumbled. Essentially, my experience to now, we have two D8 sites in production and CMI is working really, really well. It's working, essentially, it's working the same way that features work, but it is a different mindset, basically. It's a different thing. You just need to let go of features and understand CMI, but essentially, you end up having the same thing. You can export configuration and you can import it through different means. Anyone else? CMI is the, it's outside of the scope of this presentation. It's the configuration management initiative. Essentially, it's how we refer to exporting configuration in Drupal 8. It doesn't make sense because it was an initiative, but then everybody still calls it CMI and it's just like exporting the configuration. You can export like paragraphs, they are entities, so it's whatever you expect from entities, like blocks or node types and fields, it's exactly the same thing. You can export it, import it elsewhere. So if there's no other questions, thanks very much for your attention. Thanks for being here.