When there's not a module for that

>> BEN MELANÇON:  Beautiful.  Thank you all for coming, the long way.  Every person traveled to come to MidCamp in the air, mid air camp is what I've been calling it, presenting on when there's not a module for that.

My name is Ben Melançon.  My would be co presenter Mauricio Dinarte is ill and cannot make it, it's not COVID 19 but I'm hoping he does not catch that in the hospital.

You can find me @mlncn everywhere online, Drupal.org, Twitter, et cetera, et cetera, and Mauricio is @dinarcon most places and together we are 1/3 of Agaric.  Agaric is a worker owned we development cooperative.  You can reach us at [email protected] and I'm working alone, I'm a little behind on getting the attendant resources I wanted to get to go up with this presentation, a whole blog post with really well documented links for all this stuff.  It's not there yet so you can email me at [email protected] and demand it.  Again thank you for coming to mid air camp.  When building a Drupal site, there's a module for that can be a sweetest words that you hear.

What you need is right there but what you do when there's not a module for that.  You make your own.  It's easy.

Say you're creating a site where people can relive great literature that may have been inspired by also times of great hardship.  And you are, you know, you like it.  You've got your content tight.  You've done this through the UI like you always do went to structure content and created a content type but let's say your button isn't speaking to you for your new content type Frankenstein.

So how can we change that?

You can do that with two files, a total of four lines each, and that's counting the opening PHP in the second line.

Your, the first line, the first file, is info file.  You always need that for a module, and you always name it after your module so whatever you created a folder, you give that a name that only has lowercase letters and underscores, and then you create a file in that folder with exactly the same name as the folder, with dot info dot yml after it.  I give it a name.  A type module.  The description is completely optional.  Don't need that line but it's good to have and then the core compatibility which would usually be the 8.X but now we're the cool kids and we can say it's either 8.X or 9.X and you can be pretty sure it's going to work just the same for everything I'm going to show you and for most of the other work you need.  So it's a great time to make a module.  The upgrade path is really easy.

And then the dot module file itself. 

You can    you get into Drupal the old fashioned way with hooks.  Drupal has throughout its code base has things that call out and say does anyone want to change or do something here?  A lot of those are alter hooks and you can get into an alter hook with a special name.  So Frankenstein.  We're doing a form alter on a form named node Frankenstein form and the only variable that's used is the form.  It's been passed in by reference, that's what the & is doing and form, action, submit, value.  We're changing the value of our button to, from save to reanimate.  And the good news is that that just changes the text label.  It does not actually change anything the way it's submitted so we're not breaking anything by doing this.  Most important thing, where to put the files if you're doing custom module in your code base.  You'll see core, files, libraries, you put it in modules.  It's simple in Drupal 8 and 9.  I recommend creating subdirectories, but Drupal will look everywhere under modules and find it so you could name this anything.  You could call it my special module site specific whatever you want but contrib custom is a good one, and voila, our form looks exactly the same.  Enable your module, if you're using drush, that slide was the most important you'll be shown.  Enable your module after you start writing it and boom, we have our form with reanimate.  All done, you know how to make a module.

No, so. 

You're sitting there thinking sure it's easy if you know the exact words and symbols to put in that file and you're absolutely right so we're going to show you how you can figure all of that out.  Looks great if you know exactly what to write.  How do you get to the point of knowing what to write?

The examples we'll show including the one we just did, we'll talk about that for a second more, a few basic approaches give you a lot of power.  So with these specific examples about form alter, so that's the most important thing to know that if you see a form, and you want to change it, you can do it with a form alter and that gives you, like, that first step to be like okay, I can find other examples.  I can find documentation.  I can find help and see how others are doing it.

It's way better than starting out with just like, I want to change a button.  Like, that will give you a million results that don't help you, knowing that if it's on a form and you want to change it, you want to do a form alter, you can get specific results.  But before going further to these specific examples, which we'll give a lot of practical tools, two secrets.  One is good news.  Second one is bad news.

Now you know where to paste.  And knowing where to paste unleashes the power of Stack Overflow, Stack Exchange.  Yes, that's the family of sites that has helped a couple million Developers figure out how to quit Vim but you find something on the Drupal.org forms, or Stack Overflow, knowing, like, just how to make that code interact with your site, you now know enough to be dangerous.

And then that simple form alter has a few gotchas, that only applies to the create add form, not the edit form but you only want reanimate for the first edition of the monster anyhow.  You don't need it on the edit form, but, you know, the form alter documentation goes through, you know, how to identify what form you're on, and then you'll see when you look at it that it's actually different form ID, and then there's other    there's a lot of complexities in how you can deal with forms but it's all been done.  You can find examples, and do it.  So if you need it on both the add and edit form you either use two IDs, or else you can use the base form and load the node and check what type the node is, and then change the form based on the node type.

And, yeah, there's tons of variations to that form alter, and all are valid.  There's always many ways to do something in Drupal.  With our dirty secrets acknowledged, on with the show.  We'll start with how not to make a module and that's how to find one so that you don't have to make one because that's always the easiest module to make is when one you don't have to make yourself and then how not to have to make a whole module, how to contribute to an existing module, and then how to make a module which we just covered and how to figure out how to make a module, so more on where to look for those resources.  Really useful things, form alter, node insert, block, and formatter so hooks is one category of thing and we'll look at a couple specific examples.

Plugins is a whole other category of how to change things in Drupal 8, block and formatter and then if we have time we'll go into services, which is still another way to just change what is there in Drupal.  Drupal is like the    has the most capability of you modifying it, while still keeping the core intact and the same and everything else you build on it.

All right.

And so like we're saying if you're doing something with a form, hook form alter is what you're going to want to do there.

And preview of learning to learn.  How do you actually know where to start?  Drupal documentation is pretty good.  Drupal contributed modules, just go find another module and look at its code base.  That is the most useful way, I feel.  I put Drupal core and its modules as not as favorite as looking at other contributed modules because even though Drupal core has a ton of modules right now and it's awesome that they keep moving components out of, like, the mass of things you can't change, and into modules that you could actually, like, turn off and replace if you wanted to, like, if you really, really wanted to you could fork the entire node module or clone the node module and do something else with it.  Drupal core is super flexible but its modules tend to have more stuff hard coded.

It has a long history and it's been able to get away with stuff so user module still has a whole bunch of hard coded things so looking at user module for examples of how you can override things in core is frequently not a good model, so looking at other contributed modules, if there's anything vaguely in the space of what you're trying to do, it's great, and just going through its code is a great way to learn.  Searching Drupal forms and issues, Stack Exchange,.

There's an official Drupal.stack Exchange, which has been where a lot more of the action has been, the form is a little quieter.  Drupal issues those are still where, like, everything gets hard out so you'll frequently there will be patches in the issues that will be specific code.  Frequently you can take a patch and make a module of it or as we're going to cover in contributing to modules that are already there, take a patch and move it forward so it actually gets into the module, and you and everyone can use it and then yeah, just searching the general internet, there's lot of great blog posts out there.

And we'll talk a little bit about how to narrow your search so that you can get better results.

And then using a code debugger, which we'll not go into, but yes, it is definitely worthwhile to set up to put in a break point in some other module and see what it's doing, and code search grep which can be helpful.  If you want to change something on Drupal, on a Drupal site, you can see in the interface that there's some text that appears to be coming from code, or a class the HTML or some kind of, something you can see in the interface that you can trace back to the code, is often your first step to how to change that.

So when not to make a module.  When there's an easier way.

Find a contributed module that does what you want, or if what you're trying to do should be in a template.  If what you're trying to do is very specific to the design of your site and you don't think you're going to be changing themes, can just be in template but find a contrib module.  Go to Drupal.org and if you click right on download and extend, that is no longer showing you how to extend the site so you've got to go down over to modules and there and once you're on the modules page, I recommend that you change the core compatibility to 8.X.  That's not what it is by default.  It's just searching everything and if you're on Drupal 8, that's not going to be so useful.

Because there's, like, 30,000 additional modules that are Drupal 7 and below only and then also change the status to "all projects," so those are the only things that have changed here.  Are you all looking at the download and extend page?  Or are we looking at something else right now? 

>> We have a Lego heart on the screen right now.

>> BEN MELANÇON:  That's not what's supposed to be on the screen right now.

>> And we have your presenter view, too.

>> BEN MELANÇON:  All right.  Easier way.

Wow.  That's not cool.  My presenter view is different from the heart.  All right. 

Turn it off and turn it back on again.  Yeah!  All right!

So this is the first page I mentioned.  Pretty sure we were matching up until then.

Sorry about that.

Download page, as I said, the background there of download extend page does not actually have anything to do with extending.  It's just downloading Drupal so if you're, you know, if you haven't gotten your own module before, you've been making do with what's in Drupal 8 core, which is often enough, when searching for modules or just doing what modules other people recommended when you're out search for modules yourself, go down to build modules, and then maintenance.  This is where I was saying the core compatibility is by default not 8, switch that, and the status is by default only full projects, not sandbox projects.

And when you're at the point of making a module yourself, it's likely to be worthwhile to    it's really likely to be worthwhile to start building on a sandbox module that someone else has done but never fully released and start it yourself.  There's a module that almost does exactly what you want.  This is where you can contribute a patch or port it to Drupal 8 or 9.  There is really good documentation on porting a module, so that is    there's so many, like I said there's 4 times as many modules for Drupal 7 than for Drupal 8.  It's really likely and so after you don't find the module in Drupal 8, like the next thing is to filter that for Drupal 7, even go back down to Drupal 6 but if it hasn't been updated in that long it might be better to start fresh but a lot of things you want to do starting with Drupal 7 is going to be better.

This is an example of finding a module that we did.  This is David Valdez with Agaric, and comment notify, we want a very useful thing.  We wanted a module    user story, you know.

When a user went to the site and left a comment, they wanted to be notified when another comment was made and the comment notify module existed but it had a lot of bugs, and so this is the greatest way to get into module building is to look at the code base of an existing module and fix whatever is broken and if it's really just something that's broken, everyone is going to want that.  If it's new enhancement, there's a possibility that the module maintainer isn't going to want it, but it's still the best first step because you're likely to get some support and feedback from other people who know the code you're trying to change and who may want the same things you do.

And so in this case, it was a straightforward bug.  And David first wrote out, like, where he found the error, and what he thinks is wrong, and he did a patch, and the other thing that David does that makes him extremely effective in actually getting these patches in is he writes tests so if you just want to get into learning to write code, write tests.  Everyone wants tests.  More people will help you learn to write tests than anything else.  And it's still an underutilized skill.  There's been issues that are open for two years because no one's written a test, and David or someone will write a test, and it gets fixed within the next, like, two days.  So as far as contributing writing tests is key.  Contributing like this does have its risks.  David was made a maintainer of comment notify sometime after that patch and now he routinely fixes issues by himself.  This is an issue filed by someone.  David made the fix but it's generally better for everyone that you end up becoming maintainer of an existing module than for you to make your own with duplicate functionality.

So when to make a module.  When you've identified to the best of your ability that there's definitely not something out there that does what you want to do.  I personally do not advocate introspection at this point.  You might think, why am I trying to do something that no one else is trying to do?  Forget about that.  If you want it, it's good enough.  It's real.  Go for it.

So as first step around this sort of loops back to other steps, I recommend writing up what you plan to do.  You can do that on your own blog.  Go to groups.Drupal.org and use the contributed module ideas group.  It's not a very frequently used group but there's a few posts a year and it's just the act of writing down what you're going to try to do is going to clarify it a lot and you'll think of 50 more things that you can search the general internet for, search the modules, existing modules.  Like, you'll get so much more clarity on potential ways to get started.  Other modules to build on, or just the kind of subsystems within Drupal that you're going to be building on.

So it may be the first time.  Like, you may have thought of it only as like:  I want, you know, the copyright date to always be up to date on my site, and this may be the first time that you're like, well, how would I actually do that?  It should probably be in a block that can be placed in a region.  Now you're like okay, now what kind of module I want to make?  I want to make a block module.

So we'll look into blocks which used to be done with hooks.  Now done with plugins, and it's still just two files.  You can create a whole block with just two files.  So the info file, we've already talked about, and then another file.  In this case because it's a plugin it's not a dot module file and this is the new way of Drupal.  The only annoying part for me is that it's, like, 6 nested folders every time you're doing something but this is where block plugins go.

So any kind of, you know, anything that's not a dot module file now is you're doing Drupal 8 object oriented stuff correctly will be in your source folder in your module.  We're in a module called copyright.  Within that module we have a source folder, src.  Inside the source folder we have a plugin folder.  Inside the plugin folder we have a block folder and finally we can put in our block.

So first file, the info file, same before, same as before, just the type module.  Then the core compatibility which is required.  We could also make this a pipe 9.X I know will work just as well.

And now in the plugin, you start with giving it its namespace and the namespace is Drupal, and then your module name.

And then everything that's in the same, exact same folder structure, we were just looking at, for plugin and block, it just    the source is implied.  You don't put it there.  And this is the kind of thing that you need to pay attention to because even if you're copy and pasting from somewhere else, you need to change this to fit what you have so you need to at least change your namespace to be your module name.

So even though this is sort of trivial, it's really important to pay attention to.

And so we are going to extend off of Drupal's blocks.  We don't have to, like, figure out how to do everything the block system from the ground up.  We use Drupal's core block, block base, this again is the easiest way to get started on this kind of thing.  You don't need a block.  The documentation on Drupal.org and API.drupal.org in particular covers this well.

So the plugins in Drupal are frequently, the information in the comment is actually used and important.  And so you give the ID for the block in here.  This is where it's defined.  It used to be in hook block info.  Now it's just pulled right out of this special comment.

And then you're extending the block base.  That's why we're using above and you know, this is simple as you can get but is powerful especially if you don't want to have to keep doing this in themes.  If you're switching themes or have several themes, this kind of stuff can be done in template files, but it's honestly more upkeep in the long term than to get it into a block, and the other reason to do a module instead of a template file is that in a module, you're giving a little bit more control to the site builder, and sometimes the site administrator in these types of situations so they can turn off this block.  You can write settings for your module and all of that.

So once you've extended block base, only thing we need to do is actually return, is to have a build function that returns what we want in there.  In this case, we are just returning straight HTML markup, pound markup.  This is the case throughout Drupal's render system.  You can either return markup of actual HTML or you can return    you can name the theme functions you want to do and you can put theme functions in modules so that your module can then have it overridden by a theme, which it is, you know, what you probably want to do.  When you're contributing a module, when it's a custom module, you don't necessarily care whether you're doing it in the module or in the theme.  When you want to change this markup a little bit, but as soon as you have HTML in one of these things, you probably want to step out and make a theme function, and the crazy big module we mentioned at the end has 50 examples of that.

And this is where you can access PHP, so we could be grabbing stuff from the database and combining things.  In this case, we're just outputting the year.  Super simple, but the power is you need a block, you want something in the block.  Once you're at this point, you can do everything.  You can query your database.  You can load variables, and you can output them however you want.

And so that is a block plugin.  So as I said, do email me, I'll get a full list of resources out there.  Most of the links that we're going to have go to Drupal's API reference, which is a really good place to go for an overview of what tools are available for you in hooking into Drupal.

And just, we're not going to    click through.  Yes, there we go.  Thank you.

So just a note on all of these links:  I'm linking to the Drupal 9.0 version, and these hooks all work in any version of Drupal 8.X, almost without a question.  For a long time, Drupal.org inadvertently treated 8.2 as the end all and be all version of Drupal so you're in documentation and you click a link and it takes you to version 8.2.  That's not because 8.2 is better, or what should be your standard.  It's not.  It was just a bug.

So once you're on the API page, you can just change    it lists all of them, and so you can go, and I recommend just going to the latest possible, because that will warn you if you're using something that's going to be deprecated or not.  Most of the things you're going to encounter are going to be pretty stable throughout, but, you know, switch the latest version to get warnings about if you're building on something that's deprecated and you can pick which better one to do.

So hook form alter has tons of documentation there.  And then worth mentioning, the hook entity extra field info for another way of getting data outputted on your site that lets a site Manager interact with it, as opposed to you hard coding it, it makes a fake field, which can be changed on the display fields.

And if you'd rather do it in one file with a plugin like we just did with the block, there's the extra field module so there are a lot of Developer focused modules, so extra field module is just if you want to create a custom extra field.  It just, you know, takes all of this old style hooks and puts it in a new modern plugin so sort of helping Drupal 8 get to where it's trying to go in a contrib module.  It's just more convenient.  It's like that.

So if you're trying to add an extra field that you go to extra field module and get yourself out of having to learn a bunch of hooks, that will be deprecated sometime around Drupal 10 or something.

And then of course, for learning what you're trying to do, the rest of the internet.  Do recommend Duck Duck Go, and then you do a hash, exclamation point G for Google results, and one cool thing about Duck Duck Go, is that you can do multiple sites, so if you want to say, like, if you're not getting great results, and you want to restrict it to a certain set, sort of why I put a blog here, mostly joking so a combination of, I try to put all my own notes on the internet, and then so I can find what I wrote I can go to Duck Duck Go and say give me any results from Agaric.coop, that are from Agaric.GitLab.rio where I'm throwing my raw notes now, and that's all done in just one search, so I can    Duck Duck Go lets me restrict to a subset of the internet really easily.  You can do that like I trust this blog.  I want to get things that are from Drupal.org, and 10 other blogs, and you can just search that, and get sort of higher quality results.  Sort of nicer to get zero results sometimes than it is to scroll through 100 results and realize none of them helped you.

All right.  Sort of shortcuts to generating modules.  One here that was generated with Drupal Console    all right    so it's like, it was Drupal Console has unfortunately not had the support needed to be maintained at the sort of level of promise, but it still works and for certain plugins for CK editor, you can, yeah, that's a whole category of type of thing you might need.

That provided just about everything that was needed.  Mauricio made this, and, you know, he contributed it, and it was simple, got used by a ton of people, and it's slowly gotten more complex, more features over time as people need it.  That's sort of like the perfect module origin story.  Like, actually super easily generated by Drupal Console and then extended and that's    frequently, just like Drupal itself other modules will be extendible and you can just, it's like, you need to do this but you need it to work for Vimeo, like, you can copy this.  Like, you can either use the generator and do it or you can copy this one directly and just get the same thing.

And another example of that is the social share module, social media links module, which we added an email link to, just using its own hook system, its own way of plugging in, and that's another one that would be easy to follow.  So sometimes you're really building on another module and you don't even need to get a patch in.  You can make a module that works with another module.  You don't need to fork CK editor which you don't want to do.  You don't need to fork social media links.  You can just extend it.

Let's click through there.

And again, this covers where everything goes.  The CK editor module will go here.  Source code is where the stuff that matters and then libraries that are needed for it to work go in libraries, so the generated module has thousands of users now.  And we have a blog post on just how it was built that I'll talk about.

And then this is the module with a million examples in it, and it's one that maybe if I listened to my own advice and say hey, this could go in a template, would never have been built, but as a module that uses so much of the plugin system, it's a pretty good one to learn from.  And that's why what I wanted to show is the process of:  How do I actually learn from another module?

I'm sure when Drupal.org gets better and integrated with their GitLab code, it will be easier to look right at the code, but right now, it's sort of like, click on view commits, and then click on one of the commits, and now we're finally being brought over to git.Drupalcode.org, the site from GitLab, and from here we can get back to, you know, the actual code of the module.

And so the other one of the other key types of plugins out there is the field formatter plugin.  So this is what allows you to, you know, to take what might be an existing content on your site, so it's already there.  You don't need to have contenters go back and change how they input it.  You can just go and change how it's put out.

And so this is all, like, all of this is public.  Every single module on Drupal.org you can go and click through and see the code without even downloading it.  You can of course also clone it, which is good to be able to grep and play with it on your computer.

But you can learn a lot there, and so same as all plugins, the front matter in the top of the class has key information, and no one has this memorized.  Everybody is following documentation or other examples, just like this.

Key thing about field formatters is you specify what field types they work on, and so this one is working on entity reference.  And in this case, it is    one of these is more restricted to just taxonomy terms.  This one I think is    yeah, this one is, so look at the other one in one second.  This one is any entity reference, it can display it as a list with [ Inaudible ], and if that's not the    those kind of details aren't the important thing, the point is for when you want to override how something, how a field is displayed, a field formatter is probably how you want to do it, and what you can do is look at the current formatter, so this is sort of where we go to what I was saying about just searching the code base, so, like, when you are editing the    editing the display page on    of a content type, or doesn't have to be nodes, the entity system is pretty universalized so you can change the display of a ton of things and change how each field is displayed and if you go there, and you can change what the    what it's using, what its output is, there will be key words in there what so like if you'd already had mine installed, but you have no idea what this code is, link label to the referenced entity.  You search for that text, you're going to find this module, and you're going to find the one that I stole it from, essentially, so that's how I'm actually overriding it but you can add that back.

So things like this, the setting summary, this is text that shows up there, so this is where, like, you have to think about, like, what part of the text you're seeing is probably always static that way, and which part is dynamic, because, you know, if    sort of like when we're looking at the create content page, it said create Frankenstein.  Like, which part, you know, is always there and always says create?  So I know I can search for create.  I'll probably get too many results but if I'm restricted to just the modules, the Drupal core modules folder I can probably find where that create link was made.  When you have more text to work with, like list items separated by, you can almost definitely find my code right here and once you've found this, you can do it.  That's essentially how I made this.  I looked at the entity reference label formatter and what text it was putting out, and so I could find where the heck it was and once I could find the class, I could extend it and that's what this is doing.

And so finding what's doing what you want to change, and then extending it is generally what you want to do.  And once you'll there, you'll see if it's    oh, it's a formatter and you follow through, and all the formatter is derived from one type of thing.  The way class inheritance works so they're all coming from one root formatter but here we're extending this one, it was extending another one, so we inherit everything it has and we can change it as we want and field formatters are also cool because it's super easy to do settings which is a huge thing about doing a module you're going to contribute back.

So if you're manipulating a field, the tools you have to make it useful for people are great.  So just really quickly, on the other thing, this one, because it's actually looking up the taxonomy term sequence in order to summarize things, the best I can only target here the field type as entity reference, and so if you need to target the type of fields you're doing more specifically than that, that is done with the function is applicable so this function is always there, and, like, when I drill down through the kinds of things that I'm inheriting from, it's there, and I'm just overriding it here, to say that it's only going to happen for taxonomy terms.

So taxonomy terms are cool.  If you want to manipulate them and you want a formatter do it, this is how you do it but more generally, find the text that's related to the settings that you want to change, look it up, find where it is in the code base, whether it's Drupal core or contrib, and make the change.

So drilling all the way back to module page, and there.  So that's that module, which is doing tons of stuff with field formatters.  And it was a crazy need I had, I just didn't want to keep doing, you know, lists in templates all the time.  Like, okay, if this is the last word, then I stick the word "and" in between but if there's only two items in the list, I wanted to put all that in a module.

And then I also needed the crazy summarizing sequences capability, but I contributed so it's the right thing to do.

But, the selfish reasons are, people may contribute to what you put out there, and someone may take it over and upgrade it or improve it greatly so there's a whole bunch of modules that I've created that I maintained badly that other people have taken over that I still get to use and it is wonderful.

So recommend it.  So as of yesterday, another module I put out there called workflow buttons, someone has added a    contributed a patch.  Very politely, and it's, you know, gives me a great opportunity that I didn't have to do the code for to show you a nice touch you can do on the modules you're contributing.

You may know where the settings are for the module you made, but other people won't, so this is the entirety of the patch that Jay Kandari here has contributed, just adding this configure link.  This is a nice touch.  This is an info.yml file we've all seen a couple times now and it's just saying that okay, the settings page is at this path.  And if we're interested, we'll look more into the services that are supplying those types of pounds which is another way to override but I think I'll break for questions before then.

Oh, yeah, and it's the other    other example that you can find in the in other words module is that it's bringing in a PHP library, which is another really great way to do a module.  If you can't find something in Drupal that does what you need or you find something in PHP or possibly JavaScript that's out there, just bringing in that other library is huge also.  And so an example for that with PHP is the in other words module.  In that case I also wrote the PHP library but it still shows you how to bring it in and then an example of just bringing in a JavaScript library which is a little frustrating right now because Drupal doesn't have a set play of how to load JavaScript libraries but there's some convenience to wrapping them in a module is    I'm just going to blank on it    anyway, it's    

[ Laughter ]

It does    it allows you to do range selection of form buttons, and to toggle them on and off, and I apparently did too many modules last year because I can't remember its name right now but it's on the list of modules I contributed.

All right.  So I think this is a pretty big piece, because I think a lot of people aren't aware of it in Drupal 8.  One of the pieces of friction to sharing the module that you're working on is that, like, you've got your set of code, and you have to do something to get that code out in public.

And, like, you've got all of your code name repository, and then you have, how exactly do you have that    and everything in Drupal is supposed to be managed by composer now.  And that actually makes it easier, so instead of, like, trying to do some weird submodule thing where you keep the pure code version of the contributed module out there and then pull it in but you can    you're developing it.  You want to just be able to edit things, edit the changes and not have to make your edits, like, out in some one spot, push it to Drupal.org and pull it back into your site.  That's not an efficient way to develop.

And so if    you can get the best of both worlds by bringing in your module as a git repo with Composer so every time you do composer update or composer install, if you go to a new site or someone is developing it with you, which is the other big thing, if in your module composer.JSON if you add a module composer.JSON you can do that so Drupal modules on Drupal.org even though they're all using composer they don't need their own composer even though Drupal is using composer.  You say composer require Drupal/module name and it brings down the module name, that module doesn't have to have a composer.JSON file.  When you're developing your own module I recommend you do create a composer.JSON file so you can bring it in as a Dev module so this is in specific Composer.  This is for another module we contributed called cyborg translate but that's not the important part but this is just standard Composer allows you to list all of this stuff.

I've created a little like program I use locally that's contributed to convert these things into my readme file so I'm not maintaining all of this in two places.  A little project I called a writeme.  Don't even remember what language it's written in.  Probably PHP.  Anyway, but like Composer is great because it structures important information about your module.  But anyway all it needs is just a file, just so that we can point to it in our next step.  So this is our module Composer.JSON.  This the project that's using it, you can require it as normal, there's Drupal core, there's a module, there's Josh, there's all you need for a website.  There's a standard Drupal repository, and then there is our module, and doing this alone would work fine.  Well actually, hold on, sorry.

Just doing it normally would work fine.  With a normal string.  But we're doing it with a special string.  We're getting the Dev version because we're developing it and we're doing it as 1.X Dev and I don't even remember now what the reason for that is but I spent way too much time figuring out how to pull together a punch of separately maintained projects into one in a way that let me contribute to all of them really easily because we have these projects where we have    we're using 20 contrib modules that we're all maintaining and so we want to bring them in so I'm sharing that with you and I think that's something that's not well enough known or documented to bring in your module as 1.X Dev, and then when you name a specific repository, it works.  So right now we're pushing up to GitLab and to Drupal.  I haven't actually tested to see if this will work just with Drupal now that Drupal is halfway to GitLab.  It may, but if not, you can just have it to    on Drupal and on    Drupal.org and on GitLab or GitHub.  I have another program that keeps everything in sync called hackysync, so if that is kind of a pain point, got a solution for that, too.

And that is just about that.

So start small.  Bite off a piece that you can chew.  It's a wild world out there.  Do not be afraid of it.

And I am looking forward to any questions, and I'm supposed to be sending out links for all of this and more on the session page.  Again, I'm not up to speed with all of these contributed links and formatting this presentation as a blog post that's going to be a lot more useful than going through the presentation again.

So if you want to email me at [email protected] and I'll let you know when it will be available.  I'll add it to the session, too.  Now I'm also supposed to plug the Code Sprint, so if you could take it from me, or Brian.

>> BOB SNODGRASS:  Sure.  I've put the link, by the way, in the chat for the evaluation form.  That will take you to the node for the session, and the evaluation forms are at the bottom of that.  So you'll want to take a look at that.

And as far as the Contribution Day, that will be in the schedule on mid.camp.org and you could just go there on Saturday.  Those sessions won't be open until Saturday, so be aware of that.

So we have about, I don't know, 3 minutes, 4 minutes, before we're officially done, but depending on how long Ben wants to hang around, I can hang around that long, as well.  We're at our lunch break at noon, from noon to 1:15 Central time so that's where we're at right now.

Anybody have any questions for Ben?

If you do, you can unmute yourself, and go ahead and ask.

>> BEN MELANÇON:  Or else I'll start unmuting people at random.

>> BOB SNODGRASS:  There we go.  Point.

It's all quiet out there, Ben.  They don't have any questions.  You did such a good job explaining.  Thank you so much.

>> BEN MELANÇON:  Thank you all.  Yeah.  Hit me up if you think of any questions later, or if you're all secretly trapped and unable to unmute.

>> BOB SNODGRASS:  Maybe that's the case but I don't think so.

[ Laughter ]

All right, folks, thanks for bearing with us on the delays, and we'll go from there.  Have a good rest of the camp, and we'll see you in another room.

>> BEN MELANÇON:  Thank you, Bob.