And we're back with another episode of the website 101 podcast. This is the podcast for people who want to learn more about building and managing websites. I am one of your hosts, Mike Mela. They are Amanda Lutz and Sean Smith.

Hey, everybody. Hello, all. How you guys doing? We're doing great, or at least I'm doing great. Yeah. You're the one that matters. So I'm not really that interested in that. How great demand is.

Everything revolves around me. I mean, what more could we say? What more? All right. So today it's just the three of us, but we're going to be sort of interviewing Sean a little bit here, but also a bit of a round table because we're talking about boilerplates and

starters, I guess you call them different things. Starting point for building a site. Rather than building from scratch, you start with this boilerplate that has a lot of the settings already built in there and we'll explore other.

of things along that line like templates for websites themselves and all kinds of things like that. Yeah, sounds good. And the reason Sean is going to be sort of leading a little bit of it is because

Sean has a boilerplate for craft CMS, which we all use craft and I have a boilerplate that's built off of Sean's boilerplate. So he has a lot of experience doing this. And I think other people use your boilerplate. Yeah, so it looks like Mike has made a fork of my boilerplate and then

I'm taking a look at the GitHub repo right now, which will include a link to in the show notes. It's got 26 stars and... 26 stars, nice. So high level, a little bit high level here. What is the difference between a star and a fork

for people who aren't in the GitHub know so that they can more better figure out how special and used Sean's template is? Sean's bottom plate is. So a star is basically people who favorited it so that they can find it easily.

on GitHub. I don't know how cool it is. I think it's cool that it's more than just me that like it. So and a fork is somebody who said, hey, I like this, but I want to make it my own and do my own thing with it and maybe change it a little bit differently. So I've heard that sometimes people

will fork it and then do a pull request and merge their fork back in, but that's not happened to me. So nobody's offered a suggestion for how you can improve your boilerplate and asked you to pull it back in? No, but I did get a couple of

support requests early on and to go back to your question about forks and stars, I went to packages which is how you do how you hook it up with a composer and the packages listing says there are 26 stars, four watchers and five forks. Cool.

There are five people I've decided to do that and I was like wow I'm contributing to open source. I guess. I don't know. Okay, so what is a boiler plate? We're talking about it. Give a 30-second elevator pitch. Yeah, it might kind of hit on it. Basically, a boiler plate is something that you

use to start all of your projects with. So it's got a bunch of settings and it's built and set up in a way that you're familiar with and can just get you up and running that much faster. I'm going to reference craft here, but this is really something you could do with any sort of

CMS, whether it's expression engine. WordPress, Drupal, whatever. So for Craft, if I was starting a new project and I did not have a boilerplate, first thing I do is I go to Craft Site, find out what the code is to copy the,

or clone the repo, or maybe just download the zip, set that up and manually hook up everything. Then I need to start setting up channels and sections and fields and various configurations. With a boilerplate, I don't need to do all that.

because I've done it once. All my configurations, all the kind of settings that I typically use on a site are already there. Right. So if you tend to use a certain number of plugins or something on most sites, you can have them built into your boilerplate so that when you start a project,

it's already all installed and configured. Exactly. So there's a number of plugins already installed in this boilerplate and they're configured. I don't need to do anything. It's just going to work.

I think there's one or two commercial plug-ins. So if you use this boilerplate, you need to be sure to purchase a license for it before your site goes live. But it's there and it just makes things easier.

Instead of going in, oh, I need to download and install this, you'll magic and configure it. Well, it's partially configured already because there's a lot of things that are going to be used on every site that I build.

Or theoretically on every site that somebody else builds. So it sounds like boilerplates are potentially a lot of work. So why did you, Sean, decide that you want a boilerplate as a jumping off point for most of your sites? Why did you build that

thing? Well, that's a great question. It is a lot of work. And I think most of the work is coming initially in the initial setup. But if I look at how much time I would spend with every new site that I build and doing all of those steps over and over and over the amount of time that I spent

building the boilerplate and the amount of time I save it's infinite amount of time I've saved yes I probably to start from scratch everything would be like somewhere in four to seven hours of of work setting up everything and probably more because over time I've added in some sections

and fields and things like that. So that, hey, almost every site has a blog, right? Well, I have a news section that doubles as a blog. It's already set up. It's got basic templates. I don't need to add fields.

It's already got some, you know, like really basic styles. And all I have to do is go and match the design from whatever the client provides or the designer does. Right, right. I don't need to set up fields or sections.

I've got a spring setup, so it's got all that reactive pagination and search and things like that. That's a lot of time to set up individually. Not it just works. Yeah. The big advantage to me is that saves me a ton of time.

Right. So, there's not a lot of design put into it at all. It's really just like the framework of how things work and then when you build a site, you would. Apply the design of that new site to the existing framework. Yeah, it's really just a skeletal

design black and white boxes There's there's nothing special about it. It just right boom you know like If you're doing design What's it called when you you just have outlines on a design wireframe wireframe? Yeah wireframe. It's basically just a wireframe design

Right, right. Okay. Yeah, so should we get into what you include? in your boilerplate. I know what we talked about. This is yours as a craft specific one, but there'll be some things, I'm sure tailwind will come up and things like that,

but how do you decide what's in, or what maybe we'll start with just what do you have in your, you know what I mean? At a high level. Oh yeah, so it includes things like minifying your CSS, critical CSS, minifying JavaScript.

I've also got it set in for icons, SVG icons, and images to do things like like minimizing and optimizing all automatically. I haven't used that a lot on recent builds, but it is big into it. And it's part of running the production,

npm run production. So it does stuff only before you're deploying to your production site. So, okay, so this is important then. It's not just what's included in the CMS for your site. It's also build process stuff.

Yeah. Things like Alpine, Tailwind that you use. in your site, it's not just plugins in that. It's also like your whole workflow about building a website is included in there. I'm not a big fan of carousels,

but a lot of sites regardless of my feelings about them, use carousels. So I have a JavaScript plugin. I forget what one I use, but it's included in there. Alpine is included. Other things that make it nice and easy to work with

is it's already got navigation built in. So it's got a nav bar that collapses to the mobile hamburger menu and everything. And it's all based off of the tree structure inside of craft for pages. Now, I just mentioned craft, but again, if you're using WordPress or expression engine,

you would hook it into the stuff in the back end for that. And I don't have to build on an F every time. I just need to style it, make it look pretty and match the site design. So I got all of that.

I've got some. section setup, also template it. The way I organize my templates, everything is consistent across sites. So when I go into a site, I know exactly where to find everything. I include things that I don't necessarily build into every site. My boilerplate has dark mode

built in. So there's a little dark mode switcher. But I have yet to have a client want to use it because it costs money for me to... code the design, right? But it's there. I've got that switcher in and I'm actually using it

on this podcast site. So if you come to the podcast website, there's a dark mode option. So you can use system, dark or late. And what is the podcast website? What is the URL? That would be website101.com

or website101podcast.com, sorry. Yeah, right. Great website. So after. After this whole list of everything that you include in your boilerplate, what would be some items that you specifically keep out of it?

Oh, that's a good question. And when I haven't really thought too much about things that I would not include would be something that is not going to be commonly used on many sites. See, I would think that would include the code for the carousel.

Yes, I do have that included. So. I'm going to get back to that in a minute because there's a lot of stuff that I've added over the years that I've been building this. So it's a lot different from when I initially started.

I've grown the boilerplate. But let's say you've got some sort of advanced search feature on a site that gives you a lot of different drop downs and options to filter various results across your site.

I wouldn't include that in a boilerplate because not every site is going to use that. But I've included a blog because... almost every site has a blog or a news entry. I'm sorry, Mike, go ahead. No, so that's okay. So this is... Yeah, I was curious about this too because I have...

I do have a craft boilerplate based on yours. I also have a static boilerplate for the CMS static that I built a while ago. However, I don't often build new sites with static. So what happens for me is it falls out of...

I'm not keeping up to date. with it. So with best practices. Yeah. So how do you approach like if let's say you're building a new site, maybe you've used their boilerplate as a starting point, but then you build in some new feature.

How do you decide whether you'll put it into the boilerplate for the future? Or is it just for that one site? Because here's an example I have. There is a feature called not a feature like a JavaScript library, I guess, called swap SWUP,

SWUP. And it basically lets you have smooth page transitions. So you. like a link and it sort of fades into the next page or whatever. All right. And I thought it was kind of cool. And I checked it out one day.

I built it into a site. And I thought, maybe I should put this in my boilerplate because I might use it in the future, but I don't actually know. And it takes a little bit of work to configure it.

You have to put certain classes here and there and put a line of JavaScript. And I ended up putting all this documentation in the readme file about how to enable that if you want to use it. And it just became really weird.

And I was like, what? Am I just wasting time here? So how do you decide this is going into my boilerplate? This is now. not, and that kind of thing. Your example, but no. No, I know what you wanted to think for a second.

Because the reason, because Amanda mentioned earlier about the slider, like you don't usually use sliders, but you say you do have a slider in there, right? Yeah, I don't advocate for them. I actually advocate against them,

but they're so popular that I don't really push back super, super strong with clients or agencies. So I do include it because I know that I am going to use them. Maybe not on every site, but I'm always going to have a slider not because I think they're great for users

I know they're bad, but yeah, you can't afford that now your JavaScript thing that you mentioned that's something that I would probably think about including just like you did But I may wait until I've used it twice

Okay, yeah, yeah, so but for example there was a a plug-in For a craft and okay again, I'm going craft specific, but you could just Think about it as a plugin that you're using for any CMS. There's a plugin that I thought really helped with the author experience in craft called Matrix Mate.

Gives you a lot of cool little features added to the Matrix. I used it once and my mind was like absolutely, I am going to put this into the boilerplate. I did, we've used it on five or six sites since then, maybe more.

I love Matrix Mate. Unfortunately, I found out it's not... going to be upgraded to craft five, mostly because most of the functionality that it gives you is going to be baked into craft five already. There's one bit that is coming later according

to Brandon Kelly. So yeah, I'm disappointed it's not included because now I'm going to have to recreate all those things natively. There's not going to be a variation path. Just as a side note, are you referring to matrix made itself? That's not going to be

ported over or something else? No, I'm specifically referring to to matrix made. I was talking with the developer yesterday is like, this is one of the only plugins holding me back from upgrading. And he explained that you can do almost everything natively now in Craft 5.

Wow. Okay, well that's good. That's good news. So, yeah, I mean it's good because I also happen to be, as I mentioned in previous episodes, minimalist with plugin usage as much as possible. Variable equals Amanda.

If, enjoy website 101 podcast equals true, then go give us a positive review on Apple Podcast. I can't even do it with a... history phase or wherever you get your podcast. Yeah, because you run the risk of having your boilerplate get really bloated, right?

That's a problem when you start adding all this stuff that you think you may need and may not need. Yeah, and for me, for this plugin, MatrixMate, one of the reasons I accepted adding it to the thing was it added a lot of really good author experience enhancements to the Matrix.

The other reason is if it was abandoned, which... coincidentally it is going to be abandoned. Removing it from the site does not impact the front end. I can remove it from the site and the site will continue to operate. We

can continue to make updates to content. It only changes the way the author experience works. So that was one of my criteria is that if I'm going to include a plugin, it really needs to be critical for the site or be something that I can pull out and maybe...

not, it's not going to hurt it. So for example, I include SEO matic, which is a big SEO plugin for craft. Every site's going to do that. The other reason that that one's included is Andrew Welch, the developer trusted active in the community. He's not

going anywhere unless he gets hit by a bus. Or retires or retire if you want. And Andrew, I hope you never get hit by a bus because we all love your plugins. Assuming he's listening. So yeah, I'm going back to things I

would not include it something that is is unlikely to be needed on most sites that I built. Yeah, my boilerplate focuses a lot, I would say, on things that I use, like you said, the control panel side stuff,

where it's like if it came out, it wouldn't affect the public's facing side very much. It's more things that help me develop. I've got a lot of things like that in my interest. Yeah, one of the things that you mentioned,

about a year ago, maybe a little bit longer than a year ago, was this CSS. for the control panel where you can change the way things look. And I added that in, and I even copied exactly what you did

to enhance the matrix block. So it stands out more what's the active block is. Yes. And I really like that. So yeah, it's things like that. And to go back to things I do include, I have some basic templates set up.

I have a basic matrix or a content builder that's got blocks for copy, floated image with copy, a slider or a carousel, a call to action. video blocks, so you can pull in a YouTube or a Vimeo, and bet all of these are common things

that almost every site uses. So I've built a matrix that has all of these in with minimal styling using the wireframe type of thing. Now when I build the site, I don't have to sit there and create all these fields

and these blocks and then create all the templates because they're already there. All I need to do is go in and add various tailwind classes, maybe a little bit of JavaScript to enhance it and match the site design.

Yeah, and if you decide you don't need those blocks in that particular site, you can just delete them from the matrix. Yeah, I can just delete them or disable them using MatrixMate, or in Craft5 there's different

ways to do that, which I haven't had a chance to play with yet because Craft5 was just released yesterday. So, it seems like the two of you are very excited and very happy using your boilerplate disadvantages that you have run into since you've created it.

Nope. No, I, I, I, I thought about it for a second. I guess the only real disadvantage would be that occasionally I spend a little bit of time updating the boilerplate. And mostly that's like about every three or four months I'll go through and I'll update

the CMS and all the plug-ins. So it's on the latest up to that point. And occasionally if I do something cool on another site that I think would be helpful. you know, how Mike had just asked, then I'll just copy that in.

And maybe I also, I'll find a bug that in some of my code and I'll go and fix it. I find the bug on a production site and then I go back and I fix the boilerplate so it doesn't go into other sites. So as far as I'm concerned, I think one of the drawbacks of disadvantages of using boilerplates is the very fact that you have to keep it updated.

Like I've frequently had things added. to a particular site that was based on my boilerplate and then I'm like, oh, I should add this feature to that. But I'm like, what am I going to find the time to do?

I'll do that some other time. Or even when I do add it, like I said, that swap library thing I added, I found myself adding, like taking the time to add a lot of information in the README file just so

that I remember next time how to enable it or whatever. Do you do things like that? Keep the README file updated with instructions. Oh, I'm glad you brought up the README file. The README file. is really really important especially if your boilerplate is going to be used by other people.

I don't know if Mike's boilerplate is publicly available or not. No, I don't think so. No. Yeah, I think it's really important because there are some things in my boilerplate that I don't recall very often especially like when I'm doing installing it from

packages there's a step by step about what you need to do. You need to update this and that and this and that. You have to put all that in there because you're not building a brand new site every week or every day. There's things you're not going to remember.

or there's image manipulation on the front end. I previously was using a plugin and I copied some of the plugin documentation so I could easily just copy and paste into my templates, but then I didn't like that plugin eventually

and I went in and created something using native code. And then I had to go and update the documentation for how this works with the native code. And that's actually where most of my bugs came because over time I found little edge cases

that I had to go and fix and it's all really too hard. these image things. Yeah, yeah. Yeah, for my boilerplate, even though it's not public, I think I have it shared with Amanda and maybe one other friend of ours, maybe you, Sean,

but the public can't really use it. I'm not at that point yet where I wanna make it available, but just recently I did update the README file, especially the installation, like the Composer and NPM and stuff,

like incredibly detailed. I added like, you know, you copy this line, type this in like, in both, bullet points. And it's dead easy to get going now, which I'm thrilled about. It's not dead easy for everybody.

Yes. I'm gonna throw one of our friends under the bus, but I'm not gonna name him. He's gonna recognize who he is though. I'm sorry, friend, but I'm throwing you under the bus here. So one of our colleagues or friends uses my boilerplate,

and he was asking for some sort of port on something. He'd ask me the question, he's like, oh, that's on the dock. And the read needs, like this section, step three or step five or whatever the step was.

And a couple times, he's like, oh, you got to do that. You got to check that. And that didn't end up solving his problem, but he had skipped part of it. And I know he went back and talked to Mike later.

But the thing is, people don't always read that. And it made me think about all the times I have asked plugin developers for support. And they told me to go read the docs. And I was like, oh, man, face pawn.

I'm just as bad, so unnamed friend, I'm not really throwing you under the bus as much as like I'm throwing myself at the same time. Sometimes that's for real though. I recently had trouble with a plug-in for a CMS and I reached out to the developer and he tried to clarify something and he said,

as mentioned in the docs, as like this sort of passive aggressive thing I guess, and I checked, it's not in the docs. The thing he said is not in fact there. He thinks it's there, but it's not. Yeah, I think plug-in documentation is...

is probably the hardest aspect of plugins. Because you know the plugin in and out as the developer, you just know. But you're not thinking about people who are coming to it for the first time. And some people will have less experience

as being a developer, let alone less experience with your plugin. So when I see a plugin that's incredibly good documentation, it's awesome. You're getting gold. Yeah. So. Andrew Welch has probably has the best plugin documentation of all the craft to plugin authors.

And Ben Croker, our friend Ben Croker from Put Your Lights On, he was on a previous episode talking about plugins and documentation. He's got very good documentation. His documentation is also good, so is for, but that's not a slag on anybody else who doesn't.

I think it's just a ton of hard work to do. Yeah, no doubt. So yeah, I mean, boilerplates, it does... It saves a lot of time, but it also is a little bit of work, especially ongoing work, as you've

got to keep it up to date from time to time. Okay, so Sean, I know that you don't have any pull requests of people trying to add things into your boilerplate yet. But if you got, let's say, a feature request, someone came to you and said, hey, do you

think you should, why don't you think about adding this into your boilerplate? How would you handle that? If it's something I would use myself, I would add it in. If it's something I'm not going to use, I'm not going to add it in because honestly, this is a boiler plate for me.

I'm happy that other people use it, but I don't want to maintain something that I'm not going to use. Yeah. And it's interesting because it makes sense that you say that, but that makes me realize that a boiler plate is quite personal.

Like it's about the way that the person who made it develops websites. Yeah. Right. Because you and I have different ways of even something. as simple as organizing the navigation menu or something of a site.

Like I might have, I do have a very specific way that I use on every site, but you might not have that. So if you were to install my boilerplate, you might be like, what? I don't wanna do my navigation like this.

And it can even go so far as naming conventions. Yeah, that's right. If you're not using tail, and then you're gonna be doing naming conventions, whether you use BAM or Camo case or Snake case or whatever for your CSS classes.

And then even in tailwind, when I... do config custom configs, I do red brand for my color. So it's red brand 100 red brand 200 something something like that. Maybe you do it differently. Somebody might be doing primary color secondary color. Like it is personal. It's like how

you work. And that I think that the reason people might fork it is they like a lot of what I want like what I've done. But then they want to change some of it because it's not the way they personally work.

And it could be the naming conventions or whatever. But I wonder how many people of those bunch that are using your boilerplate, maybe you've actually influenced the way that they build websites as well.

Maybe you've put your fingerprints into their site with the naming conventions and whatnot. You know, it's entirely possible because I think about things that I've learned from Discord or Stack Exchange or just documentation of other plugin authors.

and how I take those and use it myself. So it's entirely possible. I'm taking a look at the stats. There are 226 installs of my boilerplate. I have maybe used it 20 times, maybe 25. There's a whole lot of other installs.

People have tried it out. I'm happy, I like that they're using it. If somebody gives me an idea, if it's something I would use, I'll do it. If they find a bug. in the code. I'll fix that, of course. But yeah, if it's

something that I'm not going to use or don't see value in it, nah, I'm sorry, it's a it's for me. Right. You're free to use it, but it's for me. Put it in your own boilerplate if you want it so bad. Yeah, fork it and make it your own. Right.

All right, that's good. That was really good information. I learned, well, I mean, I, yeah, I learned some stuff about boilerplates. Hopefully you guys did too. And everybody else? Sean, you still want to maintain your boilerplate after this discussion.

It hasn't turned you off the whole idea of providing this to people. Oh, God, no, I will be continuing to maintain it. And I'm already planning to update it to craft five. Once there's a couple of plugins that need to be done or made compatible,

and then I'll be moving on and getting it ready for craft five. Yeah, I guess we never really got into depth about that. Like, I see I'm getting updated a full. point, you know, a full version would be it would have a big impact. Like you'd

have to make a decision of when you're gonna do that. Do you have any process for that? Well, I did it when we went from craft three to craft four. And basically in the documentation at the time I added a line that said if you

want to start with a craft three plug it or a version of this boilerplate, then there's this is how you install that. Okay. And I'll do the same thing when we do craft five. I'll add an align specifically for craft four.

Wow, nice and I want to get the boilerplate up to craft five as soon as possible because I don't want to Start a new build and then have to upgrade it to craft five. Yeah. Yeah, yeah, so all right Well, this is great. Yeah, this has been fun. I like this conversation. Thank you so much

Thanks Sean for your information. Thank you Amanda Amanda's got some I think she's she got some workers in her house doing some workers up thing and making noise. Sorry So she was a that wasn't as chatty as we'd like her to be,

but that's all right. Active listening, that's what I practice today. Oh, nice. Awesome. So tell your friends, subscribe, check out our stuff on YouTube, Lunch Bites every first and third Wednesday.

I always have to think of, is it Wednesday? Yeah, Wednesday. First and third Wednesday, so the next Lunch Bites will be out before this episode. Yeah. I think, or maybe it comes out, I don't know, anyway.

Whatever, just tuning in sometime. All right, thank you for listening. Till next time, bye. Bye everybody. The website 101 podcast is hosted by me, Amanda Lutz. You can also find me online at amandalutz.com.

And by me, Mike Mela, find me online at belikewater.ca or on socials at Mike Mela. I'm Sean Smith, your cohost. You can find me online at my website, caffeinecreation.ca and link then at caffeinecreations.