--- title: Lessons from a plugin developer with Ben Croker date: 2023-05-09T05:00:00-04:00 author: Sean Smith canonical_url: "https://website101podcast.com/episodes/season-06/episode-12/lessons-from-a-plugin-developer-with-ben-croker/" section: Podcast --- <!\[CDATA\[YII-BLOCK-BODY-BEGIN\]\]>[Skip to main content](#main-content)![Ben Croker](https://website101podcast.com/uploads/hosts/_200x200_crop_center-center_none/ben-croker-2018.jpg)Guest Ben Croker Craft CMS plugin developer, trainer and consultant, lover of adventures and the great outdoors. [ ](ben_pylo) Season 06 Episode 12 – May 09, 2023 52:22 [Show Notes](#show-notes) ## Lessons from a plugin developer with Ben Croker  0:00 0:00 1.0x 0.75x1.0x1.25x1.5x2x [](//dts.podtrac.com/redirect.mp3/website101podcast.com/uploads/mp3/season-06/S06-E12-plugin-development-with-ben-croker.mp3) A discussion on plugin development with Ben Croker who has developed plugins for Craft CMS and previously for ExpressionEngine. We discuss when to use a plugin, when a plugin should be commercial, how to price a plugin, and providing support to end users. ### Show Notes - Ben's origin story - What is a plugin? - CMS acquisition of plugins in order to add to core functionality - When to use a plugin or build it myself? - How do you come up with an idea for a plugin? - Commercial vs Free plugins - Supporting plugins - No code vs bring your own code and technical knowledge - Support tickets/issues - GitHub issues - Email (good for sensitive information) - Ticketing systems - Feature requests and pull requests - How to decide the cost of commercial plugins - Breaking changes in the CMS - Plugins that work with other plugins - Website security and plugin evaluation - Advice for developers new to plugin development - USE an IDE ### Show Links - [Code Igniter](https://codeigniter.com/) - [ExpressionEngine](https://expressionengine.com/) - [Craft Cms](https://craftcms.com/) - [Put Your Lights On](https://putyourlightson.com/) - [Blitz](https://putyourlightson.com/plugins/blitz) - [Sprig](https://putyourlightson.com/sprig) - [Sendgrid](https://putyourlightson.com/plugins/sendgrid) - [Feed Me](https://plugins.craftcms.com/feed-me) - [The Dangers of Over Reliance on Plugins in Website Builds](https://caffeinecreations.ca/blog/the-dangers-of-over-reliance-on-plugins-in-website-builds/) - [SEOmatic](https://plugins.craftcms.com/seomatic) - [Good Documentation is Hard (Matt Stein)](https://mattstein.com/thoughts/documentation-is-hard) - [HTMX](https://htmx.org/) - [Tailwind with Adam Wathan - Season 5 Episode 4](https://website101podcast.com/episodes/season-05/episode-4/tailwind-css-with-adam-wathan/) - [Semantic Versioning](https://semver.org/) - [Craft CMS Docs](https://craftcms.com/docs/4.x/) - [Craft Quest](https://craftquest.io/) - [Craft Generator](https://github.com/craftcms/generator/) - [PHP Storm](https://www.jetbrains.com/phpstorm/) - [Visual Studio Code](https://code.visualstudio.com/) Powered Transcript Accuracy of transcript is dependant on AI technology. **\[00:00\]** **Amanda:** I published lots of articles on my website. I share how my plugins work. I don't try to keep those things secretive, because I believe that, you know, we can all benefit from learning together and from sharing and growing as a community. **\[00:14\]** **Sean:** Hi, and welcome to another episode of the Website 101 Podcast, the podcast for people who want to learn more about building and managing websites. I'm Sean Smith, one of your co-hosts, and with me today is Amanda Loots. Hey, Sean. And Mike Miller. Hello, Sean. We have an excellent guest today. Ben Croker is a craft CMS plugin developer, trainer and consultant, lover of adventures and the great outdoors, he's with us today from Panama and we're going to be talking all about plug-in development and craft CMS and things like that. Ben, welcome to the show. **\[00:56\]** **Amanda:** Thank you, good to be here. **\[00:57\]** **Mike:** Yeah, we kind of all know Ben sort of peripherally through our histories, I guess, because Ben used to do plug-ins for a CMS called Expression Engine, right Ben? That's right, Jim. And we all used to use that. That's kind of how the three of us met, I guess, through that community. and then now he does plug-ins for the CMS called Kraft, which we all now use as well. So we've all sort of moved in the same circles for several years now, right? Okay, let's get right into some questions here. Before we get into the plug-in stuff, Ben, beyond what I just said, what would you describe as your origin story in this industry? Like how did you come to work? How did you become a plug-in developer? **\[01:39\]** **Amanda:** Well, I consider myself a software engineer I've been doing this for a very long time, but really, at my core, I'm a builder. I love to create things, and I remember growing up Lego was my favorite toy, and I just loved the process of sticking blocks together and creating something that represented something in my imagination, and then knocking it down, of course, was just as fun and then starting over. And then as I guess was in my teens, I became interested in Technic Lego, which is if you're familiar with it, it's kind of like you can build vehicles and cranes and that kind of stuff. So it's like, it's still Lego, it's still like blocks that you stick together, but you get little engines and little wheels and this kind of thing. And I kind of consider what I do now in terms of building plugins as kind of building or creating the building blocks for people to take and integrate into the things that they're producing. So some of the plugins will just be kind of you installed at plug and play, but a lot of the plugins are there as tools for people like the three of us and people listening to integrate into their websites and their client projects, that kind of thing. So I think at my core, I would say I'm a builder. I love creating tools that people can then use, and I get great satisfaction out of seeing how my tools are used in the wild as well. **\[03:16\]** **Mike:** Right. Do you only do plugin work now, or do you do any work directly for clients? **\[03:22\]** **Amanda:** I would say that 90% of my time is on the plugins that I develop, I do some client work. And it's taken a long time to get here. I should say, because you asked about the origin story, I didn't really give you one, But it's like been a 20-year journey, I would say in this industry getting to where I am now. And in the beginning, just to back up a little bit, I was building educational software when I was fresh out of college. And I was using Flash, the technology back then. And I needed something for the back end and I found CodeGnighter, which was a framework that turned out to be built by the company behind expression engine, which you already mentioned, Ellis Lab. And that led me on a path then into expression engine. Because I quickly noticed that any time I'm building software, you have a content back end. You have, even if it's a web app, you have content that supports that or powers that or is even an integral part of that. So I quickly realized that having some sort of system for managing the content is very important. And that kind of led me in the direction of expression engine. And I started doing quite custom expression engine apps and websites. And that led me on the path to add on or plug in development. And really it was just a hobby in the beginning. It was something I did on the side. And I actually never expected that it would be something that would eventually turn into a full-time thing. In terms of now, like I said, most of my time spent on the commercial and open source plugins that I have. But I will do like, I don't know, three or four client projects a year, generally in the form of a custom plugin, that does something rather complex and is kind of challenging. And it always helps me to stay connected with how craft CMS is used and how my plugins or other people's plugins are actually being used. That's Spark's ideas for new plugins or new features. **\[05:36\]** **Mike:** Right. Very interesting. So since we're talking about plugins, let's kind of back up zoom out. What exactly is a plugin? How would you describe, how would you define a plugin versus, I don't know, some, I mean maybe there isn't a difference between like extensions and modules and all this stuff. I'm not really into that level of depth with the, the, uh, with craft development, I do more of the front end stuff. So what is a plugin exactly in your description, right? **\[06:02\]** **Amanda:** Well, in terms, in the context of a content management system, which is I think what we're talking about here, um, you have the core CMS which has all of the features that allows you and your client and the authors and editors to manage that content and create that content. And then plugins are there or there's a plugin architecture, at least, that is there that allows additional functionality to be plugged into the CMS, so to say. And in craft CMS, we don't distinguish too much between extensions and modules. That was more of an expression engine thing. But of course, different plugins can plug different functionality into the CMS. But in essence, plugins are there to fill the gaps. And some of those gaps will be things that many different websites and web apps require, things like search engine optimization, or things like performance, or things like, well, I can name a few of the plugins that I have that add different types of functionality. One would be like email marketing. Another one would be like caching for performance. So things that the CMS doesn't necessarily or shouldn't necessarily do out of the box because it can't do everything, right? Like there's a limit to what it can and even should do. But these plugins are there to fill those gaps so that you can kind of pick and choose and at what type of website and what type of functionality you want to create for your clients. **\[07:46\]** **Mike:** Right. And by the way, just before we go on, I should we should say your website is called put your lights on.com. And that's where you can see all your plugins. And we here on the show, we actually do use a lot of these plugins. I use Blitz, Blitz is like a caching thing that I use on pretty much all projects when I can. I know Sean's a big fan of Sprig. **\[08:08\]** **Sean:** Yeah, it's baked into my boilerplate, which I'm not the only one using it. There's a couple hundred people who use my, or downloads of my boilerplate. **\[08:18\]** **Mike:** Yeah, and I use entry count. I'm actually using that on a site. I've used Send Grid. So there's actually a bunch of plugins that Ben makes that we actually do use. So that's really cool. I really appreciate having these options available because they really do offer a lot of really great features to the clients that we work with, right? **\[08:41\]** **Amanda:** Yeah, and there's many plugin developers. I don't know what the plugin count is at the moment in the craft plugin store, but I imagine it's around 1,000 plugins that you have to choose from. Of course, filtering those down to a set of plugins that you're comfortable using, or that you want to be using is a bit of a process, but it's good to have that choice available to you. **\[09:05\]** **Sean:** So Ben, you said something along the lines of plugins are typically used to fill gaps that the CMS either doesn't, either doesn't or shouldn't include in the baked in features. In your opinion, is there ever a time that it would be better for a CMS to acquire or build something from a popular plug-in that everybody is using so that it's standardized? It could be an SEO plug-in or image manipulation, something like that. **\[09:44\]** **Amanda:** I think there are times when that does make sense, but it's a very fine line, right? Like, what you want to avoid generally is that the core of the CMS gets bloated and that it's providing too much functionality. And the danger there is that the software becomes overly complex, perhaps it negatively affects performance. Maybe it just becomes difficult to use because you have all of these options available to you that you frankly don't need half of them. So I think that the focus, and this is gonna be different for every CMS, of course, you know, depending on the focus of that CMS or the goals of that CMS. But there are situations and there have been situations in the past where something like that has happened. For example, there was a plug-in, I believe called craftql, which added a graphql API to craft CMS. And I don't think that was acquired necessarily, but the team behind Kraft CMS decided that that should be core functionality, that a GraphQL API should be part of the CMS. And therefore, they built that in as a feature. And there have been other things, like, there have been acquisitions. I believe pixel ontonic acquired feed me, which is a plug-in for importing data into the CMS. And that's another use case where you could say, well, they did make the case that, you know, this should be core functionality. It's a CMS is there for managing content, so part of that is getting the content into the CMS. So it picks on tonic acquire that plugin. **\[11:23\]** **Sean:** Yeah, I think with FeedMe, it's not part of core functionality, but they kept it as a first party plugin. **\[11:28\]** **Amanda:** Oh, yes, you're right, I'm sorry. So that's a scenario where they made the conscious decision to not pull it into core, but they acquired the plugin and left it as a plugin, but they're supporting and maintaining it going forward. I believe the plan, maybe this is just rumors, but I believe the plan is to eventually bring some sort of import functionality into core. We already have export functionality, right? You can export your entries and your data, so why not be able to also import them as a core feature? So I believe that's on the road, map eventually. **\[12:07\]** **Mike:** Yeah, it would make sense for something like craft too, because they're part of, I feel like part of what they're really need to work on is the outreach and getting people to know about it so that people aren't saying, I've never heard of that. What if it disappears tomorrow? You know, everyone's heard of WordPress or whatever. So if they make it easier for you to bring content from WordPress into craft, because it's built into the system then it would really help with getting people to adopt the product, I would think anyway. Sure. Maybe that's just me. **\[12:35\]** **Sean:** Yeah, I would agree with Mike as well. So another question here, Ben. What do you think, or when do you think is the appropriate time for a developer to use a plugin? So one of my things that I bring up many times is over relying on plugins, just using a plugin because it exists rather than doing it simpler and reducing your bloat or reliance on something that could just disappear. What are your thoughts about that? **\[13:10\]** **Amanda:** I think it's a very good point. And I believe you wrote an article about over reliance on plugins. **\[13:16\]** **Sean:** Which I've plugged several times on the podcast. Well, I'm doing it for you here, Sean. It's cool that you're aware of it. I wasn't sure, so. **\[13:26\]** **Mike:** I have a feeling this is gonna end up in the show notes as well. **\[13:29\]** **Sean:** link once again. I wasn't going to do that like swear to God. Well, yeah, yeah. I tend to agree **\[13:40\]** **Amanda:** with you that overreliance on plugin is not a good thing. And the main reason for that is that every time there's a major update to the CMS, all of the plugins that you're using also need to be upgraded. And if one of those is holding you back, then that puts you in a bit of a pickle. And that's one reason, there are other reasons that, again, like I talked about code, bloat, and the more plugins you add, like just the more stuff there is in there, and the more things can go wrong, and the more things need to be maintained. So my philosophy when using craft CMS is to, you know, take craft core as far as you can without any plugins. And whenever you need a piece of functionality that doesn't exist as part of core, you're kind of left with the decision, like one is, do I even need this and can I leave it out or can I find an external service perhaps that fills that gap? The second might be, well, do I build this myself or do I hire somebody to build a custom plugin that fills this piece of functionality that's missing? And of course, the third option is, is there a plugin that I can simply install and possibly, maybe it's if it's a commercial plugin, I'll pay something for it. And then I get that functionality built in. And hopefully if there's a good plugin developer behind it, there's somebody maintaining it and providing updates for that as well. And I think that's an important question to ask yourself each time. And of course, with experience like you You mentioned it shown that you have a boilerplate project, like you get used to the types of plugins and type of functionality that you want on every site and you can start creating a safe list of plug-in developers or plug-ins or that kind of thing. **\[15:30\]** **Sean:** Yeah, for sure. There are times when, you know, if, so let's take the navigation that you just mentioned as an example, because that's a perfect example, you probably need a navigation on almost every website you build. So it seems like you've managed to take, to take the functionality that craft core gives you and twig templates probably give you, and turn that into something that works for you and works with the majority of the size that you build, whereas there are plugins, right? You could install a plugin and rely on a plugin for that, but you're making the conscious decision not to do it. For something that is a bit more complex or a bit more involved to set up such as SEO you've chosen a plugin which I believe is $99 and that probably saves you hours and hours of development work and you kind of can just install it and forget about it. **\[16:21\]** **Amanda:** Yeah, for sure. There are times when, you know, if, so let's take the navigation that you just mentioned as an example, because that's a perfect example, you probably need a navigation on almost every website you build. So it seems like you've managed to take, to take the functionality that craft core gives you and twig templates probably give you, and turn that into something that works for you and works with the majority of the size that you build, whereas there are plugins, right? You could install a plugin and rely on a plugin for that, but you're making the conscious decision not to do it, whereas for something that is a bit more complex or a bit more involved to set up such as SEO you've chosen a plugin which I believe is $99 and that probably saves you hours and hours of development work and you kind of can just install it and forget about it. **\[17:19\]** **Sean:** Yes and it's easy for clients to use and Andrew regularly updates it so he's on top of all the SEO stuff. I don't have to think about it. It doesn't even require a line of code in the template. **\[17:34\]** **Amanda:** Yeah, SEO is constantly changing too, right? And you maybe you're not an SEO expert and maybe you don't want to be, whereas navigation isn't really changing. Navigation is navigation. **\[17:47\]** **Mike:** So I have a question here. When I was younger, I used to want to be an inventor. I always wanted to come up with some cool idea and invent things like machines or whatever. But of course, the trick for that kind of thing is how do you get an idea? Like, where do you get up? Where do you get an idea for something that doesn't already exist? So, how do you approach plugin development with that in mind? How do you come up with, you know, oh, this is a great idea for plugin, and it doesn't already exist, and it's not in the core CMS. I mean, you've got what dozens of plugins here. Where do you get the ideas for them? **\[18:26\]** **Amanda:** I guess like any good inventor, like the seed for the ideas is necessity. You know, I find myself in a situation where I would like to do something or I would like to add some functionality, and it doesn't exist out there. And at that stage, you have to ask yourself, is it worth my wild building? And if it is, am I going to build this just for myself, or am I going to put this out there and make this publicly available? And if you go down the second route and making it publicly available, then there's some follow-up questions like, is this something I want to make free open source or is this something that I want to make commercial and charge for it? And sometimes that question has nothing to do with, do I want to make money from this and has everything to do with like how much work will it be to support this and and to maintain this going forward, because so many plugins or so many inventions have been created and nothing happens to them. You know, they might be wonderful ideas, they might be wonderfully executed, but there's no follow-up and there's no momentum to keep them going. So to go back to your question, I would say almost all of the plugins have come out of necessity or, I mean, there are a few plugins, I guess, that, you know, there's been a need for them, a client has required them, and I've decided, like, I think the send grid plugin that you mentioned, Mike, earlier, all that does is it adds an integration between Craft CMS's Mailer adapter and the send grid email delivery service. And there was a need for that And I created it and decided to put it out there for free. And this very little maintenance to do every now and then. I mean, this Android API doesn't change, but it did change at one stage. And that needed enough grade. But that's a good example of a plugin that I'm happy to make free open source. And I should also mention, even though I'm a full-time plugin developer, I have only five commercial plugins. and I don't know, two dozen free open source plugins. So the vast majority of my plugins are free and open source, but those are made possible, or it's possible for me to support those because of the small number of commercial plugins that are selling quite successfully. **\[21:06\]** **SPEAKER\_00:** Right, okay. I have a question about you in supporting all of your plugins. I think that every developer at one point or another has come up with this idea that's gonna be awesome I'm gonna put it online and everyone's gonna use it and I know that I always just stop whenever I start thinking about all of the people who are gonna contact me and be like make this change, include this feature and it's like I just I could not bother. So how do you deal with the crazy requests or the volume of normal requests or like is it just you or do you have a team of people and now you can shuffle that off onto someone else. How did you deal with Sean pestering **\[21:46\]** **Sean:** in here when the spring first came out. I did put a lot of time. I did take a lot of your time. **\[21:52\]** **Amanda:** Well, let's come back to spring because that's a bit of an exception here. But to your question, Amanda, I think first of all, you got to love support. And sometimes I get frustrated, for sure, with the number of questions and with the way that questions are asked even. But I would say that, you know, I have to love it because it's probably like 50% of my time is answering support questions or helping people with their issues or just or just even sending people links to the docs in which things are actually explained. So I would love to think that I'm or yeah, you might think that I, you know, sit there building plugins all day, but actually half of my days are spent just, you know, answering support requests and questions. **\[22:46\]** **SPEAKER\_00:** I think some of the best, some of the best plugins are created by people who are patient and so helpful with their support. Like Ben, like Andrew, like Josh at Verb, who makes for me, like Josh has helped me so many times with his plugins. So thank you, thank you Ben, and thank you to all of the other plugin developers for being patient with us who know and ask, you know, the intelligent questions like me and Sean and thank you for being patient to all of the other people asking **\[23:14\]** **Amanda:** for help as well. Yeah well building the plugin is just half of the journey. You have to also the other half is helping people use it or communicating to people how they can use it, how they can possibly extend it and that comes in the form of writing good documentation which is extremely hard. It's deceivingly hard, I would even say, and a good friend of mine, Matt Stein, put out an article just the other day on how documentation is hard, and Matt contributed a lot of the documentation for craft, CMS, actually. So that's an excellent article I recommend reading. But documentation is hard because you're trying to explain to people who don't have an insight or knowledge into your plug-in or possibly even non-technical. You try to explain how this plug-in should be used. That's a very difficult thing to do when you're the technical person who's kind of built it from the ground up if that makes sense. Because everyone should just know what's happening in my head. Absolutely. And when I write the instructions, I write it as a technical person, but I need to take myself out of my position and put myself in the position of somebody who has, you know, possibly no idea what this plugin does or even, you know, how to install a plugin. I've had to turn down questions like I've had people ask me how to install the Blitz plugin, for example. And that's where I kind of have to say, okay, well, this is where the support burden on me ends and I can shift that over to craft CMS And I can say, well, you know, this is nothing to do with my plug-in per se, it's to do with you need to understand how to install plugins and you know, they're going to be coming back with more requests if they don't how to install the plugin. Yes. **\[25:16\]** **Mike:** Well, it would be an added, I would imagine that problem will be compounded in the fact that a lot of people again just pick on WordPress a little bit in the WordPress world. press world, if you're like a no code type person, and you want to do something, you get a plugin. That's what you do. You plug it in and that it does all the work. So a lot of people coming from that space just aren't good at working with code. So the idea of using a plugin is their way out of that. So the idea that you have to do some technical things to use the plugin could throw them off a little bit. **\[25:52\]** **Sean:** Absolutely, because I mean, craft is a bring your own code solution, not a use whatever **\[25:58\]** **Amanda:** everybody else is doing. Yeah, that's a very good point. And something we didn't touch on earlier, like the difference when we were talking about what is a plugin in the context of WordPress, a plugin is something you can just, you know, click a button and it gets installed and maybe adds a new page to your site, whereas in the context of craft CMS, a plugin is something that you generally install and then have to configure or set up or integrate into your site with sometimes a little bit of code sometimes no code but but almost always you need to have some technical knowledge about how it's going to add functionality to your site or how to how to **\[26:36\]** **Sean:** integrate it into your site. At a minimum you need to put template codes in for almost any plug-in And then quite often a lot of them will have a config file that you have to, which is like a JSON config file. **\[26:51\]** **Amanda:** Yeah. So in terms of support, I mentioned documentation. And it's also important to have a good system for dealing with support requests. I tend to use GitHub issues because I like the support requests kind of being compartmentalized with the source code so that they're per project and GitHub issues, I find great because I get email notifications or there's the notification system built in actually to GitHub issues. I can pull people into the conversation, I can refer to source code, I can add pull requests. So, and people can contribute code as well if they want and we can discuss it there. So, that's my preference. but it's just one type of support system. I will also offer email support because sometimes people want to ask a question or send something that perhaps contains sensitive information. So of course, we can do that one-to-one over email. And there are definitely lots of ticketing systems available out there. I don't personally, I'm not a big fan of ticketing systems. probably good for larger support teams, but every time I fill in like a support form, I kind of feel like it just disappears into the void. I don't know when I'm going to get a response, and I don't know where this thing is ended up, and I can't go back to it and add to it or modify **\[28:26\]** **Sean:** it or anything. I like GitHub issues as a user, not a developer plug-in developer, because I can search the issues for the same question that I have and either follow-up question I didn't work for me or save you time because the answer is right there and it saves me time too because I **\[28:47\]** **Amanda:** don't have to wait for you to respond. That's a really good point and that's yeah the big disadvantage of having support coming through as emails or some sort of private ticketing system where it's not **\[28:58\]** **Sean:** publicly available. Do you want to hear more website 101 Podcast content? Of course you do. Now you can not only listen to us but watch us on our YouTube channel. Search YouTube for **\[29:13\]** **SPEAKER\_00:** website 101 Podcast. Ben are you working by yourself or do you have a team of developers **\[29:20\]** **Amanda:** that's going through stuff? No, my company is really just me. I have quite a few colleagues and peers and we will kind of bounce work around when when I don't have availability or something like that or I need you know help because there's just too much work on a project and I'll pull somebody in but I don't have a team of people around you know. **\[29:47\]** **Mike:** Do you with regard to GitHub and all that do you find that the pull request feature? it seems to me like if I were a developer like you, I would think there would be some people who think they can suddenly make your plug in better. And here's a pull request, just I fixed this thing for you. Like it's easier for them to sort of make that claim than to reach out through an email and say, hey, what about this feature? Do you find that I'm just curious about the pull request feature? Does it just get flooded with people claiming to be a better **\[30:20\]** **Amanda:** version of you. Fortunately, it doesn't because it takes quite a bit of work to submit a pull request, right? You actually need to understand the code base and write a piece of code that hopefully works. People have great ideas for my plugins, or at least they think they do. I get lots of suggestions for features or even for plugins, and I'll weigh them up and I'll consider them you know each one but sometimes those ideas are kind of out there or sometimes those ideas are very specific to this person's use case and it doesn't make sense to add it as a feature that will be rolled out to everybody when really only one person will use it. **\[31:04\]** **Mike:** Right. I guess it's the same principle as making the plugin part of the core. It's like you have to to evaluate, is this gonna improve everyone's life? Or is it just one person? It's sort of like a microcosm version of that, right? **\[31:18\]** **Amanda:** It is. Yeah, it's exactly that. **\[31:23\]** **Mike:** So we talked a little bit about pricing and free plugins and all that. How do you decide how much you're gonna charge for one of your plugins? I mean, do you evaluate what other plugins by other developers' costs? I know a lot of them are 99 bucks or whatever. So how do you come up with these numbers? **\[31:40\]** **Amanda:** Yeah, a lot of them just kind of landed on a, you know, of course, you do a bit of market research and you see what other maybe similar plugins or not even similar plugins, but plugins that provide kind of a comparable amount of functionality might cost. But like I said, I tend to charge if I charge, I tend to charge because of the support burden maintenance burden going forward and for that I guess that takes a bit of experience and you have to kind of understand how far you want to take this plug-in, how much time do you want to commit to a plug-in. There's all these factors to take into account and there's no formula I guess. Like one of my plug-ins, the campaign plug-in is a marketing, an email marketing system that kind of plugs into craft CMS. And it's equivalent, well, I don't make this comparison sound like a one-to-one comparison, but it's like taking MailChimp and pulling it into the CMS and having everything in one place. So maybe as you can imagine, like it's a big piece of functionality that adds, it kind of means that you don't need this external system for email marketing. You can bring everything into into the CMS and manage it there. So that's one plugin that that is going to I think it costs there's a light version I think at 150 and a pro version at 300. So that's a plugin that had to be priced differently because of the scale of what it does as well as the value that that it provides, as well as the support burden because this plugin can, you know, it can send to unlimited size mailing lists. So, you know, there could be a website using it. I mean, you could have one website using it to send out to a mailing list of 100 subscribers. You could have another website using it for a mailing list of 100,000 subscribers. So, like scalability, which is one of of the biggest challenges in software development plays a big role in deciding what to charge. But it's a tricky one. And I think, well, plugins are priced completely different. There's a whole range of them, but they tend to fall into the kind of $50 to $150 range. And I guess that's just a pattern that's happened over time. **\[34:23\]** **Sean:** So have you ever considered taking a free plug in and say okay from the next version this is now going to cost money? This free plug in is really popular, let's start charging. Or it could be something like this free plug in is taking up more time that I anticipated with support. And I'm kind of thinking in my head that sprig because I happen to love sprig and I know when it initially came out, we did a lot of chatting on Discord and email and you really helped me a lot to get my wrap my head around it. And I'm sure there's other people who are equally as incompetent as I was at that time who pester you and take up your time. And you know like I, I might come back to you with support for something else that I can't figure out how to do in and I'm just I really think it should be a paid one and I'm happy to pay for it. Yeah maybe **\[35:20\]** **Amanda:** you'll just start charging you personally. Well it's not something I've ever done or it's not something I would really ever consider because once I make the decision to put a plug in out there for free like I've already decided that it's going to be free and I'm going to maintain it. Of course Of course, there could be a situation like that where it becomes hugely burdensome in terms of support. But sprig is an exception. Let's talk about sprig, because sprig is something that I knew would be a support burden and would require a lot of maintenance and a lot of primarily explanation and education. And the reason for that is that sprig is not something you just kind of plug and play. It's actually a framework, I'll try not to get too technical here, but it's a framework for creating reactive components, so for adding interaction to your site. So it's really a developer tool to help developers. **\[36:23\]** **Sean:** It's a wrapper for HTMLX, isn't it? **\[36:26\]** **Amanda:** It is a wrapper for HTMLX plus it provides that integration with craft CMS. And there I made the conscious decision to put it out there for several reasons. One of them was, as I mentioned necessity, like I thought, you know, I would love to be able to build reactive components, but not have to use a JavaScript framework like React or View, because it's just a much more fun and lighter approach in my mind. But one thing that I did know, being a developer framework, is that it's going to need educational resources. So I kind of committed to that up front, and I made a decision from the very beginning that the plugin is going to be free, but also all of the educational material that I create, which consists of code samples, and I have like a cookbook with lots of recipes that kind of gives you the source code for doing common things that you might want to do with Sprig, as well as a bunch of videos where screencasts where I explain how I build components and I go through the process together with the viewer, I committed to making all of those freely available. And that is kind of a crazy thing to do, in a sense, but how I justified it was that I was going to make it available to sponsor the plugin. And there's GitHub sponsorships available. And I have on average between 8 and 12 people I would say sponsoring with $50 per month. So it's not a bad decent chunk of change for helping to motivate me to continue developing Sprig and also creating more educational material and content for it. But that is that is really I would consider like a passion project or a passion plug-in because I you know I believe in the whole HTML over the wire methodology and I wanted to bring it into craft and make it as simple as possible for for people to start building interesting things using it. **\[38:42\]** **Mike:** Yeah, yeah, that that goes back to the documentation thing. I remember we had Adam Wathen who created Tailwind on the show a while ago, and he was talking at the time about the difficulties of me. I know he's not that's not a plugin, of course, but software of a type. And he was saying that it's challenging making documentation because I think his example was Flexbox, you know, CSS framework, and it uses Flexbox, but he pointed out that there's not really a part of the documentation where you can go and learn how Flexbox works, which you kind of need to know in order to know how all of his little tailwind classes about Flexbox work. And anyway, who is kind of taking its down this rabbit hole of, well, you also have to explain a little bit of this and a bit of that and suddenly you're explaining someone how to make a website **\[39:31\]** **Amanda:** kind of thing. Right, so you decide to put out a CSS framework and then you end up teaching people **\[39:36\]** **Sean:** how what CSS is. Yeah, exactly. And if anybody wants to look at good documentation in my opinion, the tailwind documentation is top of class. It's so, it did it for you, John. So, so good. I haven't hasn't seen a better documentation on anything that I use? **\[39:57\]** **Mike:** So Ben, have you ever made a plugin and had it break eventually as a result of some update to craft and like they do some change and suddenly your plugin doesn't work? **\[40:09\]** **Amanda:** Well, craft goes through, craft follows semantic versioning or attempts to, which kind of means that like a major version like craft 3 to craft 4 is expected to have breaking changes. So in that situation, yes, but there's time to upgrade the plug-in and make the plug-in compatible with the next major version of craft CMS. So in that situation, yes, but it's to be expected. There are some situations with point reduces, which would be like going from 4.1 to 4.2, in which craft should not include any breaking changes. But then you have to ask, well, what is a breaking change? A breaking change really is when a feature that's documented changes so that it has a knock-on effect on a plugin. But there's so many, as good as the craft documentation is, there are lots of features that are not documented. And as a plugin, a plugin can really hook into any part of the CMS and do all sorts of crazy things to all sorts of parts of the plugin, sorry, the CMS that are undocumented for. So I think in my situation it's happened a handful of times, but fortunately, so I get a bit of, I get quite nervous when I put out some of my plugin updates. For example, Blitz has over 10,000 installs, so I kind of have this nightmare scenario in my head, you know, if I release an update, potentially I'm breaking, you know, and there's a breaking change, like a potentially break 10,000 sites plus, but of course that's not the reality. **\[41:56\]** **SPEAKER\_00:** I got to say it's nice to know that it's not just me that has that little panic of anxiety every time I'm about to say, okay, push, push to get, you know, I'm always a little bit nervous about that. **\[42:07\]** **Amanda:** For sure. The reality, of course, is not that everybody updates at the same time. update you know incrementally and some people will update once a week, some people will update once a quarter. So if that happens then I tend to to catch those situations early and either you know if I release something that contains a breaking change or if craft releases an update that contains a breaking change for one of my plugins then I tend to get a GitHub issue or somebody asked me you know hey did this just break and I release a fix as soon as possible and that's also very important for me like if as soon as I notice something is broken or something's just not working the way it's supposed to do I'll release a fixed straight away I don't have a fixed release schedule where I have to wait until you know the 15th of the month to be able to release this and that's That's nice. That's a luxury for me to have that flexibility that I can you know push out release releases as needed. **\[43:13\]** **Mike:** And I guess related to that, I don't know if any of your plugins work like this but I've seen plugins where they kind of interact with other plugins by other developers not necessarily officially react with them but like you know they're somehow related so do you ever have have another plugin developer connect with you and say, hey, man, I'm about to do this just so you know, you know what I mean? And somehow it might impact your work. **\[43:40\]** **Amanda:** Yeah, I mean, I do have some of my plugins do have integrations with other plugins. Fortunately, those are things like, for example, the, well, Blitz has an integration for SEO Madag. So if something changes in SEO Madag like you change your SEO settings or something like that, that can trigger a refresh in Blitz. It's rare that SEOmatic would add a feature that breaks that integration. But I'm in constant contact with other plugin developers. We're constantly discussing ideas and changes and road maps and not all plugin developers. But I have quite a big network of developers that we're going back and forth on and if you know if I'm changing something that I expect or even suspect might break some functionality in another plug and I will absolutely tell that developer beforehand and check in with them and try to avoid that wherever possible. **\[44:43\]** **Mike:** Yeah, that's one of the great things about the craft ecosystem is that you guys I mean we know from attending conferences and stuff all you guys are always there and you're always talking to each other and we, you know, like, it's not like in some other CMSs, there might be thousands and thousands of plug-in developers who never met each other, never talked. You guys are fairly tight-knit group from what I understand based on how you communicate on socials and all that kind of **\[45:08\]** **Amanda:** stuff. Yeah, I would say tight-knit in the sense that we communicate a lot between us, but at the same time, I would also describe the craft community as very open and very, you know, open to sharing information and I don't keep any trade secrets. I published lots of articles on my website and I just share my process. I share how my plugins work. I don't try to keep those things secretive because I believe that we can all benefit from learning together and from sharing and growing as a **\[45:43\]** **Sean:** community. For our listeners, been written up a number of articles on website security must read. **\[45:54\]** **Amanda:** Yeah, those are, well, I was going to say fun to write. Those are challenging to write because I'm not a security expert by any means, but as a plug-in developer, I need to consider security, right? I don't want to introduce security vulnerabilities. And that's also something we didn't really touch on when evaluating plugins, a plugin has the potential to break your side in the worst case, but also to introduce security vulnerabilities or performance bottlenecks, all sorts of things. So auditing the plugins that you use regularly is very important in terms of of various different things including security and. **\[46:40\]** **Sean:** Well, especially keeping them and your CMS up to date, I've read articles about other CMSs and plugins where like private data was stolen because they had a bad version of a slider plugin or something. **\[46:57\]** **Amanda:** Yeah, you hear so many stories about that. Like we tend to think that security breaches happened because of some complex exploit. And very often, it's just, oh, the software wasn't up to date. There was a known vulnerability. And it was easy to exploit. Anybody could have done it. So keeping your software up to date is kind of the number one in terms of security best practices. **\[47:23\]** **SPEAKER\_00:** Ben, do you have any advice for developers who are looking into maybe getting **\[47:27\]** **Amanda:** into plug-in development? Yes, I think it's important to understand how you learn best. So, I would say the starting point for everybody should be understand what a plugin is. So go read the official craft CMS documentation. That's kind of a no-brainer. **\[47:48\]** **SPEAKER\_00:** RTFM. **\[47:51\]** **Amanda:** But from there, if you're a visual learner, then there's the craftquest.io site, which has lots of courses on craft CMS, as well as plugin development, which I've recorded a few courses there, others have too. So if you're a visual learner and you'd like to watch and listen to somebody going through the process, then that's a great place to start. If you're more of a kind of do it yourself, learn by doing person, there is the craft generator, which is a package that you can install. And through the command line, you can create a sample plugin. And it'll kind of prompt you, do you want this feature? Do you want this feature? And then it will actually generate the source code for you. And this is a first party package. **\[48:43\]** **SPEAKER\_00:** Was that based on, was it Andrew Welch that had, like, the, he had something, yeah, the plugin feature? And I think it did evolve into that. or is this something completely different but similar? **\[48:58\]** **Amanda:** It's completely different. The plugin factory was a website that you could go to, and you could click around, and you could select checkboxes of what you wanted. And the craft generator package is a command line tool, which is kind of similar in the sense that they both end up generating source code for you. But there's different methods of doing that. What's good about the new generator packages that it is first party. So you're getting like sample source code from the official source. And I think that's an excellent way of learning because you can generate a sample plugin and start reading source code and see how it's been laid out and what are the different components that are required. And I think the other piece of advice I would give is to use an IDE. So I'm a big fan of PHP storm, but you can probably do most of this with visual code as well. But what an IDE will give you over a simple code editor is code intelligence. So you'll be able to actually if I click around into methods into different classes, the IDE is aware of your entire project and how different pieces of that project are connected. And I find that an amazing learning tool because you can explore the code base. You can kind of see, okay, well, from here, what APIs are available to me. And for each of those APIs, what methods are available to you? So I highly recommend using a proper IDE when going on that learning journey as well. Amazing. **\[50:40\]** **Sean:** I think this has been full featured. Yeah, full featured interview. Yeah, really, really informative. Ben, thank you so much. **\[50:50\]** **Mike:** Yeah, thanks for being on the show, Ben. **\[50:52\]** **Sean:** Thank you, Ben. **\[50:52\]** **Amanda:** Thank you, everybody. And thanks for keeping the show going. It's been evolving really well over time. **\[50:59\]** **Sean:** Well, thank you for the praise. Thank you. **\[51:01\]** **Amanda:** And thank you, yeah. **\[51:02\]** **Mike:** Thank you for being a listener. Hey, thanks for listening today. This is Mike Mella. You can find me online at belikewater.ca or on socials at Mike Mella. **\[51:16\]** **Sean:** Posted in part today by me, Sean Smith. You can find me at my website, caffeinecreations.ca, or on LinkedIn at caffeinecreations. **\[51:26\]** **SPEAKER\_00:** One third of the website 101 podcast talent is provided by me, Amanda Loots. You can find me online at my website, amandolutes.com. I also hang out on Twitter sometimes. You can find me at Amanda Loots.TO. **\[51:44\]** **Sean:** We have an excellent guest today. Ben Croker is a craft CMS plug-in developer, trainer, and consultant, lover of adventures, and the great outdoors. He's with us today from Ecuador, originally based in... **\[51:59\]** **SPEAKER\_00:** No, not Ecuador. **\[52:00\]** **Sean:** Ecuador, yeah! Close to the end of the day. Sorry. Don't look out of my head. Drive the role through the hole. That was a lot of thought. **\[52:09\]** **Mike:** No, no, just, he's with us today. Start there. **\[52:12\]** **Sean:** Okay. Where are you with us today from? **\[52:15\]** **Mike:** Panama. Okay. I think Van Halen. It's a great song. Close Transcript Have a question for Sean, Mike, and Amanda? [Send us an email](/contact). [![Listen on Google Play Music](/assets/images/google_podcasts_badge@2x.png)](https://www.google.com/podcasts?feed=aHR0cHM6Ly93ZWJzaXRlMTAxcG9kY2FzdC5jb20vZmVlZC5yc3M%3D)[![itunes badge](/assets/images/itunes-badge.png)](https://itunes.apple.com/ca/podcast/website-101-podcast/id1449510012)[![itunes badge](/assets/images/spotify-logo.png)](https://open.spotify.com/show/3rmSM1R9t6q1U8DmYWJRSO?si=NrYPMgDaRV6Dd56PjEaPow)### Season 06 - 1 [ Tools of the Trade](https://website101podcast.com/episodes/season-06/episode-1/tools-of-the-trade/) - 2 [ Website Contract Advice From an Actual Lawyer](https://website101podcast.com/episodes/season-06/episode-2/website-contract-advice-from-an-actual-lawyer/) - 3 [ Choosing a CMS](https://website101podcast.com/episodes/season-06/episode-3/choosing-a-cms/) - 4 [ Tips for Website Maintenance](https://website101podcast.com/episodes/season-06/episode-4/tips-for-website-maintenance/) - 5 [ Working with Conflicting Personalities](https://website101podcast.com/episodes/season-06/episode-5/working-with-conflicting-personalities/) - 6 [ Building an Online Course with Jane Atkinson](https://website101podcast.com/episodes/season-06/episode-6/building-an-online-course-with-jane-atkinson/) - 7 [ PodCamp Toronto 2023 Recap](https://website101podcast.com/episodes/season-06/episode-7/podcamp-toronto-2023-recap/) - 8 [ The Good, The Bad, and the Ugly about RFPs](https://website101podcast.com/episodes/season-06/episode-8/the-good-the-bad-and-the-ugly-about-rfps/) - 9 [ Here's how to work from paradise](https://website101podcast.com/episodes/season-06/episode-9/heres-how-to-work-from-paradise/) - 10 [ Rebroadcast: Pimp Your Typography](https://website101podcast.com/episodes/season-06/episode-10/rebroadcast-pimp-your-typography/) - 11 [ Internet Privacy with Michael Geist](https://website101podcast.com/episodes/season-06/episode-11/internet-privacy/) - 12 [ Lessons from a plugin developer with Ben Croker](https://website101podcast.com/episodes/season-06/episode-12/lessons-from-a-plugin-developer-with-ben-croker/) - 13 [ Stand Out on Social Media with Jessica Perreault](https://website101podcast.com/episodes/season-06/episode-13/social-media-with-jessica-perreault/) ### All Seasons - [Season 01](https://website101podcast.com/season/01/) - [Season 02](https://website101podcast.com/season/02/) - [Season 03](https://website101podcast.com/season/03/) - [Season 04](https://website101podcast.com/season/04/) - [Season 05](https://website101podcast.com/season/05/) - [Season 06](https://website101podcast.com/season/06/) - [Season 07](https://website101podcast.com/season/07/) - [Season 08](https://website101podcast.com/season/08/) - [Season 09](https://website101podcast.com/season/09/) <!\[CDATA\[YII-BLOCK-BODY-END\]\]>