 Hello everyone and welcome to my presentation about defaults, cloning, referencing and content prototypes and the editor's user experience for similar content creation. I'll say a few words about myself first. So my name is Simo Helsten. I'm a full stack developer at Druid in Finland. I studied computer science in Helsinki and Tampere universities. My first Drupal site went live in 2007. That was Drupal 5 at the moment at that time. I'm a member of the Drupal UX team and I follow Drupal accessibility issues. I also participate in W3C Cognitive Accessibility Community Group and the Nordic Accessibility Group. I'm a member of the International Association for Accessibility Professionals. In my free time I train with Japanese weapons and play with fire. At home I have waiting for me four dogs, four cats, a spouse and a daughter. You can see one dog and one cat in the picture. Depends if it's feeding time. But about creating similar content. If there's something that computers are great at, it's automating things. But still we do a lot of things manually when we use those computers. Many of us are still used to copy-pasting information from docs to a web page. And often we sometimes have some kind of a text where we copy-paste things to several different pages. And sometimes we need to create a lot of content that is almost the same, but not exactly. Like maybe some customer certificates, time-bound products or targeted newsletters. Or things that are the same and parts that are different. And in this kind of things automation can help. But there are different kinds of ways to automate things or make things semi-automatic. So some of the cases where we use this kind of content replication is when we have a partially same content that we use for grouping pieces of other stories. Like it's very common to use taxonomy terms to group different collect blog posts or articles. And sometimes we include short biographies or contact details or some other additional information about the author. So that's kind of using the same content over and over. And that's where we face a challenge when information changes over time. So when the author gets some new role or new information that kind of relates to the new content but not to the old, what should we do? So there is a real life example from a few years back when a program assistant in Zambia wrote news stories to the organization's website. And nine years later the same person was hired as an assessment specialist in the Helsinki office of that organization. And her new role and the content she published was very much different from what she had done before. And we ended up with a dilemma. Should we use the same public profile for the author or different? And how it would affect the nine-year-old stories that were kind of the topic was quite different. And in a way choosing between that kind of fixed content or references or maybe referencing specific versions of content. Mostly it's editorial dilemma, but there are tools that can be used to manage that in the content management system and there are some differences. So here's a kind of a graphical example of the same situation. So we have the author sport with a six-month-old doghound terrier puppy. And he has written two blog posts about experiences from the puppy class. And the profile is referenced there. And five years later sport the doghound terrier is a specialist search dog and writes about the work or like the days of the working dog. So there is a kind of a... It would be difficult to understand puppy class experiences if it would be written by a professional working dog or working dog's life if it would be written by a small dog puppy. Another case where we use similar content is when we have products that have variations. So Drupal.com has a certain support for variations, but this is not the same thing I'm talking about here. So if you have a commerce product that is a dog training class, and people are searching for certain kinds of classes for dogs, and then they have the same name, but there are some differences in the content. So if a dog training class is called puppy class, it's always a course for puppies. It's about basic skills, but there will be some kind of differences there. So sometimes there are changes in the content, in the descriptions that need to be updated, and because some research suggests that some methods would be better for dogs than others, and then we already have sold these kind of classes with the old description, old content, so we don't want to change the information in the old product because if the clients want to reference what was promised and if they got what was promised. And there can be some kind of variations in dog training classes like breed specific class, or sometimes it can be a bit longer or a bit shorter class. And then how to update the classes that are coming in the future and how to manage that kind of content creation process. So that it will be easy to create similar content, but also to keep the old information in the old products. And, yeah, so is it possible to update some of the content with the shared information, but keep content the same in some other that have used the same content. So, yeah, graphical example. So there are different kind of variations for puppy class, so some classes might be outdoors, some indoors, some might be for certain breeds, and some might have long, shorter or longer duration. So there is variation, but most of the content is the same. And then we sometimes want to combine fixed text in content with some kind of variable content. So we might have some kind of newsletter template where we have fixed content and then we pull in some kind of a view or some kind of different kind of information. And, like, we want to store it in a way that is archivable so that the kind of same parts don't change. And there are different kind of ways to use, reuse content and some of the modules I've looked at, they use kind of a mixed terminology. And I kind of, here I a little bit take distance from Drupal terms so that it will be more, a bit more generic. So I call pages, this kind of nodes, terms, products, this kind of a fieldable entities that have their own URL. So I kind of call the basic content, I call page. And I call fields, this kind of atomic parts that are page content. So that's kind of more or less the same as Drupal field. And I call sections when you kind of have a combination of fields that might be put from another page or like if you have a term, taxonomy term with fields and you pull it into a page, then I would call that section. And I call source the original page or that's either duplicated or referenced. Yeah, so whether information is stored that is going to be reused. So the most basic case of reusing content is using field default values. So field UI, that's in the core. So it's kind of always available in Drupal. And it can be sometimes very useful for simple things. But it can be hard to update, especially if you have users who don't have permissions to manage fields or content types. So it's kind of managing the field default values. It's something that requires quite a high user permission. And when you use field default values, if you want to change those defaults, it only affects the newly created content so you can't update everything you have already done. Except if there is a module called field defaults, that's in alpha stage, that can update those change defaults to different content that uses, or content that uses those field values. But it's a very rough method because it doesn't have very fine-grade options to update. So it kind of updates everything, but it's possible. And another very common thing what we use is referencing other content. So this is just when we have taxonomy terms, we reference images, we reference other pages. So we can pull information from other entities. So we have pages that use other pages as sections inside the kind of content that is shown to users, like the views. And here it's very efficient in a way in the way that it keeps the information current when you edit the section or the original source or the information where it was referenced is updated as well. But this is kind of if you have a lot of content and a lot of references and a lot of editors, then they need to be able to keep track where the content is used. And if somebody updates content that is referenced in one place and doesn't realize that the same content is referenced by another page, then it can get a bit funny sometimes. And referencing other content, we have some special cases, such as layered bill or blocks that can be referenced and can be reused. We have paragraphs that are usually not reusable, so we can't easily reference other paragraphs. But there is actually some modules I introduce here that can also do things with reusing paragraphs. And then something that is more versatile to do in Drupal is, oh, I changed the order. So cloning fields from content prototypes. So this is something that doesn't actually yet have a module, but it's more of a concept. So this is something I'm working on a website that has this approach where I use field values from different content so that it copies the field values to the content form. So this is kind of a combination of referencing and field defaults, but instead of using field defaults that are set in field UI, it uses values from different pieces of content. And this is a way how we can separate the permissions for updating values, default values, and we can use a selection of different default values, and we can also combine different sources for different fields. And this is done by referencing the original source, and then it copies the values to the edit form, and then after the new content is stored, then it kind of cuts the connection. So editing the originals doesn't change the piece of content, but it keeps the reference so it's possible to implement a feature that updates select fields. But then the most versatile method of using same content is cloning entities. So cloning entities and editing is one approach to do this. And here we have several different modules that do more or less the same things, but with very different flavor. So one of the methods of cloning is to copy everything from the original source and then save it and then edit that page later. In this method there is a risk, because if to have duplicate values, because if it copies everything, there might be some different kinds of IDs that come from outside Drupal, some strings that should be unique, but need to be added manually or from another source. So like for instance in some medical database, like a pharmacological database, there are different kinds of IDs that are used by officials and it's kind of not easy to handle those through APIs. So in that kind of things there is a risk that the editor forgets to edit a value that was cloned. So because it looks like it's there, it passes validation maybe, but then you would have two same values. And here when you use cloning, you can have many sources of information. So when you have the original that you use to make copies of and start editing them, then you start having different branches and if you want to combine information that's in them, it can be sometimes difficult to decide which one to start working on, but it can be also a strength to have this kind of multiple sources available. But that's one of the very dangerous parts I think with cloning and especially with cloning entities as such is that some of the modules that are available, they clone the entity and save it as published version. So that's something that happens with several modules that can do cloning, but I'll come back to that later. Another way of cloning entities is to copy, like to copy all the values into the same type of content or same type of page, so that you end up in the create form, creating a new create form with the field values copied from the original source. And this is not so dangerous because then it doesn't automatically create published content, but still it has the risk of duplicate values. And here also the editing of the original source doesn't affect the later versions. And this one also has the question of which version to start working from. So here are some of the modules that do cloning. So there is entity clone that is a beta version, there is content entity clone, entity copy with reference and replicate that has at least three different user interfaces. So replicate UI, entity bulk clone and page templates. Those three are such that they use replicate and then there is cloner that is in alpha stage and both replicate and clone they don't have user interface. Those are something that developer can use to build their own ways of doing the cloning. And here is explained a little bit about the different differences with cloning and the status of the content because we usually like to keep the unfinished work out of sight. So here we have that original page that has been published. And then the quickest way to clone content is to just clone it and there will be a published clone. So this is the default method for replicate. And also because there was that bulk version user interface that bulk clones nodes with replicate it's possible to publish a lot of clones at the same time. So that's something that user needs to keep in mind that you should maybe clone things that are not published. Then some modules do so that you take a published page and then you clone it and it is still published but it opens as edit form. So then the user doesn't know that it's already published because you have it open in edit form. And then you can save it either after it has been published and after you edit, then you user can choose if it goes unpublished or published. But that's something that's kind of confusing for the user that you can open a page in edit form and then you don't know that it's already saved as published. Then there is also one option that this is actually the page template module that refuses to accept sources that are published. So you have to first save the original as unpublished then you can convert it as a template and then you can use the template to clone. So that's something that's safe but it can be a bit not so effective sometimes. At least it doesn't publish anything without asking. So this is something that's very important to remember. And then I have a rough comparison of different ways of replicating content. So when the source changes how these different approaches behave so when you're using field values by default when you change the default values none of the content that use those default values changes so they just keep the values that were stored on the pages. And when you clone entities or clone pages then when you edit the source also the clone doesn't change anymore. When you reference other entities when you edit the source also those pages that use reference to that source they change. So that's kind of the referencing it's the only one that keeps content up to date. And with content prototype it behaves just like field default values but as the kind of the reference to the original piece of content so it's possible to implement a method that updates. And this is kind of the same thing that diverging from the source so that when you have default values when there is only one source of truth when you create new content it only uses the values that are currently stored as the default so it's kind of diverging from the original it happens when the original is changed. With clone entities you can end up with different kinds of versions because each new version can be used as a source or usually each version can be used as a new source so you can have different kind of like different kind of branches there and with referencing entities then when you change the original everything changes at the same time so in that sense there is no diversion caused by editing the source and with the content prototypes basically it behaves the same way as field default values and with permissions different ways of reusing content require different kind of permissions and if we want to use field default values which is the most simple one the permission is the user requires for updating the defaults managing fields and that's a very strong permission so that's something that is not very useful for maybe big organizations at least and then again with field defaults you don't need for creating a new page you don't need any extra permissions except to create that kind of content type with cloning entities the original sources are created in the same way as just any content you create afterwards and then you need for creating new pages by cloning you need permission to do that cloning actually you need also permission to view content that was created that's usually given that users can view the content they edit but it's not actually compulsory but for cloning you need to be able to see what you're cloning and then start cloning it and that's a little bit different permissions for different modules and then you create the content when you reference entities you need to be to create the sources you need to be able to create and edit those kind of content types or that kind of type of content you need to be reference and when you create new content you need to be able to view those so that on the form you can reference them and the same goes with that content prototypes because content prototypes uses references for choosing the content from which to copy field default values so when things can go wrong cloning references is something that it can sometimes be a bit complicated because when you clone content several of the modules also clone the references and the user needs to know what are the different kinds of dependencies if there is reference content in the new clone the same references exist in the original so you can't go changing them except some of the modules do so they give option to duplicate the referenced items and that's something that also kind of can cause problems if the editor clones a piece of content that has some taxonomy terms tags and checks box that says make a copy of these terms and then you end up having duplicate tags in your taxonomy, that's also possible and the big thing I mentioned already before and mentioned it again saving clone before reviewing it and saving a published version of the content before giving user access a possibility to review it so that's something that is kind of scary and then it's possible with cloning it's possible to reuse something some kind of an ID string or something that might pass validation but if it's not validated so that it needs to be unique so it's usually better for this kind of string so this kind of values to be able to skip those and it's better to have them empty than to have duplicate values in some cases and yeah, the other side did it like there are different kinds of ways of cloning inside Drupal several different modules so it can be also user interface is different and what they do is different so it's very important for users to know how this site does it and it's something that you don't if you done cloning on one Drupal site it might work quite differently on other if you don't know which module has been used and having limited access to content can cause problems so that the user doesn't know when there is references to the different pieces of content then if the user doesn't know where that content has been used and decides to start editing that kind of that section that has been referenced so it can cause problems and yeah, I didn't find anything that could do clone a node or clone a piece of content so that it would clone some of the reference entities but only reference some so that's kind of a fine-grained version I wasn't able to find I'm not sure there might be something somewhere but I didn't find it and yeah, and when your clone translated content then you also have a kind of choose between two options one is that you clone the whole thing so that you store the entity that you have a let's say English version and Finnish version and then you clone it and then you have English clone and Finnish clone and that's something I don't like because I'd like to see that the content comes to the edit form first so I can review it but of course you can't have two languages on one edit form so you have to choose either having the possibility to review or the possibility to have both languages cloned at once so that's kind of a trade-off so as a summary creating similar content can be done by copying entities into new entities field values to the add form entity add form field content or copying one source to one content or many sources to one content and copying only references or replicating the reference entities as well so there's a lot of variation and yeah, and the best approach how to do it depends on the need to if you need to update multiple content at once so that's with translations or maybe something else and then maintaining single source of truth there is variation if you have single source of truth or if you can have different sources from which to clone and then being fast and never mind the risk so this one relates to just cloning and publishing right away and bulk publishing clones so this is something, sometimes it can be useful but if you have a development site that's not public so you can start building it quite fast and if you need to divide permissions on editing the source and creating new instances because usually, well I didn't mention it I think before if you use cloning you usually clone the same type of content and then you end up, you need to give permissions to do that something like content prototypes you can give permission to view the originals but not to edit them so it's kind of, different methods can use allow to kind of make different permissions and also page templates module allows you to like restricted viewing unpublished content so I have here some of the different ways of cloning so replicate UI this is usage replicate module and with this one the problem is that the replicated content is published right away if the original was published and it's possible to do some configurations on which entities are cloneable with content entity clone it's possible to skip fields so you can choose which fields to clone so this is something I like myself so you can choose which skipping fields so it leaves something blank and this one doesn't I think this one was also so that it doesn't create and publish the content but fills the information into an ad form so this is kind of safe and also the local top so they usually have those tabs either view page either viewing the content or editing the content they had those tabs where you can choose cloning and this is also something that it's a little bit different because some modules only have the link to cloning on the view version of the page and some only on the edit version of the page so there's also that if some user is used to one way it might be hard to find where to click the clone button entity clone this one would be quite powerful you have all those different options to check different configurations but I didn't quite figure out what all those configurations means but this is the module where you can choose if you duplicate also the reference entities so you can duplicate taxidermity terms that may be not so useful but you can also duplicate paragraphs so this is the one that can duplicate paragraphs but it also gives you option to use paragraphs without duplicating them and it has a long warning text that if you have a paragraph field in your entity not to clone it here deleting the original will delete the paragraph in the clone so that's something that I think is quite dangerous but at least there is a warning text but nobody probably reads that but this is a very powerful one but to me it feels like the user interface is a bit difficult to understand and then there is quick node clone which is a very simple approach it just clones the values into a node form and that's very simple it feels very safe only that it clones everything so you can't skip fields from cloning but this is a very simple one and then we have entity copy with reference and so this can either reference or clone the reference entities I think so this is something that but this is kind of it's not per cloning as with the other module but here you can kind of per I think it's per content type you can choose whether to clone or clear or keep the references but also here you can't choose to keep some and clone some and then page template is also using replicate but it has a kind of a I think it's quite intuitive interface so that it forces you to unpublish the original first and then you can convert the original into template and the editor can from the like creating new content and choose to create from template and then it's kind of a the process is kind of a it's not straightforward cloning and it's a bit more safe than other other cloning methods using replicate module and entity bug clone is so you can clone a lot of different like from the content at least you can clone lot of nodes at the same time it uses replicate and therefore it keeps the published state so if you clone bulk clone 10 published pages you get 10 new pages that are published already so this is where the cloning