---
title: How to submit a support request with Ben Croker
date: 2024-04-30T05:30:00-04:00
author: Sean Smith
canonical_url: "https://website101podcast.com/episodes/season-07/episode-7/how-to-submit-a-good-support-request-with-ben-croker/"
section: Podcast
---
<!\[CDATA\[YII-BLOCK-BODY-BEGIN\]\]>[Skip to main content](#main-content)Guest Ben Croker
Craft CMS plugin developer, trainer and consultant, lover of adventures and the great outdoors.
[ ](ben_pylo)
Season 07 Episode 7 – Apr 30, 2024
40:46 [Show Notes](#show-notes)
## How to submit a support request with Ben Croker
0:00
0:00
1.0x
0.75x1.0x1.25x1.5x2x
[](//dts.podtrac.com/redirect.mp3/website101podcast.com/uploads/mp3/season-07/S07-E07-Support-Requests.mp3)
In this episode we talk to returning guest Ben Croker about how to write a good support request.
### Show Notes
- Turn it off and on
- Our experiences providing technical support
- How to troubleshoot before submitting a support request
- Rubber ducking
- Use the correct support channel: not DMs on social media
- When providing support a public, discoverable approach, such as github issues, is recommended
- RTFM - read the docs
- What to include in a support request
- What to exclude in a support request
- Sean's mistake asking Ben for support a few months ago
- Security issues
- Closing the issue
### Show Links
- [The Dangers of Over Reliance on Plugins in Website Builds](https://caffeinecreations.ca/blog/the-dangers-of-over-reliance-on-plugins-in-website-builds/)
Powered Transcript Accuracy of transcript is dependant on AI technology.
**\[00:00\]** **Amanda:** Welcome to 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 co-host, Amanda Loots. With me, this week is Sean Smith. He's Sean. How are you?
**\[00:19\]** **Mike:** I'm doing good. I'm excited to be here and looking forward to recording this episode.
**\[00:24\]** **Amanda:** Excellent. Our other co-host, Mike Mella, is under the weather today, so he will not be joining us. But instead, we get to talk to Ben Croker again. We've had Ben on the show before, as a reminder. Ben Croker is a craft CMS plugin developer. He is also a plugin trainer and consultant, and he is a lover of the outdoors and adventure. He Ben, welcome back.
**\[00:49\]** **Ben:** Hey, good to be back.
**\[00:51\]** **Amanda:** Thank you. I don't know, maybe we should mention this is actually take two of recording this podcast episode due to technical difficulties that happened the first time. We got about 20 minutes in and then it just died.
**\[01:05\]** **Ben:** Yes, and I will mention that it was my fault. Everybody showed up and I'm in Costa Rica now, so we get power out. They just regularly and we do have backup power system That failed. We had a generator, which I started up that failed to. So the irony of needing technical support in that moment was not lost on me. Of the things go smoothly.
**\[01:31\]** **Mike:** So when you put in your technical support request to get your generator running, did you follow the guidelines that we're going to talk about?
**\[01:40\]** **Ben:** Well, I did not put in a support request. I just kind of let it cool down and then a couple of hours later, of course, it worked. So I kind of was the typical turn it off, you know, weight of it, turn it back on situation. Turn it back on? Yeah.
**\[01:55\]** **Mike:** Hey, that's always a good first step in troubleshooting anything.
**\[01:58\]** **Ben:** Absolutely. Yes. And the physical world is a little bit different to the virtual world. And obviously we understand the differences, but you know, technical things or technical things so that they share a lot in common too. And I think we're kind of privileged to work with software because we get updates sent down the internet pipelines to our computers, which is pretty amazing. And we kind of, of course, get people to send us code samples or tips to things to play out. So we're pretty lucky in that sense.
**\[02:33\]** **Amanda:** Yes.
**\[02:33\]** **Mike:** Absolutely.
**\[02:34\]** **Amanda:** In university, I had a co-op work term where I did tech support at a revenue Canada office. And on my first day there, and I'm trailing around, I'm like shadowing some senior tech person or whatever. And the very first ticket that he went to go do, he tried a bunch of things, he tried a bunch of things, he tried and what ended up working in the end was control all delete three times. Wow.
And I just thought to myself, how, how would anybody like once, yes, I get it? maybe twice, but to do it just three times in a row. And he was like, yep, that fixed it. Let's go, no explanation, no rhyme or reason.
It was very frustrating.
**\[03:17\]** **Mike:** Well, it's interesting, because all three of us have then done technical support. Ben does it for his plugins, Amanda did it. And I previously worked for Alice Lab doing technical support in the forums.
**\[03:29\]** **Ben:** You did? Those were very active forums back in the day.
**\[03:34\]** **Mike:** they were. They were. It was fun. I did that for a little less than a year. I forget why, but I stopped working with them, and well, here we are now today. Anyways, it was a good learning experience about what to do, what not to do, how to interact with people, and oh, it's awesome. So then, what are some things that users should consider before they submit a support request? So they're They're working with your plug-in or somebody else's plug-in or even just whatever code that they're trying to do and they're looking for help. What are some things that they should do before they ask for help?
**\[04:16\]** **Ben:** Right. I think first of all, it's important to consider nobody actively thinks, oh, I'd like to create a support list. They just want their problem solved, right? And if they could, they would turn around and ask the person sitting next to them, but if Because that person isn't there, or doesn't know, and they actually have to create the support request and go through this process.
And there's this phenomenon I've found where intelligence, well-meaning people become kind of like, lubbering buffoons when they need help, like in a rush, right? And myself included, like, I've been there, so I'm speaking from experience. raises his hand. It's a situation of, you know, I need to get this thing launched or I need to get this thing delivered and this one thing is holding me back and it turns into this kind of stream of it's kind of a cry for help.
But the end goal of what we're trying to do is we're trying to solve our problem. So we need to consider that when we're asking for help so that the person who we're asking for help for can also kind of help us reach that goal as well. But I think probably the most important thing to do before you submit a form as a forward request is do some collection, data collection of what is the problem. I go through that process mentally and there's this thing called rubber duffking.
**\[05:50\]** **Mike:** you've heard of it where I was going to mention that yeah yeah that you know
**\[05:54\]** **Ben:** programmers should have a rubber dog on their desk next to their computer and if they run into an issue before you ask before you send a discry for help ask the rubber dog and simply the the active formulating question often forces you to go check other things which tends to in many situations kind of like allow you to find the answer on your own. So just kind of taking that pause and exploring what the actual issue is and formulating the question in a way that divides all the information necessary and it will often get you the answer just in the activity. Yeah I've found that rubber
**\[06:37\]** **Mike:** ducking does work but I don't actually intentionally do it. I find that when I start to write out a a support request or when I'm talking to somebody about it, it's the act of going through an explaining step by step by step, and then I'll all of a sudden I'll have this epiphany is like, oh, it could be that. That's it. And it's solved. And I don't actually have to submit the support request. So I mean, it's rubber ducking, but it's like the last step just before I hit submit.
**\[07:07\]** **Ben:** Yeah, and our tendency is to like reach out to a person as the first step. But if we reach out, you know, if we simply reflect on the question and go do some discover and discovering on the issue, then we can't often not always find the answer, but that already sets us up for creating a good support request. And I think our focus today is going to be on the side of the person who's creating the support your quest. But I think later we should also discuss setting up, like as a plugin developer or as a developer providing a product, how you can set your users up for success in terms of, you know, how they should go about creating that request and, you know, channeling them to the
**\[07:58\]** **Amanda:** to the right place to submit that. Absolutely. Yeah, that's a good idea. So back to your question,
**\[08:03\]** **Ben:** though. I think that's the first step is kind of doing some recon and figuring out what the issue is. Now, as we said earlier, like turn it on, turn it back on is step number one. In most cases, if it's your generator, do what I did, turn it off, come back 10 minutes later and it just works.
**\[08:24\]** **Amanda:** Or the router or the Wi-Fi?
**\[08:26\]** **Ben:** Yeah, if it's the router, the Wi-Fi, the printer, you know, these things. We've all been asked, I think by friends, relatives, you know, can you, my printer is not working and there's no question there. It's just like the statement we should have. We should be able to say the magic word and often that does, my wife actually will often call me over saying some, this is not working.
This is not working. I'll walk over and I'll say, okay, what's not working and then she'll be like, oh, now it works. So there's often this like just, I don't know what it is, but it's this kind of, when you're doing something in the presence of somebody who you think knows what's going on, then things tend to work. Have you found that?
Have you come across them?
**\[09:07\]** **Amanda:** Well, I heard, so I've heard anecdotally this story a very long time ago. Somebody in a car, they had a brand new car, they were very excited about it. And they noticed that whenever they went to the ice cream store and got a certain flavor of ice cream, they would go back to the car and it wouldn't start again. trying to like contact the car manufacturer and explain that it's like it's not when I drive to work and it's not when I go to the mall and it's not when we go for dinner it's when I go to this store and buy this flavor of ice cream and everyone thought the person was cuckoo pants because even like at some point they were like even when I go to that store and I got a different flavor of ice cream the car will start it's no problem it's only ever this flavor of ice cream and I don't know how they figured it out but eventually what it came down to was that the car didn't have a chance to cool down.
So this flavor of ice cream was at the front of the store. So their trip of going in and getting it and paying for it was half the time of picking any other flavor in the store. So just going back outside and trying to, so it's oftentimes it seems like something ridiculous that makes absolutely no sense. But if you can use that almost as a detective and try to figure out what exactly is the cause It's not ice cream, but it's like the wait time.
So yeah, oftentimes it's so frustrating, yeah.
**\[10:32\]** **Ben:** That's a really good story.
**\[10:33\]** **Mike:** Oh, come on, the car is possessed, and it just doesn't like that flavor of ice cream.
**\[10:39\]** **Ben:** Because causality is like, it's important and it's risky because we can get into this thinking that, you know, oh, like you said, I have to hit control all the lead three times. And I'm not saying that was not the solution. It worked in that instance. But maybe that person just had to wait long enough and three times was long enough.
Yeah, so that comes back to turning it off, turning it on, kind of forces you to just wait for the thing to restart or allow it to cool down or sometimes we simply don't know what the issue was. But once it's solved, we kind of just get onto the next thing so we don't even take the time to figure out what the problem was in the first place, but the more you can do upfront than your own, think the better. So we talked about turning it off, turning it back on that, I guess, advise to your computer or your web browser or if you logged in like log out, log back in, maybe it has to do with your current session. And then I would say like, once you've tried those things and you've waited a bit of time if you can, that's a challenge because you know, We're often in a rush to get the thing working.
And then I think it's important to figure out, okay, what is the correct support channel? I'll often get this kind of support requests I get, I guess you can call them, but there are more questions on direct messaging, apps, Twitter, sometimes on Discord. And it's okay as a first step of reaching out, but it's not ideal, right? Like direct messaging back and forth, asynchronous communication is probably the best thing because we can work through a problem together regardless of whether one person's online or not and there are much better tools than direct messaging for you know submitting support requests.
So I think figuring out like what is the official support channel is an important step and hopefully That is something public that has some sort of issue tracker that is searchable and discoverable, which will allow you to kind of do a, like a web search within that issue
**\[12:59\]** **Mike:** track. Yeah, I was just going to say if it's something that's public, then if you're the first one with that issue, when it gets resolved, you're helping future people who have come across the same problem. So getting support by DM, it's more personal or email, it's more personal, but it doesn't help everybody, and Google is not indexing it. If you've got to GitHub issues, which is very common for the plugin developers and craft, I can just Google the problem, and a lot of times it'll show up the link to GitHub.
**\[13:35\]** **Ben:** And this is why I use GitHub, where one of the reasons I use GitHub issues, it's discoverable and it's public and I can refer people back to it. I can search it myself if I know, oh yeah, I did answer that question, but I don't remember the solution. I can refer back to it as well. And as you said, search engines will index it.
**\[13:56\]** **Amanda:** Before we go on, actually moving to something else. I just wanted, we've talked about users googling for answers and I'm sure users should start using AI solutions like chat GPT, et cetera, whatever to try to help them find solutions, but I find that really the biggest one is just go and read the documentation, RTFM. And I have fallen victim to that as well, where it's like, I thought for sure I was following every step of the instructions and then it's not working and why and tech support and it comes back and they were like, well the documentation says this and it's like, oh my lord, that was the step that I missed and after that everything worked great. So just like with a recipe in the real world, just follow step by step and actually take the time to read it and don't skip over things because you think it's not important.
**\[14:50\]** **Mike:** Documentation is, documentation is really important. Not speaking for plug-in developers, not every plug-in developer has the best documentation. Ben is good, Andrew Welch, and there are others, but there's some plugins that have like really poor documentation. And I recall a story that Mike mentioned that he was trying to get some support. And the developer came back and said, as it is in the docs, you need to do this. He went, Mike went and checked the docs. It wasn't there. So the issue here, I think, is that the developer knows their software so well that they forgot to include it in the documentation or they plan to, but they just didn't get around to it. And they're like, yeah, it's in the docs. It's really easy. And it wasn't.
The documentation is a good plan, but it might not always work for you.
**\[15:47\]** **Amanda:** Well, and the documentation too is often at different levels. Like maybe somebody more junior needs a little more handholding or somebody more senior doesn't want to like troll through pages and chapters like to just get to get to the very advanced specifications that they need or want. And you can't have documentation at different levels. that's way too much work for the plugin developers. Please work on the plugin instead of the documentation. It's a hard balance.
**\[16:15\]** **Mike:** I think documentation is the hardest job for the developer, not the actual coding it, but you have to write it in such a way that it's easy to follow searchable covers edge cases and just everything. I think it's a difficult job.
**\[16:32\]** **Ben:** If I remember correctly last time I was on, mentioned that support takes up about 50% of my time, which might be surprising, but that does include like answering support requests, but also documenting things, going through the docs and reworking them, writing articles and knowledge, kind of based documents, writing frequently asked questions and common issues. All of that stuff for me is just as important. Does he say as like the plugin actually doing what it's supposed to do because if people can't use it Then how much functionality are you really providing and I tried to be as disciplined as possible when in a support It best comes in and I answer it. I will then go refer to the docs and see what does do the docs explain You know that question that that person had and if not could they Or is there somewhere else like a frequent ask question section where and in like belong again just to help you know future me and future People users and from being able to solve this issue on their own
If people can't use it, then how much functionality are you really providing.
**\[17:39\]** **Mike:** Yeah One of the things that I like about your documentation especially for sprig is that you went through and you've got a cookbook Where you got things that calm and tasks that people will want to do with with it and And it's really helpful. And even though I use Sprig on almost every site I build, I constantly going back there to check things. It's more than just documentation. It's examples, real live example code that you can actually use. Copy and paste it and it just works, it's great.
**\[18:15\]** **Ben:** Yeah, some plugins are gonna be very simple to use or an intuitive, you turn it on and it just works. And other plugins like Sprig, they take some, there's a learning curve. And part of addressing that learning curve is giving people not only documentation, but examples and sample recipes, as we call them in the cookbook. And I have a whole video series on how to create different types of components and make the source code available. And the whole idea is there is, this was two ideas. One is to reduce the support node on me. and the other one is to, you know, and now developers to do more advanced complex things on their own through giving them all these learning resources. And that's part of support as well.
And part of addressing that learning curve is giving people not only documentation, but examples and sample recipes.
**\[19:09\]** **Amanda:** Hi, Amanda here. If you're enjoying the website 101 podcast, we would love it if you could give us a positive review on Apple podcasts or wherever you get your podcast. Reviews help new listeners find out about us and allow us to keep doing the show.
**\[19:22\]** **Mike:** Thanks. So speaking about users, when a user comes to you and they've got an issue, what are things that you want or would expect them to include in a support request?
**\[19:38\]** **Ben:** Sure. So I think everything we've talked about up until this point in terms of what to do is like before you actually submit the support request. And there's one maybe important step is to update the software. like make sure you're on the latest version because one of the first things that I'm gonna ask a user is what version are you on and have you tried update? Cause updates are there to not only add new features and functionality to pieces of software but also fix issues and fix bugs that are known about. So if you hear a few versions behind, chances are or there's a good chance that maybe you've encountered a bug and that bug has been fixed in a future version. So updating software is important. But really, I think it's important to kind of explain the problem from a kind of round about situation of, this is the issue that I'm encountering. This is what I would expect to happen, but this is what's happening. Here's everything that I've tried. Maybe if there's an error message, here's the error message that I've encountered. Here are the steps for you to reproduce it, which is really helpful. Because if it's something that appears to be a bug, then I need to be able to reproduce that to be able to confirm or deny that, right? And like you were saying Amanda with the guy who his car wouldn't start after going to the ice cream store, like that's not something you can reproduce. So how can you help this person? unless you go with him to the ice cream store and take some measurements. We can't really do that here. And similar to the ice cream store, because craft is craft CMS itself posted, it can be running on all sorts of different environments, different machines, and different operating systems. So it's difficult to reproduce some, or we can really reproduce someone else's entire environment. So we need some code or something that we can reproduce the issue and troubleshoot it. So providing like, if it's appropriate, things like screenshots, error messages, and code samples that I can take, reproduce, and then, you know, fix the issue, if it is an issue or tell the person what they're doing wrong, and are all, like, greedy, important fate.
Explain the problem from a round about situation of this is the issue that I'm encountering. This is what I would expect to happen, but this is what's happening. Here's everything that I've tried.
**\[22:13\]** **Mike:** When I make a support request, the first bits of information I always include at the very top are the CMS version and the plugin version. And then if there are any other relevant plugins that might be affecting things like in that template, I'll include that as well. But I think that you should know what version of the plugin I'm on. there might be a reason like that I am unable to update, because for some reason the production site we just can't do it, then you need to know that, hey, I am a few versions behind.
**\[22:49\]** **Ben:** Yes, because if I want to reproduce your environment, I need to maybe backtrack to that version and see if it was an issue. Yeah, so one of the ways of addressing that is, I mentioned GitHub issues. GitHub issues allows developers create different issue templates. So for example, for a bug, I'm able to specify what you need to tell me how to reproduce the issue. And I can make different fields so that everything is laid out. And I do that because I want to ensure that the person has done some due diligence. I'm able to request the version of plugin, the version of craft CMS, and dependency. then you mentioned dependencies shown, which is an important thing because dependencies add a whole lot of complexity to software. And it's something that's difficult to read. Yes, you can provide all of the version numbers of your dependencies, but difficult sometimes to know is the issue being caused by the piece of software that you're using, the keyword like interacting with, or is it being caused by something that it depends on. that's always going to be a challenge. And therefore, I think you wrote an article about
One of the ways of addressing that is using GitHub issues and issue templates.
**\[24:07\]** **Mike:** reducing dependency on plug-ins to Pepe. Yeah, I'll include a link to it in the show. I'm sure. Yeah, I wrote that and it gets mentioned several times in the discord because really, fewer plug-ins that you use, the better it is for the life of your website, in my opinion.
**\[24:31\]** **Ben:** She or dependencies, she or things that can go wrong, a few are things that need to be updated.
**\[24:37\]** **Amanda:** Yeah, if you're moving parts, yeah. We've talked about some of the things that would be good to include. And I also like that on GitHub issues, sometimes they'll be like a template there to like show you the type of information that's expected. What are some things not to include? And do you have any hilarious stories about people that have just sent really wild and appropriate information that you just did not need?
**\[25:00\]** **Ben:** API keys. Oh, yeah. Yeah. Secrets have been sent. Yeah. Because very often when you send error messages or stack traces, yeah, or a log file, those will incur secrets. So I have had plenty of situation where secrets have been incurred in there. And I'm able to delete those in the issue tracker, but it's still never good to do that. So some some amount of retracting before you send your logs would be important to do. I do ask, like I mentioned, like for code samples, when relevant, sometimes I will just get like a wall or code. And in those situations, it's difficult because it's like, you know, how much Sean is hiding? Yeah,
**\[25:53\]** **Mike:** Because in January, I did that to you. I was going to bring it up myself, but you brought it up and it was referring back to what you said earlier. It was like, I need to get this fixed and I just dump this, the entire template instead of stripping up what was relevant and I'm so sorry, I did that too.
**\[26:16\]** **Ben:** That's a great. I don't remember this exact situation. Oh, thank God. My guess is that my answer was, please provide a reduced, yeah, it was something along that life. Yeah. And on the one hand, I don't think it's worth my time reading through hundreds of lines of code, just to find the three lines of code that are relevant. But on the other hand, I can't copy paste that into my environment and reproduce it, because you're likely referring to different sections made by their ideas, that kind of thing that I wouldn't have in my local copy. So getting a code sample that is just reduced down the few lines of code that really demonstrate the issue is important.
Getting a code sample that is just reduced down the few lines of code that really demonstrate the issue is important.
**\[27:04\]** **Mike:** Anything else that you would like to exclude?
**\[27:07\]** **Ben:** Yeah, the other thing that I think is important is anything that is a potential security issue. So if you discover a bug and you don't really know what's going on, that's fine. But if you notice, hey, this is something that could actually be exploited and maybe sensitive data could be stolen or manipulated or something, then there's a bit of a different process for submitting that. It probably should not go through any kind of public and issue tracker. It should probably go directly to developer. And most developer is will have a security policy where they kind of outline steps that you should take to submit at the pen show security issue. And that will normally be there in kind of in the same form of a support request where you describe the issue and the potential security implications, but they'll go directly through email or through some sort of private channel to the developer who can then address that in a more responsible way.
Anything that is a potential security issue should go directly to the developer through a private channel.
**\[28:10\]** **Mike:** Yeah, that makes sense because you don't want that security issue out there before it's fixed.
**\[28:16\]** **Ben:** Yeah, that's exactly. And usually there's this grace period, security of this whole cyber security, this kind of whole other world that I've dipped my toes into and I find it interesting, but it's a bit 80 into me too. But this is kind of grace period when after a security issue is reported, the security researcher or whoever submitted it will not disclose it publicly until a patch or security fix has been released and normally for one or two months after that point, so the people have a chance to update their software and make sure that it's secured. Another important reason why updating your software is so important, it's not just those bug fixes and those features, those security updates.
**\[29:07\]** **Mike:** Yeah, and actually, since CMSs and plugins rely on other packages from GitHub, if If you update the CMS or the plugin, you're also getting updates of everything else that might have a security issue that even Ben might not know that there's a security issue in a certain package that he's using when he updated it with a new version for Sprig or whatever plugin he's updating, and so there would be like this rabbit hole of potential security fixes.
**\[29:39\]** **Ben:** So I guess that brings us to, you know, once you've submitted the support requests, what of the next steps. And hopefully if you've gone through that process, you've given the developer all of the information, then you're going to receive a quick response. And you've done your work up front. So that response is not going to be like, well, what version are you running? Or well, have you tried turning it off and on because that's the other thing that as the, you know, people providing support, we need that in. I'm unable to help somebody who hasn't provided the basics of what's necessary to actually, you know, encourage them to try what to try. So, um, hopefully, you'll receive a response that kind of like points you in the right direction or even gives this solution.
And then I think once the issue is resolved, I think it's good to go close the issue. Um, if it just started working or if you solved it in a different way. I think it's also a good idea to kind of put that in the issue so that other people are maybe experiencing the same problem. Don't just kind of get a blank,
**\[30:53\]** **Amanda:** you know, at the end they can actually maybe learn from you. I think everyone has been super frustrated when they go search for the issue that they're having and one other person was like describes the exact same problem like on Stack Overflow. And then the only comment is from like a month later from the same person where it's like solved and it's like how though like what did you do? Yeah, so it's definitely helpful to to keep everybody up to date.
**\[31:22\]** **Mike:** Oh, 100%.
**\[31:24\]** **Ben:** I tend to follow up with support requests and it with GitHub issues. Like if I see two weeks of past and this person hasn't responded to me, I'll say hey, did you did you get that like you said Sean Closure? Like did you get that issue resolved? I want to make sure that they did And if they did, I want to make sure that I want to encourage them to explain how they did for anybody visiting that in the future.
**\[31:47\]** **Mike:** Yeah, I try to almost always go back and close the issue. And thank you for your help. Fixed. Fixed it. Like you said, I ended up not needing this or whatever. Just let people know that you walked away from it and it is done.
**\[32:06\]** **Ben:** Yeah. closing the issue kind of, you know, in GitHub, it doesn't force, like you can see a comment on that issue, but it kind of shows closure. And sometimes people then follow up with the next question. And I'll try to encourage them, hey, can you create a new issue because, you know, it's a completely different topic in this issue is close just for my own organization. Right. So having a support system, I think in place, like an issue tracker rarely you can get notifications from, give up notifications is great because I don't get like a stream of emails coming in telling me that there's something I can check it in my time and I do that, you know, we're seeing them warnings. And then I can organize the issues based on priority, based on what's going to answer it, what's depending if you have a team of developers and you can assign issues to different people.
So support for me kind of bleeds into the product as well. I could try to build support into the product or the plugin. And what I mean by that is like anytime you have to enter information or choose settings, I tried to explain those settings in place, in context, rather than forcing or expecting people to read the docs because they don't. I explained this setting means that, you know, what is the implication of them? I'll often use info windows that can be expanded, that explain things in more details, and when appropriate, link off to the docs for even more details. Of that, you know, it's really just helping or encouraging people to have a good experience using your plug-in, which means that, you know, they don't get stuck, they don't get frustrated. That's really important for quality product.
**\[34:11\]** **Mike:** How often do you run into an issue with somebody that you cannot find a solution or it takes a crazy amount of time to figure out, like, it's a super edge case? Yeah. And do you have a story you could share?
**\[34:26\]** **Ben:** Those are the tough ones. Yeah. The easy ones are like, oh, you just need to disable this setting or, you know, here's the link to the docs. And fortunately, for me, the majority of the support requests are relatively straightforward. I can address them in a couple of minutes or there's something back and forth and getting information. But it is those kind of edge case support requests that are very time-consuming that kind of caused some worry because I think you know like the car that doesn't start like you know did I do something wrong is there is there some big issue or not big but is there some bug hiding in my code base that it only crops up in these certain situations and also known as an edge case. And yes, those come up not that frequently, but there was one not too long ago actually.
And it just took a lot of looking and a lot of trial and error. It was only happening in one specific environment on Amazon AWS, which I tend to avoid. I think we all do. Yeah, it's over complex. It was not reproducible locally. It was not reproducible. I couldn't reproduce about on any kind of server that I tried. And we have a lot of back and forth because the site was already in production. It's happening in the production server, so it's, you know, it's all of the entire scenario just made everything difficult to troubleshoot simply because it was not reproducible. Like, once an issue is reproducible locally, I can run a bunch of tests, I can use Stepped debugging to step through the code. I can try things out very quickly, but in this case, it was like make a change, ask the person who submitted the support request to test it. In there, guess it wasn't, they were testing and staging, but it was a mirror of the production server. So all of this just took a long time.
And it felt like I think it took also about two weeks, two and a half weeks may be being told to troubleshoot it and that's challenging, yeah, because it's always at the back of my mind. Is this some big issue, why can't I figure this out? In the end, it happened to be this unique scenario where it had to do with the environment, but it also had a combination of three different settings that had to be in a specific configuration. And it turned out to be a bug.
**\[37:04\]** **Mike:** So it sounds really difficult to troubleshoot.
**\[37:07\]** **Ben:** Yeah, and there's always the question there, like, is it an issue with the plugin or is it an environment issue, environmental issue that I have no control over?
**\[37:17\]** **Amanda:** Yeah. Well, it's so often those production environments are nothing but a black box. Yeah. Oftentimes as developers, we don't even have access to it because we've got all of these auto-deploys that happen now. which is kind of like a, hey, hopefully it works out. And if not, I'm gonna have to figure out some magic.
**\[37:40\]** **Ben:** Right, it is a black box, you're right, because we can't really look inside it, especially when it's, you know, this virtual server that's posted on in the cloud somewhere. But yeah, it was a bit stress-inducing because I don't know if it has to do with my code or the enzyme. And therefore, I can't really put up, raise my hands and walk away, right? I need to kind of figure out because I could be an issue with the bugging.
In this case, it turned out to be, and I'm grateful that the person worked with me for those two weeks or so and to get to the bottom a little bit. And now it's solved and now it's documented. So hopefully, if it comes up again, we know how to address it.
**\[38:25\]** **Mike:** Yeah. I'm sure that they appreciate the effort that you put in, it must have been frustrating for both you and the person who put the support request in.
**\[38:35\]** **Ben:** Yeah. For sure. And I know that they, for example, had their development agency. So they had their clients telling them, hey, this is not working. They were the middle person, and they were communicating with me. Fortunately, they're very good developers. So they were able to work together with me and to get to the bottom of it. and they had pressure from their clients which I completely understand so yeah fortunately we got through it but those those edge case bugs are tricky and likely stress
**\[39:08\]** **Amanda:** boost for me awesome thank you Ben for coming out and talking to us again about support tickets and how everybody can work together to get any issues figured out thank you it's been fun
**\[39:23\]** **Mike:** Yes, Ben. Thank you. You're a friend of the show. Come back again. You'll be our first triple guest. Yes.
**\[39:28\]** **Ben:** And then glad to.
**\[39:34\]** **Amanda:** The website 101 Podcast is hosted by me, Amanda Loots. You can also find me online at AmandaLoots.com. And by me, Mike Mella, find me online at belikewater.ca or on socials at Mike Mella.
**\[39:46\]** **Sean:** Hi, I'm Sean Smith, your co-host. You can find me online at my website, caffeinecreation.ca, and LinkedIn at caffeinecreations.
**\[40:08\]** **Amanda:** Sorry, sorry, before we go on, is there like squeaking happening in the background?
**\[40:12\]** **Mike:** Yeah, I think there's birds. Is there a way you could close your window or is it going to get too hot for you? It's okay
**\[40:19\]** **Amanda:** Sorry, thank you
**\[40:21\]** **Ben:** There we go. It's birds
**\[40:24\]** **Amanda:** Like weirdly like rhythmic like I Thought it was like maybe something squeaking in a car or kid on a playground or something. It's stopped now
**\[40:34\]** **Mike:** Yeah, yeah, it's much better. So yeah, Mike as you're listening to this Don't try and get rid of that noise. Mike, Michael, I added it later. He's not here.
**\[40:44\]** **Ben:** Sorry, Mike. Sorry, Mike.
Close Transcript
Have a question for Sean, Mike, and Amanda? [Send us an email](/contact).
[](https://www.google.com/podcasts?feed=aHR0cHM6Ly93ZWJzaXRlMTAxcG9kY2FzdC5jb20vZmVlZC5yc3M%3D)[](https://itunes.apple.com/ca/podcast/website-101-podcast/id1449510012)[](https://open.spotify.com/show/3rmSM1R9t6q1U8DmYWJRSO?si=NrYPMgDaRV6Dd56PjEaPow)### Season 07
- 1 [ When to Say No](https://website101podcast.com/episodes/season-07/episode-1/when-to-say-no/)
- 2 [ How can I communicate better with clients?](https://website101podcast.com/episodes/season-07/episode-2/how-can-i-communicate-better-with-clients/)
- 3 [ What to do when work is slow - with Mitchell Kimbrough](https://website101podcast.com/episodes/season-07/episode-3/what-to-do-when-work-is-slow-with-mitchell-kimbrough/)
- 4 [ Motivation, Burnout, and Imposter Syndrome, with Kevin Nicholson.](https://website101podcast.com/episodes/season-07/episode-4/motivation-burnout-and-imposter-syndrome-with-kevin-nicholson/)
- 5 [ How to spin up a website quickly using a boilerplate](https://website101podcast.com/episodes/season-07/episode-5/how-to-spin-up-a-website-quickly-using-a-boilerplate/)
- 6 [ Back in my day...](https://website101podcast.com/episodes/season-07/episode-6/back-in-my-day/)
- 7 [ How to submit a support request with Ben Croker](https://website101podcast.com/episodes/season-07/episode-7/how-to-submit-a-good-support-request-with-ben-croker/)
- 8 [ Online Learning and Keeping up with Technology with Ryan Irelan](https://website101podcast.com/episodes/season-07/episode-8/online-learning-and-keeping-up-with-technology-with-ryan-irelan/)
- 9 [ Unlock your ADHD superpowers with Chris Ferdinandi](https://website101podcast.com/episodes/season-07/episode-9/unlock-your-adhd-superpowers-with-chris-ferdinandi/)
- 10 [ Rebroadcast: 11 Things to avoid doing on your website](https://website101podcast.com/episodes/season-07/episode-10/rebroadcast-11-things-to-avoid-doing-on-your-website/)
- 11 [ Raw and Unedited](https://website101podcast.com/episodes/season-07/episode-11/raw-and-unedited/)
- Bonus[ The Joy of Self-Taught Coding](https://website101podcast.com/episodes/season-07/episode-/the-joy-of-self-taught-coding/)
### 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\]\]>